Re: PHP security (or the lack thereof)
On Fri, 23 Jun 2006, Crispin Cowan wrote:
> nabiy@xxxxxxxxxxx wrote:
> > Trying to make the language 'safe' won't fix it because the language
> > is not the problem. The real problem is the way PHP is presented to
> > most new developers.
> >
> > * snip *
> >
> That is a fascinating perspective.
>
> Web developers who work with static content (HTML and images, etc.) is
> pretty secure: the security threat amounts to Apache configuration
> (directory browsing and htpasswd stuff) and it is pretty difficult for
> an attacker to corrupt static content by way of the content.
>
> Dynamic content, while not inherently dangerous, becomes dangerous when
> you hand the web developer a Turing-complete language. Suddenly the
> exact behavior of the web site under arbitrary input becomes
> undecidable. Programmers (mostly) know this. Security developers
> (should) know this. Web artists may have just been introduced to
> programming to get their web site to be dynamic.
>
This is true, of course, even with basic shell scripts -- give a user
CGI or the ability to launch any sort of program that can access data
outside of the user's own directory, and you already have potential
security problems. It's not even necessarily confined to running an
application; it could be as simple as allowing Server Side Includes,
permitting something like:
<!--#include file="/etc/passwd"-->
> There are two possible approaches to fixing this. One, as nabiy
> suggests, is to change how PHP is presented to web developers. Label it
> as a chain saw, and point out that chain saws don't know the difference
> between "log" and "leg" :)
>
CGI-bin routines and SSIs are not chainsaws, but they might qualify at
least as hedge trimmers... Full-blown tools like perl and PHP certainly
do. And for exatly that reason, my feeling is that the ability to
tap into these ought to not be granted by default -- it's almost as if
you should need to have legitimately obtained a driver's license of sorts
to be able to operate equipment like this on a public highway.
> The other is to contrive a language that is both sufficient for dynamic
> web content development, and also *not* Turing-complete. I have no idea
> what such a language might look like, or even whether the intersection
> of these two requirements is the null set.
>
The problems with granting any sort of CGI permissions to the user
automatically gives out carte blanche to employing a huge variety of
scripts or executables, as others have pointed out.
So instead of restricting things on the language level, another option is
to create a specific wrapper that will launch a specific user app, and
only that specific user app. It requires that trust is granted to the
specific routine and of course, it should be launched with careful
consideration as to what UID it runs as. Apparmor, I presume, would fall
under this category. There are also a number of Apache options that deal
with running jailed or restricted code. However, even with restrictions
on what can be run, argument passing still remains a big issue, especially
if dynamic content is desired.
Furthermore, what features you trust someone with may not be universal for
any given installation. Undoubtedly, someone will come up with a
justification for needing more than one is initially willing to grant, and
so a power struggle is likely to ensue over who gets what priviledges.
This, in turn, quickly could escalate into a hopelessly complex
administrative issue, requiring constant monitoring of potential security
issues on an individual basis.
This is a very fuzzy area and I agree with Dr. Cowan that there are no
simple answers. The crux of the matter is that once you let the users
start employing any dynamic languages, it becomes potentially a huge time
sink, either because of the time and effort needed to administer the
environment or the resources needed to deal with security issues that are
bound to result because of it. Freedom has its price.