6th Apr 2003 [SBWID-6102]
COMMAND
Sendmail remote heap overflow in address parser code
SYSTEMS AFFECTED
Sendmail versions 8.12.8
PROBLEM
Michal Zalewski says :
http://lcamtuf.coredump.cx
CVE: CAN-2003-0161
CERT: VU#897604
There is a vulnerability in Sendmail versions 8.12.8 and prior. The
address parser performs insufficient bounds checking in certain
conditions due to a char to int conversion, making it possible for an
attacker to take control of the application. This problem is not
related to the recent ISS vulnerability announcement.
The impact is believed to be a root compromise. I've confirmed this is
a local issue, and my initial impression is that a remote attack
possibility is not that unlikely. Only platforms with 'char' type
signed by default are vulnerable as-is, and little endian systems would
be easier to exploit. Systems that use Sendmail privilege separation
are safer against the _local_ attack, but even then it is still
possible to compromise the smmsp account and control the submission
queue.
The bug lurks in parseaddr.c in prescan() function, which, in certain
conditions, will run past the buffer size limit and overwrite stack
variables, reaching to and past the stored instruction pointer itself.
This function is called quite generously accross the code for
processing e-mail addresses.
It is possible for the attacker to repeatedly skip the length check
location in this function because of an unfortunate construction of a
"special" control value check. A special value, NOCHAR, is defined as
-1. There is a variable 'c', also used to store last read character,
declared as int, and the variable will be sometimes assigned the value
of NOCHAR to indicate a special condition.
Unfortunately, the input character - type char - defaults to a signed
type on many modern platforms, and ASCII value 0xff ((char)-1) will be
converted to 0xffffffff ((int)-1) upon assignment. This makes character
0xff indistinguishable from NOCHAR after being stored in 'c', and makes
it possible for the attacker to spoof NOCHAR and skip the length check.
Since precise control of the overwrite process is possible (length,
offset and layout are up to the attacker), even though the values are
mostly fixed, it is reasonable to expect that this vulnerability will
be easy to exploit on little endian systems. Even on big endian
systems, it might be still possible to alter important control
variables on the stack, and you are generally advised to upgrade.
-Also-
From FreeBSD security advisory [FreeBSD-SA-03:07.sendmail] :
--snip--
A remote attacker could create a specially crafted message that may
cause sendmail to execute arbitrary code with the privileges of the
user running sendmail, typically root. The malicious message might be
handled (and the vulnerability triggered) by the initial sendmail MTA,
by any relaying sendmail MTA, or by the delivering sendmail process.
Exploiting this defect is particularly difficult, but is believed to be
possible.
The defect in the ident routines is not believed to be exploitable.
--snap--
SOLUTION
I've (Michal Zalewski) notified the vendor on March 18, and got a
response on the next day. Sendmail is releasing version 8.12.9, and the
official notice is as follows:
Sendmail, Inc., and the Sendmail Consortium announce the availability
of sendmail 8.12.9. It contains a fix for a critical security
problem discovered by Michal Zalewski whom we thank for bringing
this problem to our attention. Sendmail urges all users to either
upgrade to sendmail 8.12.9 or apply a patch for your sendmail version.
Remember to check the PGP signatures of patches or releases obtained via
FTP or HTTP (to check the correctness of the patches in this
announcement please verify the PGP signature of it). For those not
running the open source version, check with your vendor for a patch.
SECURITY: Fix a buffer overflow in address parsing due to
a char to int conversion problem which is potentially
remotely exploitable. Problem found by Michal Zalewski.
Please visit http://www.sendmail.org for more details and patches, and
check with your vendor for the availability of a new or patched
package.
-Also-
From Sendmail advisory :
This version can be found at
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz.sig
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z.sig
and the usual mirror sites.
MD5 signatures:
3dba3b6d769b3681640d0a38b0eba48c sendmail.8.12.9.tar.gz
19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.gz.sig
268fc4045ba3eac6dfd9dc95d889ba5f sendmail.8.12.9.tar.Z
19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.Z.sig
SECURITY: Fix a buffer overflow in address parsing due to
a char to int conversion problem which is potentially
remotely exploitable. Problem found by Michal Zalewski.
Note: an MTA that is not patched might be vulnerable to
data that it receives from untrusted sources, which
includes DNS.
To provide partial protection to internal, unpatched sendmail MTAs,
8.12.9 changes by default (char)0xff to (char)0x7f in
headers etc. To turn off this conversion compile with
-DALLOW_255 or use the command line option -d82.101.
To provide partial protection for internal, unpatched MTAs that may be
performing 7->8 or 8->7 bit MIME conversions, the default
for MaxMimeHeaderLength has been changed to 2048/1024.
Note: this does have a performance impact, and it only
protects against frontal attacks from the outside.
To disable the checks and return to pre-8.12.9 defaults,
set MaxMimeHeaderLength to 0/0.
Do not complain about -ba when submitting mail. Problem noted
by Derek Wueppelmann.
Fix compilation with Berkeley DB 1.85 on systems that do not
have flock(2). Problem noted by Andy Harper of Kings
College London.
Properly initialize data structure for dns maps to avoid various
errors, e.g., looping processes. Problem noted by
Maurice Makaay.
...