lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 14 Aug 2007 21:09:42 -0400 (EDT)
From: "Steven M. Christey" <>
Subject: Re: PHPCentral Login Script Remote Command Execution Vulnerability

Magnus Holmgren said:

>[the superglobals] shadow everything - you cannot define your own
>$_SERVER array, nor can it be overridden with HTTP GET or POST
>values. If that were possible, using the superglobals would be
>useless; all scripts would be vulnerable unless register_globals is

This EXACT problem occurred in older versions of PHP, at least 4.x if
I recall correctly, although I can't dig up which versions were
affected.  Now, you could argue that this is the PHP interpreter's
fault, so the applications shouldn't be held accountable, but we see a
lot of reports like this one - and I bet they work in many
environments.  Then there's the unset() vulnerability [1] and other

Ignoring register_globals, there's still dynamic variable evaluation
[2], extract(), and other variable-overwriting constructs, from which
I suspect even the superglobals aren't always protected, although
these constructs don't seem to be used very heavily.

>Now, register_globals has defaulted to off ever since PHP 4.2.0.

This is a reasonable argument.  However, many hosting sites and
applications still enable or require it.  The mass compromises of web
servers for botnets, as described by Gadi Evron [3], were probably
made possible due to this setting (and allow_url_fopen).

>And it would of course be nice if people posting to Bugtraq actually
>tested their PoCs first.

This would be nice, but as you see, sometimes a "fake" isn't always so
immediately identified, thanks to the colorful, complicated history of
the PHP interpreter itself [4] [5] [6].

- Steve

[1] Zend_Hash_Del_Key_Or_Index Vulnerability
   Stefan Esser

[2] Dynamic Evaluation Vulnerabilities in PHP applications

[3] "Web server botnets and hosting farms as attack platforms"
    Gadi Evron, Kfir Damari & Noam Rathaus, Virus Bulletin, February 2007

[4] $GLOBALS Overwrite and it's Consequences
    Stefan Esser

[5] PHP import_request_variables() arbitrary variable overwrite
    Stefano Di Paola


Powered by blists - more mailing lists