[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#499191: Possible security issues

I haven't looked at your patch yet, but here are some more arguments.

On Saturday 24 January 2009, Alexander Prinsier wrote:
> > Not so. But this would mean that in many setups, any user would
> > be allowed to execute any root-owned program under the document
> > root that has mode +x as any _other_ user (above uid 100). This
> > is something that no admin would expect. The restriction that
> > suexec can only be executed by apache can often be circumvented.
> > E.g. if user are allowed to create php scripts in ~/public_html.
> If a user is allowed to create a php script that will be executed
> as www-data, he can just go read everyone else's data (like a
> config.php which includes passwords to databases etc), because
> everyone else's data must be readable by www-data to get served by
> apache in this setup.

You are just considering pure web servers. On a machine that has a web 
server running but is also used for other things, users' home 
directories will contain many things that are not readable by the 
user www-data. If you have some insecure cgi script that allows to 
read arbitrary files, every local user would be able to read 
~/.ssh/id_rsa of every other local user. This is not possible with 
the current, tighter suexec.

> Because of that, I don't think there are many setups allowing
> script execution as www-data, but yes, in such a case there is a
> side-effect with my suggestion, that most admins would not suspect.

It's rather easy to get such a setup:

aptitude install apache2 libapache2-mod-php5
a2enmod userdir

The default mod_php config allows it. Probably this should be changed.

> But I'm targeting another audience here :) One where www-data is a
> privileged user (has read access to everyone's data), and script
> execution is only allowed as the user itself using suexec.
> To circumvent the issue totally, I could modify it so that if the
> cmd is inside the docroot, then the owner of the cmd must be the
> target user. If the cmd is inside a cgi-docroot, then the owner
> must be root. (It's up to the admin to make these docroot's non
> overlapping :)).


Reply to: