bugtraq - Re: PHPCentral Login Script Remote Command Execution Vulnerability

lists.openwall.net		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 linux-cve-announce 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]

Message-Id: <200708150109.l7F19gux025047@faron.mitre.org>
Date: Tue, 14 Aug 2007 21:09:42 -0400 (EDT)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
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
>off.

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
variants.

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
   CVE-2006-3017
   Stefan Esser
  http://www.hardened-php.net/hphp/zend_hash_del_key_or_index_vulnerability.html

[2] Dynamic Evaluation Vulnerabilities in PHP applications
    http://www.securityfocus.com/archive/1/432828

[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
    http://www.hardened-php.net/globals-problem

[5] PHP import_request_variables() arbitrary variable overwrite
    Stefano Di Paola
    http://www.securityfocus.com/archive/1/archive/1/462263/100/0/threaded

[6] http://www.hardened-php.net/advisories.15.html