Delegate Ssl Filter Buffer Overflow

Full Version: Delegate Ssl Filter Buffer Overflow

GovernmentSecurity.org > The Archives > Exploit Articles

qcred11

May 6 2004, 05:53 PM

QUOTE

DeleGate is "a multi-purpose application level gateway that runs on a variety of platforms, such as Unix, Windows, MacOS X and OS/2. DeleGate can be used to mediate communication of various protocols, including but not limited to HTTP, FTP, NTTP, SMTP, POP, Telnet and SOCKS. It has the ability to apply caching and conversion for mediated data, access control from clients and routing towards servers. It is also able to translate between protocols and apply SSL (TLS) to arbitrary protocols".

A remotely exploitable buffer overflow vulnerability exists in the SSLway filter that is used when SSL should be applied to a client or server connection.

Vulnerable Systems:
* DeleGate version 8.9.2 and prior

Immune Systems:
* DeleGate version 8.9.3

The bug can be triggered using a certificate with field contents large enough to make the subject or issuer name larger than 256 bytes. The vulnerability is caused by this piece of code in filters/sslway.c:

static ssl_prcert(ssl,show,outssl,outfd,what)
SSL *ssl;
char *what;
{ X509 *peer;
char subjb[256],*sb,issrb[256],*is;
char *dp,ident[256];

ident[0] = 0;
if( peer = SSL_get_peer_certificate(ssl) ){
sb = X509_NAME_oneline(X509_get_subject_name(peer),subjb,1024);
is = X509_NAME_oneline(X509_get_issuer_name(peer),issrb,1024);

The second argument to X509_NAME_oneline() is the buffer to write to and the third argument is the size of that buffer. In the case above a buffer size of 1024 is specified, but the buffers are only 256 bytes large. This allows us to, for instance, overwrite the saved return address in ssl_prcert()'s stack frame.

Exploit:
X509_NAME_oneline() converts chars below 0x20 or above 0x7e to 'xHH' where HH is the hexadecimal value of the char. This makes the bug pretty hard to exploit on at least x86 Unix variants since we will usually need to write chars outside that range to construct a valid address where we can place shellcode. Creative use of a partially overwritten pointer or address is likely to be possible, but Joel hasn't investigated that thoroughly.

For instance, the "peer" or "ssl" pointers may be of use, since at least the SSL struct contains pointers to callback functions, and of course partially overwriting the saved EBP or EIP is a possibility. Any pointer that is dereferenced and written or called to can possibly be abused.

What Joel find most ironic about this flaw and other flaws where a restricted set of characters can be written is that the address space randomization feature in kernel patches such as PaX can actually make the flaws easier to exploit.

The only protection against standard return-to-lib© techniques in PaX is address space randomization, with 16 bits of entropy (e.g. 65536 possibilities). This means bruteforcing the offset can be done in a few minutes on most systems.

For bugs that the attacker only has one shot to succeed with, some may consider randomization good enough. However, in the case of daemons that handle each connection in a separate process (which is the case here) or for local SUID/SGID vulnerabilities, randomization is no adequate protection.

To create an SSL certificate that can be used to trigger this bug, it's easiest to use the OpenSSL command line tool:

[je@vudo ~]$ cat>openssl.cnf<<EOF
> [ req ]
> distinguished_name = req_dn
> prompt = no
> [ req_dn ]
> CN=bof
> 0.OU=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 1.OU=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 2.OU=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> 3.OU=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EOF
[je@vudo ~]$ openssl req -x509 -new -nodes -out bof.pem -keyout bof.pem -config openssl.cnf
Generating a 512 bit RSA private key
.........++++++++++++
..........++++++++++++
writing new private key to 'bof.pem'

For an example of an actual exploit using the return-to-lib© technique to defeat address space randomization as provided by PaX, and possibly also restricted character set such as in X509_NAME_oneline(), take a look at: http://0xbadc0ded.org/exploits/pax-poc.tar.gz

Fix:
Upgrade to DeleGate 8.9.3 or edit filters/sslway.c and change:

sb = X509_NAME_oneline(X509_get_subject_name(peer),subjb,1024);
is = X509_NAME_oneline(X509_get_issuer_name(peer),issrb,1024);

To:

sb = X509_NAME_oneline(X509_get_subject_name(peer),subjb,sizeof(subjb));
is = X509_NAME_oneline(X509_get_issuer_name(peer),issrb,sizeof(issrb));

T3cHn0b0y

May 6 2004, 07:04 PM

So theres room for approx 700-800 bytes of shellcode? Man, how can a programmer (filtered) up on something that simple...why 1024? Surely he must have thought about what figure he was typing whilst doing it! This makes me slightly suspicious!

radien

May 7 2004, 02:53 PM

Very glad to know Delegate, Thx for info

totof

May 7 2004, 06:16 PM

hwo do you do to compile that

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.