Antony Dovgal wrote:
> Hello Andrew.
>
>> I think it would take two things to properly mitigate this vulnerability:
>> 1) Patching PHP to add in new ini settings in parallel to those in
>> suexec, and advising that a script which forces those ini options to be
>> set before calling the binary, rather than the PHP binary itself, should
>> be installed.
>
> It's been agreed that we won't implement any more security hacks in PHP
> itself
> since such things should be done by the OS, so no more magic INI settings.
>
> The only "magic" thing that is left at the moment is open_basedir and even
> this
> might be bypassed by some external library directly using open(), even though
> we do try our best to prevent that.
Although surely protecting scripts which have just been elevated to a
different privilege level by the suexec wrapper from arbitrary code
execution is a rather different type of protection than trying to
implement file-level security in the OS.
In this case, the INI settings would control what code is initially run
when started via suexec. Once we are sure we are running the correct
code, there would be no need for further intervention by PHP in what the
script does - so unlike open_basedir, the INI settings only affect a
very local part of the code (the cgi SAPI).
Properly implemented suexec wrapped FastCGI seems to be the most
promising way to allow the operating system to apply protection without
sacrificing too much performance.
If PHP doesn't impose any restrictions on what script suexec invoked
php-cgi runs, then how do you propose that the OS could be used to
provide this security? The chain of execution is:
Apache (web user) => suexec (root => normal user, takes many security
precautions)
=> php-cgi (normal user, currently will run any requested PHP
script)
=> PHP script (normal user, if properly written can take security
precautions)
Caution is generally expected for programs which run with elevated
privileges (setuid programs and programs invoked by them); this type of
security is quite distinct from programs imposing access controls in
addition to those of the OS.
If PHP stays as it is now, the only adequate security measure is really
to never install PHP in the web space on suexec enabled systems (or have
sysadmins patch PHP from the standard one to protect themselves), which
essentially means either having a PHP running all the time per user in
external FastCGI mode (probably not an option for shared hosting), or
running everything as the web user (which means any user on shared
hosting can read each others database passwords, write in directories
the authorised script can write in and so on). As such, I submit that
not fixing this issue means moving away from allowing the OS to provide
the security, and back towards forcing PHP to provide access control.
>
>> 2) Fixing the documentation to ensure that sysadmins are well informed
>> about the risk and how to avoid it.
>
> I'm sure the documentation team (CCed) would be happy to improve the manual.
> Do you have any certain ideas on what and how to improve?
I think unless there is a fix for the issues discussed above, the only
proper solution is a warning that running PHP in an suexec environment
is not safe.
Kind regards,
Andrew
