CVE:  CAN-2003-0161
CERT: VU#897604

  ********************************************************
  *** FORCED RELEASE -- VENDOR NOTIFIED AS OF 03/18/03 ***
  ********************************************************

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.

I've 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.

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-03-19 00:21 --

 [ http://lcamtuf.coredump.cx/photo/current ]







































































































































































































   Mister Trouble never hangs around
   When he hears this Mighty sound:
   "Here I come to save the day!"
   That means that Mighty Mouse is on the way!
   Yes sir, when there is a wrong to right
   Mighty Mouse will join the fight
   On the sea or on the land
   He gets the situation well in hand
   So though we are in danger
   We never despair
   'Cause we know that where there's danger
   He is there!
   He is there! On the land! On the sea! In the air!
   We're not worryin' at all
   We're just listenin' for his call:
   "Here I come to save the day!"
   That means that Mighty Mouse is on the way!






































   Mr. Trouble never hangs around
   When he hears this mighty sound...
   "Here I come to save the day!"
   That means that Mighty Mouse is on the way.
   Yessir when there is a wrong to right
   Mighty Mouse will join the fight
   On the sea or on the land
   He gets the situation well in hand
   So though we are in danger
   We never despair
   Cause we know that where there's danger
   He is there!
   He is there!
   On the land!
   On the sea!
   In the air!
   We're not worryin' at all
   We're just listenin' for his call
   "Here I come to save the day!"
   That means that Mighty Mouse is on the way!