More details to come when we have PHP patches distributed with majorThe 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.
distributions. I might disclose details before to some IDS vendor or other
Hello,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.
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.
The bug was found in late February by one of the japanese PHP developersThe 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.
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
<?phpI 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:
printf("html_entity_decode: %s<br>", $foobar);