exploit the possibilities

0xbadc0ded-04.txt

0xbadc0ded-04.txt
Posted Jun 14, 2004
Authored by Joel Eriksson

A remotely exploitable format string vulnerability exists in smtp.proxy up to and including version 1.1.3. The bug is present and exploitable regardless of any compile time and runtime configuration options and can be exploited by sending a message with an embedded format string in either the client hostname or the message-id.

tags | advisory
MD5 | 8ff006e1ae1e98fc101e810e7fd5cffd

0xbadc0ded-04.txt

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

==========================================================================
0xbadc0ded Advisory #04 - 2004/06/10 - smtp.proxy <= 1.1.3
==========================================================================

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

Application smtp.proxy <= 1.1.3
Discovered By Joel Eriksson <je@bitnux.com>
Researched By Joel Eriksson <je@bitnux.com>

Overview

smtp.proxy is an application level gateway for SMTP. It assures that
the data received from the client fulfills the protocol specification
before forwarding it to the server. It also offers email address
control so that only certain sender or recipient addresses is allowed
and can optionally remove the 'Received:' lines from the mail header.

Problem

A remotely exploitable format string vulnerability exists in smtp.proxy
up to and including version 1.1.3. The bug is present and exploitable
regardless of any compile time and runtime configuration options.

The bug can be exploited by sending a message with an embedded
format string in either the client hostname or the message-id, the
userspecified message-id string is obviously the most convenient to
use though. The sender address (smtp command "mail from:") is also part
of the format string, but the string is filtered for '%'-chars so it
cannot be used.

The vulnerability is caused by this piece of code in smtp.c:

snprintf (line, sizeof(line) - 2, "client= %s, sender= %s, nrcpt= %d,
size= %ld, jobid= <%s>, message-id= <%s>, status= %d",
x->client, x->sender, x->nrcpt, x->size,
x->jobid, x->msgid, rc);
// echoline(stdout, line, 0);
syslog(LOG_NOTICE, line);

The line to be logged is first formatted with snprintf() and then sent
to syslog() and parsed as a format string. Since the 'line' buffer is
a local variable and thus placed on the stack, arbitrary addresses can
be embedded into the buffer and the data on those addresses can be
written to by using the %*n format string specifiers.

Exploit

An exploit has been developed, but will be kept private for now.
Those who share our interest for exploit development may find the
following description interesting though.

Since smtp.proxy is started from a superserver, like inetd, the stack
offsets will remain constant and an attacker can use bruteforcing to
determine the unknown parameters required to exploit the vulnerability.

This means that even though it is a blind format string attack (the
output is not written back to the client) it can still be exploited
reliably by determining exploit parameters step by step. The unknown
parameters are (in the order they can be determined):

1. Offset to the format string on the stack (for embedding addresses)
2. Address to a function pointer or saved return address
3. Address to the shellcode

Determining the offset to the format string can be done by embedding
a known non-writable address in the message-id and attempting to write
into it with %*n at different stack offsets. For each offset that
causes a crash, embed a known writable addr (e.g. some high stack addr,
like 0xbffffffc for vanilla Linux/x86), and try again with the same
offset. If the daemon doesn't crash this time we have found it.

To determine the address of a function pointer we could either try to
find a saved return-address on the stack or the address of a suitable
GOT-entry by bruteforcing it. To decrease the number of attempts needed
we could use multiple writes. To see if the address is readable, so we
don't just try to write to non-mapped memory, we can use %*s. If we
cause a crash when writing to a certain (readable, and thus mapped)
address, these are the three most likely possibilities:

- We have tried to write to a read-only page
- We have written to a pointer that is dereferenced
- We have written to a function pointer or saved return address

We can determine if we have written to a read-only page by attempting
to write to surrounding addresses, if those writes also causes crashes
this is almost certainly the case.

Determining if we have written to a pointer that is dereferenced, or
perhaps an integer representing an array index or the length of a
buffer, is harder. If we don't cause a crash when overwriting with a
small integer or with a known readable and writable address we can
assume that we have not overwritten a function pointer and continue our
search. By writing the address we're writing into with the address to
itself we can also survive double dereferences.

If we pass the tests above (e.g. we still cause a crash when overwriting
with small integer values and other valid addresses, including the
address we write into to see if we have overwritten a pointer to a
pointer) then we can be reasonably sure that we have found a function
pointer. Let's start searching for our shellcode.

If we have embedded our code into the message-id it will be located on
both the heap in a malloc()'ed buffer and on the stack. The message-id
buffer is only 200 bytes large though, so unless the host has a
non-executable stack we are better off embedding our code in the 2048
bytes large line buffer on the stack in receive_data()'s stack frame.

Since fgets() is used to read lines, we can use a line like:

.<NUL-byte><NOPs><Code>

to terminate the message. A single dot indicates the end of the message
after the DATA-command has been sent. fgets() ignores NUL-bytes and
reads bytes into the buffer until a newline has been read or until the
buffer is full. This means we can stuff 2046 bytes of NOPs + shellcode
into the buffer, and thus use a stepsize of 2046 minus the length of the
shellcode when bruteforcing the shellcode address on the stack to be
certain to hit it.

Fix

Upgrade to smtp.proxy 1.3.3. When this vulnerability was discovered 1.1.3
was the latest announced version, and it is still the version available from:

http://www.quietsche-entchen.de/software/smtp.proxy.html

The author, Wolfgang Zekoll, has informed me of the previously unannounced
version 1.3.3, that is not vulnerable for this problem. After waiting over
one week for a response from the author that he has officially announced
version 1.3.3 we discovered that he announced it the same day as we reported
the problem. The page above is not yet updated, but version 1.3.3 is available
from:

http://www.quietsche-entchen.de/cgi-bin/wiki.cgi/software/smtp.proxy.yawk

Make sure you check that the URL is at quietsche-entchen.de before following
the download URL though, since it's a Wiki and anyone can edit the page...

Disclosure Timeline

2004/06/01 Notified the smtp.proxy developer (Wolfgang Zekoll)
2004/06/10 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAyBJQqnq6VG/4jhQRAnHUAJ9tKNGuxwwD/FgZjCuXV3Sn+Ka+zACdEYCd
N34z7nqSUzQUPIQ2eJIQ3aA=
=/KiB
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

October 2020

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close