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.
	
	...