[Secure-testing-team] Statement regarding PHP safe mode bugs

[Florian Weimer]

Here's my old draft for an official statement regarding PHP safe mode
bugs (or more, generally speaking, bugs which can only be exploited by
malicious or vulnerable PHP scripts).  Recent events suggest that we
should publish something to describe the focus of our security
support.

Things that need updating:

  * Explict mention of PHP kernel bugs (like the disclosed reference
    counting issue).  In their impact, they are safe mode bugs as
    well, but this should be made more clear.

  * Somehting about suPHP.

  * Something about running separate web servers.

I haven't got much time to work on this right now, so feel free to
take over the document and bring it into shape.  I hope it's a
reasonable starting point.

#use wml::debian::template title="PHP's Safe Mode and Security"

<p>PHP offers a feature called
<a href="http://de3.php.net/features.safe-mode">Safe Mode</a>,
which is supposed to restrict what untrusted PHP scripts can do when the
web server interprets them.  Unfortunately, the Safe Mode feature
does not reliably provide security.  Therefore, the Debian Security
Team does not support its use to protect against maliciously written
PHP scripts.</p>

<h2>Architectural Issues</h2>

<p>Even the PHP developers admit that the design of PHP Safe Mode is
"architecturally incorrect".  Why is this so?</p>

<p>PHP tries to reimplement some of the security checks multi-user
operating systems (like Debian GNU/Linux) perform to isolate multiple
users on the same system and prevent them from accessing other users'
resources without their consent.  PHP performs its checks well before
the potentially malicious operation is executed, and these checks
reside in completely separate program code.  Therefore, it is likely
that these checks are too lenient and miss dangerous operations, which
are then executed by the operationg system.</p>

<p>More concretely, many of the libraries PHP scripts can use were
written with the assumption that the application is trusted.  For
example, they do not check some input data for correctness (which is
usally not transmitted over the network, such as internal file names),
or they assume that the application uses the library programming
interface in the documented manner, calling functions in a particular
order.  By design, these libraries cannot enforce the Safe Mode
restrictions on their own, which means that as soon as they implement
some functionality which reads or writes to the file system or permits
the invocation of arbitrary subprograms, PHP's restrictions are easily
bypassed.  PHP tries to address this by filtering access to the
dangerous functions, but experience shows that again and again, new
dangerous functions are discovered.</p>

<p>These design problems imply that Safe Mode offers only very weak
protection against untrusted PHP scripts written by malicious authors.
They also lead to a high rate of bug fixes related to the Safe Mode
feature.</p>

<h2>Security Team Support for Safe Mode</h2>

<p>The Debian Security Team does not support Safe Mode.  This means
that no security updates will be issued for PHP security defects which
can be exploited only by specially-crafted PHP scripts, or PHP scripts
suffering from PHP command injection vulnerbilities.</p>

<p>This decision is based on the on two observations: Most PHP users
are small-scale users, not service providers.  As a result, they do
not have to deal with the challenge of multiple users who need to
write PHP scripts which run on the web server, but do not trust each
other.  These users would not benefit directly from security updates
related to Safe Mode.  Even worse, security updates, like all changes,
come at a cost, for example in terms of stability and scheduled
downtime, and should be avoided if possible.</p>

<p>In addition, PHP security updates are always a significant effort
because the upstream developers usually do not provide isolated
security patches, only new releases.  According to the security
backporting policy, the Security Team is forced to reverse-engineer
the changes from one PHP version to another, to recover a minimal
patch which just fixes the security issue.  The number of updates
related to Safe Mode makes this process very time-consuming.</p>

<p>Therefore, the Debian Security Team allocates its resources to
other tasks, according to the needs of the Debian community.
Consequently, PHP defects which can be exploited by maliciously
written PHP scripts which are not related to Safe Mode will
not be addressed in official security updates, either.</p>

<h2>Alternatives</h2>

<p>Most large ISPs who run customer PHP scripts on shared hosting
servers do not use <code>mod_php</code> (or other forms of direct
integration into a web server), but use the CGI version of PHP, <a
href="http://httpd.apache.org/docs/suexec.html">suEXEC</a>, and a
different user account for each customer and proper permissions.  This
way, the operating system enforces the usual restrictions.</p>

<p>In such an environment, it is important to restrict the number of
installed SUID and SGID applications, to prevent local privilege
escalation, and promptly apply security-related kernel updates.  A
host-based intrusion detection system is also strongly recommended.
This means that this approach is far from ideal, but experience from
ISPs suggest that the necessary level of security can be achieved.</p>

<p>Of course, it is possible to enable Safe Mode as an additional
layer of defense.  However, as the only layer, it is far too weak.</p>