Memory leak: PHP 4.x/<5.1.3-RC1 Yesterday an individual posted a quasi-advisory on Full Disclosure which caught my eye, for it spewed out text concerning a possible local/remote vulnerability in PHP. The poster was teeter-tottering on the verge of FUD (fear, uncertainty, doubt) almost nervously seeping across the screen and asking developers of PHP sites/projects to filter out all non-usable ASCII characters. He concludes with:

More details to come when we have PHP patches distributed with major
distributions. I might disclose details before to some IDS vendor or other
trusted party.

The title of the post wickedly titled "Critical PHP bug - act ASAP if you are running web with sensitive data", I'm sure he caused a small scare.

Quickly, Stefan Esser replied with:

Hello,

just to stop this:

The bug is a binary safety issue in html_entity_decode. A function that
is not usually used on user input, because user input is usually not
expected in HTML format and then decoded. Even if the function is used
on user input it can only leak memory to a potential attacker if the
decoded user input is send back to the client.

I love how he throws up "just to stop this:" in the mix, almost hinting at the B.S involved in the tree of posts between the original poster and others.

He went on to conclude:

The bug was found in late February by one of the japanese PHP developers
and was fixed in CVS one day later. Because the bug is a local memory
leak it was not considered top critical and is among the usual bugfixes.
PHP 5.1.3-RC1 which was released in the beginning of March already fixes
this issue.

The vulnerability very much exists, and affects a nice chunk of the web. The catch is though, the function vulnerable to the memory leak is rarely used on web applications--which doesn't say much, clever attackers are capable of figuring out a usage.

Here is a PoC I tested on a non-busy server in my LAN; apparently on servers with high volume this can be nasty as it'll output sensitive data from other running applications:

<?php
$user="usernamehere";
$password="mysqlpasswdhere";
$server="127.0.0.1";

$foobar=html_entity_decode($_GET['foo']);
printf("html_entity_decode: %s<br>", $foobar);
?>

I executed the script above with a value of: ?foo=%00(..554 characters), and what I got was interesting. Infact, I saw not only a bunch of garbage data, but values of $user, $password, and $server. ouch, thats not nice. Screenshot below:

As you can see from the image, not only was the username and password leaked, but the mysql server value I had placed. I repeat, though this a serious vulnerability, it is unlikely you'll find many sites that actually utilize the html_entity_decode() function.

I'm sure in a situation where a secured PHP server, with safemode, safedir, execution functions disabled, and plugins lacking--you find a script that is badly coded to a point you can execute PHP code via eval. Since you can't execute arbitrary code, or do anything fancy like local file inclusion to at least read configuration files and the likes, you eval html_entity_decode() so it outputs chunk of memory, repeat rinse and recycle until you have a located a mysql login to some server. Oh, that'll be fun ;) mysqldump anyone?  ¶ 3/29/2006 11:29:00 AM