[NEWS] DeleGate SSL Filter Buffer Overflow

• Previous message: SecuriTeam: "[UNIX] PHPX Multiple Vulnerabilities"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: list@securiteam.com
Date: 6 May 2004 19:53:35 +0200

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

  DeleGate SSL Filter Buffer Overflow
------------------------------------------------------------------------

SUMMARY

 <http://wall.etl.go.jp/delegate/> 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.

DETAILS

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(c) 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(c) 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>
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));

Disclosure Timeline:
2004/05/02 Notified the DeleGate team
2004/05/05 DeleGate 8.9.3 was released with fix (without notifying us)
2004/05/06 Public release

ADDITIONAL INFORMATION

The information has been provided by
<mailto:je-fulldisclosure@bitnux.com> Joel Eriksson.

The original article can be found at:
<http://0xbadc0ded.org/advisories/0401.txt>
http://0xbadc0ded.org/advisories/0401.txt

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

• Previous message: SecuriTeam: "[UNIX] PHPX Multiple Vulnerabilities"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]