[17874] in bugtraq
Re: Security problems with TWIG webmail system
daemon@ATHENA.MIT.EDU (Shaun Clowes)
Fri Dec 1 12:41:33 2000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <3a2738aa.db.0@webcentral.com.au>
Date: Fri, 1 Dec 2000 16:35:38 AEST
Reply-To: shaun@securereality.com.au
From: Shaun Clowes <shaun@securereality.com.au>
To: BUGTRAQ@SECURITYFOCUS.COM
>That's not an option. Try this example script:
><quote>
><?
>echo "$HTTP_POST_VARS<br> $HTTP_GET_VARS<br> $HTTP_COOKIE_VARS";
>?>
></quote>
>
>And call it like this:
>script.php?HTTP_GET_VARS=test&HTTP_POST_VARS=test&HTTP_COOKIE_VARS=test
This behaviour varies across versions of PHP, in PHP 4.0.3 I definitely don't
get the behaviour you describe. If I use the following code under 4.0.3:
<?php
if ($HTTP_POST_VARS['hi'])
print "Defined in post vars<BR>\n";
if ($HTTP_GET_VARS['hi'])
print "Defined in get vars<BR>\n";
if ($HTTP_COOKIE_VARS['hi'])
print "Defined in cookie vars<BR>\n";
?>
and retrieve the script as
testnew.php3?HTTP_GET_VARS=&hi=hello
the script correctly identifies the variable $hi or $hi[anything] as coming
from post, get or cookies vars. Interestingly if I try it with PHP3.0.12 I get
the following message:
Warning: Illegal string index in /<path>/testnew.php3 on line 5
I would suggest the ability to override the PHP defined arrays in the way you're
describing only exists in version 3 of PHP since PHP 4 adds the configuration
directive variables_order which allows the order in which variables are defined
to be set, by default PHP defined variables are set LAST in the configuration
file examples that ship with PHP 4.
I described in our first advisory (SRADV00001) how easy it could be to introduce
security holes into PHP, especially with this ability to affect the global name
space. This is another example of that, the issue is only made more cloudy by
the variation in behaviour of different versions of PHP. I'll be speaking about
web applications security, and in particular PHP at the Blackhat Briefings in
Asia next April (http://www.blackhat.com), the crux of the issue is that it
is extremely difficult to write secure applications using the rapid web applications
development environments favoured at the moment.
In the end I certainly stand by my initial fix for the problem which did the
job of preventing ANY external input defining those configuration variables.
Cheers,
Shaun Clowes
SecureReality Pty Ltd.
http://www.securereality.com.au
