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
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 :)).