Message-ID: <0ISP00I97427SF10@l-daemon>
Date: Fri, 06 Jan 2006 17:01:59 -0700
From: LE Backup <lucretias@...w.ca>
To: mercenary@...hmail.com, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com
Subject: RE: Windows PHP 4.x "0-day" buffer overflow


I believe using named pipes on windows has ALWAYS been known for MANY YEARS
that it was exploitable.

Products we were working on in 2003 were quite aware of this potential, and
simply don't use named pipes.

What this has to do with PHP I'm not certain either as this seems to
highlight MySQL.

Cheers,

James Friesen, CIO

Lucretia Enterprises
"Our World Is Here..."
Info at lucretia dot ca
http://lucretia.ca


> -----Original Message-----
> From: mercenary@...hmail.com [mailto:mercenary@...hmail.com]
> Sent: Wednesday, January 04, 2006 8:53 PM
> To: full-disclosure@...ts.grok.org.uk; bugtraq@...urityfocus.com
> Subject: Windows PHP 4.x "0-day" buffer overflow
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Buffer Overflow in PHP MySQL functions
>
> I.	RISK
>
> Low - Remote code execution on some systems The function is
> not normaly exposed to external users via input data
>
> II.	AFFECTED VERSIONS
>
> 4.x Branch under Windows
>
> III. 	BACKGROUND
>
> PHP contains many built-in functions to allow a developer to
> interface with MySQL servers. One of these, mysql_connect()
> contains functionality to allow a user to connect via named
> pipes to a server.
>
> IV. 	DESCRIPTION
>
> The format of the mysql_connect function is as follows:
>
> mysql_connect(host, username);
>
> The host field can accept a host in the following format when
> PHP is used on a Windows system:
>
> "hostname:/pipe"
>
> Where "pipe" is the named pipe to use. Within the internal
> code, this pipe name is later copied into a 257 byte internal
> character buffer. By supplying a long pipe variable, we are
> able to preform a classical stack based buffer overflow
> attack. From \ext\mysql\libmysql\libmysql.c line 216:
>
> HANDLE create_named_pipe(NET *net, uint connect_timeout, char
> **arg_host,
> 			 char **arg_unix_socket)
> {
> 	[...]
> 	char szPipeName [ 257 ];
> 	[...]
> 	sprintf( szPipeName, "\\\\%s\\pipe\\%s", host, unix_socket);
>
> The variable unix_socket is the value of the host string
> after the trailing colon (:), if it exists.
>
> Because we will be overflowing several pointers, the address
> of a valid memory location must also be written to memory 4
> bytes after our replacement EIP. When our EIP is restored,
> ESI will contain a pointer to the value of the "username"
> variable. This can be used as a location to store our
> shellcode, as it is a reliable location.
>
> V.	EXPLOIT
>
> This exploit was designed to work with PHP versions 4.3.10
> and 4.4.0 under Windows XP SP 1. If another operating system
> is used, the replacement EIP must be changed.
>
> The replacement EIP is written 261 bytes into our string. For
> this exploit, I used a CALL ESI from ws2_32.dll from Windows XP SP1.
>
> The replacement ESI is simply the base of the PHP image.
> Locations after this address will be overwritten with some
> internal data.
>
> Our shellcode is written into the $user variable. $two is
> used to prevent $user from being truncated with a MySQL error message.
>
> VI.	WORKAROUND
>
> None.
>
> VII.	FIX
>
> The length of unix_socket should be verified prior to use. In
> addition, the string should be formatted using a safe
> function such as snprintf, followed by a hardcoded null terminator.
>
> VIII.	POC
>
> POC is attached.
>
> -----BEGIN PGP SIGNATURE-----
> Note: This signature can be verified at
> https://www.hushtools.com/verify
> Version: Hush 2.4
>
> wkYEARECAAYFAkO8lv4ACgkQLpU3lrW2nNMlTACfeYj28WH+qaJRr+UJ41wVUkfSHd8A
> niKUfNuCT9LgoX8fjWb7oi2W5QTj
> =QoFC
> -----END PGP SIGNATURE-----
>
>


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists