.comment-link {margin-left:.6em;}
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.
vuln: str_replace("./","",$path);
attack: "../..//../..//../..//etc/passwd"
result: "../../../etc/passwd"
while
vuln: str_replace("../","",$path);
attack: "../.../.././../.../.././../.../.././../.../.././../.../.././../.../.././etc/passwd"
result: "../../../../../../etc/passwd"


This isn't anything new.
 
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:
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?
 
  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!
 
This public blog will be a place for me to output any Security findings, both technological and physical, that I have come about. I will post Security advisories I was apart of, and also other interesting bits of knowledge. email: xavier [at] tigerteam.se

RECENT RELEASES
Rocks Clusters <=4.1 mount-loop local root
Rocks Clusters <=4.1 umount-loop local root
TSEAD-200606-6 - Rocks Clusters <=4.1 local root
xorgmodroot.py - Xorg-server 1.0 / <=X11R6.9.0-7.0 local root
TSEAD-200509-5 - Multiple Netscape.com vulnerabilities.
TSEAD-200512-3 - Multiple vulnerabilities in KISBG <=v5.1.1
fsigk_exp.py - FSIGK for Linux <=2.10-431 local root
TSEAD-200510-4 - FSIGK for Linux <=2.10-431 advisory
ritk.php - remote inclusion pentest tool
owm_exp.py - openwebmail <=2.51+ local root
perliodebug_exp.py - perlIO_debug 5.8.* local root
bankfix.py - bank card number lookup tool
TSEAD-200412-2 - AOL XSS/file read vuln
TSEAD-200412-1 - AOL redir vuln

ARCHIVES
September 2005 / October 2005 / November 2005 / December 2005 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / September 2006 / October 2006 /