Xavier's Security Post
Friday, March 31, 2006
Directory transversal in a can.
Well, not really in a can, more in a bug, or two. I've always found directory transversal bugs to be fun, and that goes way back to when CGI (common gateway interface) was the way to go. now, you have PHP, and numerous other dynamic web structures. They usually suffer the same kind of bugs, simply because of programming error; it should be known by now that developers should use absolute urls, defined internally.
I've recently audited a few smaller projects that used str_replace to strip out "../" or even "./". The problem with that is that it is very much defeatable.
This isn't anything new. ¶ 3/31/2006 09:33:00 AM 0 comments
I've recently audited a few smaller projects that used str_replace to strip out "../" or even "./". The problem with that is that it is very much defeatable.
vuln: str_replace("./","",$path);while
attack: "../..//../..//../..//etc/passwd"
result: "../../../etc/passwd"
vuln: str_replace("../","",$path);
attack: "../.../.././../.../.././../.../.././../.../.././../.../.././../.../.././etc/passwd"
result: "../../../../../../etc/passwd"
This isn't anything new. ¶ 3/31/2006 09:33:00 AM 0 comments
Wednesday, March 29, 2006
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:
Quickly, Stefan Esser replied with:
He went on to conclude:
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:
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 0 comments
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
trusted party.
Quickly, Stefan Esser replied with:
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.
He went on to conclude:
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
this issue.
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:
<?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:
$user="usernamehere";
$password="mysqlpasswdhere";
$server="127.0.0.1";
$foobar=html_entity_decode($_GET['foo']);
printf("html_entity_decode: %s<br>", $foobar);
?>
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 0 comments
Neglection!
Oh my! I sure have left this blog idle for a bit too long, I was starting to miss it! I'll soon post some new True Cracks, and get this show on the road again!
¶ 3/29/2006 11:14:00 AM 0 comments