[VIM] PHP interpreter problems and blaming the victim - GLOBALS etc.

[Steven M. Christey]

On Thu, 1 Feb 2007, str0ke wrote:

> The first line of code contains.
>
> require_once($GLOBALS['core']['module_path'].'/module_common.php');

OK, I'm starting to get a little worried about this trend of hacking
GLOBALS, SERVER, SESSION, FILES, etc. from a VDB perspective.

Really, what chance does any application have against a GLOBALS overwrite
when it's a PHP bug itself?  If there's no chance - then should we be
flagging these apps in VDB's?

According to Stefan Esser - "Unfortunately the register_globals mode of
PHP was not protected at all against overwritting GLOBALS from the outside
until PHP 4.3.11 and this protection had a hole before PHP 4.4.1, which
means when register_globals is turned on in PHP versions before 4.4.1 it
is possible to exploit code sequences like the one found above... PHP4 >=
4.4.1 adds checks to extract() and import_request_variables() to protect
them against overwriting the $GLOBALS variable. This however does not
protect against applications that use their own routines to globalize ...
[such as $$varname = $value]"

For PHP 5, he says "In PHP5 the $GLOBALS array is implemented as a real
superglobal, that is registered before anything else is added to the main
symbol table. This means, when it is overwritten in PHP5 it has a
different impact on the application, than in PHP4. Because it is
registered before the request variables are parsed and because there was
no (or better no working) protection in PHP <= 5.0.5 it was possible to
overwrite $GLOBALS from the outside when register_globals is turned on, or
extract() or import_request_variables() were used in an unsafe way. The
major difference between the impact on PHP4 and PHP5 is, that due to the
real superglobals nature of $GLOBALS the overwrite will not only be
visible in the scope where it happened, but in all scopes."

http://www.hardened-php.net/globals-problem

Now, from a sploit standpoint, I can see how this kind of issue is still
worth tracking, because no doubt there are many active environments out
there using vulnerable PHP versions.  But flagging these apps for GLOBALS
problems (and, presumably, other superglobals overwrites) seems incorrect
to me.  Operationally it's important, since if you're a consumer and your
app uses GLOBALS, you want to know; but CVE and some other vdb's won't
distinguish between every product that uses a vulnerable zlib, for
example.

I don't recall there being other major programming language bugs past that
introduced vulnerabilities that could not be defended against.  The Perl
format string issue only existed if your program had user-injected format
strings (which I still think is important even though it's not for code
execution).

I suspect that some XSS also stems from the PHP "XSS in error message"
problem, and then you've also got the unset() issue.  This seems to be
making things very messy.

Thoughts?  Anybody know the status of other superglobals like FILE and
SESSION?

- Steve