Re: [cobalt-users] Severe Security Problem Between Sites

[michael@xxxxxxxxxx]

Hi all, especially Robert G. Fisher,

Robert, thank you for your answer, but I was probably very 
misunderstanding in my intention. I did not make the setup which I was 
describing, it is the default setup of my Cobalt RaQ3! I just showed up 
some flaws. For many things fixes are easy, but then the UI 
administration of the RaQ3 ist broken AND thus the warranty lost.

> > 1. Everybody has Telnet access to ALL sites!
>
> Umm...You only have ONE server.  You don't actually telnet to
> a virtual site so much as to the server it's hosted on.  The
> only way you're going to get to where people don't see this is
> to change the shells to something such as ksh or similiar that
> allows for you to do a chroot.  That or do make the default
> script call chroot as the user logs on -- this has the unfortunate
> affect however that they then need a copy of lib files and basic
> binaries in each site directory...Not very efficient.

It's certainly not the ONLY way to chroot. I already gave a solution in 
my original article, just with access rights. The point is: it breaks the 
UI administration of the RaQ! For every added site and every added user, 
manually work is necessary.

My point was: why des the default setup not offer correct right settings? 
But the answer comes problably with the next point:

> > where CGI- or PHP-Skripts store data. This is because the httpd needs
> > "world" rights to the files in the sites. Actually it´s at least not
>
> Umm...httpd should never require files to be world writeable.

So I thought, but again: that is the default setup of the RaQ! 

> Generally speaking the httpd (Apache) will run as either the
> account it was started from or if started as root, as the User/Group
> specified in the config files.  You can find what this is by running:

>       egrep '^(User|Group) ' /etc/httpd/conf/httpd.conf

htttd, httpd is the answer. But all the files, including the 
automatically generated web/index.html in the site's and users's 
homedirectories look like this:

[admin@www conf]$ ls -la /home/sites/home/web
total 3
drwxrwsr-x   6 httpd    home         1024 Mar 19 22:23 .
drwxrwsr-x   6 httpd    home         1024 Mar  1 19:32 ..
-rw-rw-r--   1 httpd    home         2887 Mar 25 21:31 index.htm

This index.html can get accessed by httpd, because it belongs httpd, but 
new files ? with no way around ? will look like this:

-rw-rw-r--   1 owner    home         2887 Mar 25 21:31 myfile.html

Neither does it belong httpd nor is httpd in the group "home", thus httpd 
can only access it if the file has world-read-rights. 

> Generally speaking, files will need to be writeable by this User
> or by this Group if you want FrontPage extensions to work.  Leaving
> them world writeable, is often just the mark of sloppy programming
> and/or configurations.

In this case the sloppy programming/configuration is within the Cobalt 
setup! All PHP programms in the default config need world-write-rights to 
data-files. The reason is the same as depicted with the myfile.html 
above.

> Generally, the mail spool files should be owned by the user of the
> same name and should be read-write by the user only.  

It was just a guess, but here you are right, at least for the mail files 
the Cobalt config does not screw up.

> > are readable (skripts often have to contain passwords) and data files
> > where scripts write to are even writeable.
>
> Storing passwords in plain text...once again, a bit of slopy
> programming.

I agree, but I don't know any other way. How do you add your passwords 
for MySQL databases in PHP skripts?

> > This could be solved by adding httpd to all site groups and remove the
> > world-rights from all site directories and files (chmod -R o-rwx
> > /home/sites/*). But I am not sure if having the httpd in all the site
> > groups would raise new security leaks. And of course that breaks the
> > admin UI of the cobalt.
>
> Well, first off...This will only work if you have less than 32
> sites on your server.  32 is the maximum number of groups a user
> can belong to under Linux 2.2.X and 2.0.X kernels.

Good hint, thanks!

> What Cobalt does on the RaQ2 is it basically has all the files
> under the web and log directories owned by the httpd account.
> Then on top of this, the access permissions are set with
>       -rw(x)rw(x)r-- for files (x) for directories.

And exactyl this last r is bothering me! For PHP via module that means 
that data-files have to have world-write-rights too ? at least in the 
default config. We will change that to PHP via CGIwrap. But the point is: 
why is the default config so insecure?

> Bingo.  And, generally speaking -- Apache doesn't change uids to
> suit a virtual host, at least, I've never seen that happen.  You're
> more than welcome to try editing the httpd.conf file to add the
> User and Group lines to each VirtualSite, good luck, though I'd
> re-check the apache docs to see if that's even valid.

The documentations sais, it does ? but only for CGI scripts. I really 
think this is an awful bug in Apache or probably the PHP module for 
Apache. It should seteuid for such things too. Same btw for the Perl 
module.

> > It´s easy to fix, just add the right catch-all rules to the
> > /etc/virtuserlist. But again, you break the UI-only admin advantage of
> > the Cobalt.

> You *CAN* add the alias as 'u1@xxxxxxxxxxxxxxxxxx' -- since RaQ2,
> the 'aliases' are written directly to the virtusertable.  

But I can't add a catch-all address via the admin UI. Actually, and that 
was my point, that should be done be the admin UI automatically!

> > By default there is no MySQL root passwort set, the admin is not forced
> > to set one and I´ve not even found a hint to do that. So if you forget,
> > problably one of your Telnet users will do that ...
>
> This is silly, honestly, if there *IS* a default password and you
> forgot, then all your telnet users would have to do is try the
> documented default password and change it of their own accord.

I did not say they should add a default password. I just mentioned they 
should address this topic at least in the manual or even better: let the 
password set by the admin in the first setup process so that there is no 
way around to forget. 

My point is: if the security default security for a RaQ is so weak and 
you need to edit many config files or set rights etc. for each site and 
user anyway: not much point anymore for a such a UI administrable system. 
Especially because it seems some of the flaws cannot be wiped out without 
losing warranty.

Got what I mean?

Bye
	Michael