WebLogic Connector JSESSIONID Stack Based Buffer Overflow

Posted on: 2009-03-02 by Guido Landi, SD-Team

Hi there, it seems that it's up to me to write about a fine vulnerability. It's one of the vulnerabilities patched by the CPU 2009 and there are no informations of any kind regarding the bug. Advisories say something like:

"Unspecified vulnerability in the Oracle BEA WebLogic Server Plugins for Apache, Sun and IIS web servers component in BEA Product Suite 10.3, 10.0 MP1, 9.2 MP3, 9.1, 9.0, 8.1 SP6, and 7.0 SP7 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors."

The vulnerability lies in the connector between IIS and WebLogic. The Oracle's application server is not usually exposed directly but it is instead accessed through a webserver with the connector installed. The web server act as a reverse proxy and protect WebLogic.
Since there are no public informations I had to reverse engineer the patch provided by Oracle: it's a stack based buffer overflow triggered by a copy of a string controlled by the attacker in a statically allocated buffer.

Here is the vulnerable function HttpExtensionProc:





if you are an expert you could already see that the function seems interesting. After the initialization of the Structured Exception Handler the _alloca_probe() function in called, it simply substracts a value from ESP and allocates a memory area on the stack. You can expect that this zone will be used to store data and, if you are looking for a vulnerability, you can hope that the copy operation has no boundaries checks.


In the same function, after a while, we find a call to sprintf() and one of the two arguments passed to it are controlled by the attacker::





even if the function copies memory without checking size, due to the limits imposed by the web server on the maximum length of a request, the sprintf() doesn't reach pointers that we could overwrite to divert the application flow.


The possibility to execute arbitrary code is possible because of the instructions that follow:





"REPNE SCASB" search for the value in EAX starting at the zone pointed by EDI and store the number of bytes processed in ECX: it is an inline implementation of strlen(). "REP MOVSD" instead copies 'ECX' bytes from the zone pointed by ESI: it is an inline implementation of strcpy(). It's because of the latter instruction that we can reach and overwrite the SEH pointer inizialized at the beginning of the function and achieve arbitrary code execution.