exploit the possibilities


Posted May 7, 2004
Authored by Joel Eriksson | Site 0xbadc0ded.org

DeleGate versions 8.9.2 and below have a remotely exploitable buffer overflow vulnerability that exists in the SSLway filter.

tags | advisory, overflow
MD5 | 445eeac5fcf2a83fe07bb922dd565578


Change Mirror Download
Hash: SHA1

0xbadc0ded Advisory #03 - 2004/05/06 - DeleGate <= 8.9.2 (SSL-filter)

Reference http://0xbadc0ded.org/advisories/0401.txt
PGP-key http://0xbadc0ded.org/advisories/pubkey.asc

Application DeleGate <= 8.9.2 (SSL-filter)
Discovered By Joel Eriksson <je@bitnux.com>
Researched By Joel Eriksson <je@bitnux.com>


DeleGate is a multi-purpose application level gateway which 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.

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.


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 I haven't investigated that

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 I 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 sendmail prescan() bug comes to mind..

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,
randomization may be considered good enough by some. 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
[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 charset such as in X509_NAME_oneline(), take a look at:



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


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

The 0xbadc0ded.org team is hosted and sponsored by Bitnux: www.bitnux.com

Bitnux is a company located in Sweden focused on security
research and system development. We offer services such as:

- Code Reviews
- Exploit Development
- Reverse Engineering of Code
- Security Revisions of Systems and Software
- Custom System Development for Unix/Linux/BSD and Windows

E-mail : info@bitnux.com
Phone : +46-70-228 64 16
Chat : http://bitnux.com/live

Version: GnuPG v1.2.1 (GNU/Linux)

Login or Register to add favorites

File Archive:

January 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jan 1st
    2 Files
  • 2
    Jan 2nd
    0 Files
  • 3
    Jan 3rd
    20 Files
  • 4
    Jan 4th
    4 Files
  • 5
    Jan 5th
    37 Files
  • 6
    Jan 6th
    20 Files
  • 7
    Jan 7th
    4 Files
  • 8
    Jan 8th
    0 Files
  • 9
    Jan 9th
    0 Files
  • 10
    Jan 10th
    18 Files
  • 11
    Jan 11th
    8 Files
  • 12
    Jan 12th
    19 Files
  • 13
    Jan 13th
    31 Files
  • 14
    Jan 14th
    2 Files
  • 15
    Jan 15th
    2 Files
  • 16
    Jan 16th
    2 Files
  • 17
    Jan 17th
    18 Files
  • 18
    Jan 18th
    13 Files
  • 19
    Jan 19th
    15 Files
  • 20
    Jan 20th
    29 Files
  • 21
    Jan 21st
    12 Files
  • 22
    Jan 22nd
    0 Files
  • 23
    Jan 23rd
    0 Files
  • 24
    Jan 24th
    17 Files
  • 25
    Jan 25th
    34 Files
  • 26
    Jan 26th
    23 Files
  • 27
    Jan 27th
    0 Files
  • 28
    Jan 28th
    0 Files
  • 29
    Jan 29th
    0 Files
  • 30
    Jan 30th
    0 Files
  • 31
    Jan 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2020 Packet Storm. All rights reserved.

Security Services
Hosting By