Microsoft 'wininet.dll' FTP Reply Null Termination Heap Corruption
Vulnerability

iDefense Security Advisory 02.13.07
https://labs.idefense.com/intelligence/vulnerabilities/
Feb 13, 2007

I. BACKGROUND

The WinInet module provides access to common Internet protocols, including
FTP and HTTP, allowing a programmers to add this functionality to their
code without having to re-impelement the details. As an part of the base
operating system, it is used in many applications including Microsoft's
Internet Explorer. More information on the WinInet module is available at
the following link:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/portal.asp

II. DESCRIPTION

Remote exploitation of a design error in Microsoft Corp.'s 'wininet.dll'
FTP client code could allow an attacker to execute arbitrary code.

The vulnerability specifically exists in the parsing of reply lines from
remote FTP servers. During an FTP session, the client makes requests for
the server to perform some operation and the server responds with a
numeric code, a human readable message and possibly some other
information. As there can be multiple lines in a reply, code in the client
breaks the reply up into lines, putting a null byte (character 0x00) after
any end of line character. In the case where a line ends exactly on the
last character of the reply buffer, the terminating null byte is written
outside of the allocated space, overwriting a byte of the heap management
structure. By sending a specially crafted series of replys to the client,
the heap may be corrupted in a controlled way to cause the execution of
arbitrary code.

III. ANALYSIS

Successful remote exploitation of this vulnerability would allow a attacker
to execute arbitrary commands in the context of the currently logged in
user.

In order to exploit this vulnerability, the attacker must convince the
target to follow a link in a program which uses the vulnerable functions,
such as Internet Explorer, Word, or Outlook. For any of these applications
it is sufficient to embed an image linked to a malicious ftp server, but
for modern versions of Outlook, the image will not render unless the user
allows it.

In testing by iDefense Labs, server responses were generated which put
controlled values into controlled memory locations in Internet Explorer,
with varying degrees of success on a system running Windows XP SP2.
Although methods applied during initial testing were unreliable, they did
indicate that it was possible to use this vulnerability to cause code
execution.

The portion of the heap management structure overwritten is used to
determine the length of the allocation it refers to. In combination with
another less severe vulnerability in the FTP code, which allows a remote
attacker to see a valid memory address, it may be possible to cause
reliable remote exploitation.

IV. DETECTION

iDefense has verified that Internet Explorer 6 on the following Microsoft
operating systems, with all security patches applied as of May 2006, are
affected:

  Windows 2000 Advanced Server SP4  
  Windows XP SP2  
  Windows Server 2003 Enterprise Edition SP1

This vulnerability appears to have existed from at least Internet Explorer
5.0. It is suspected that all versions of Internet Explorer on all
supported platforms are affected.

V. WORKAROUND

iDefense is unaware of any effective workarounds for this vulnerability.
Blocking outgoing port 21 (ftp) requests is not effective, as this it is
possible to supply an ftp URL with an alternative port. It may be possible
to limit exposure to this vulnerability by configuring systems to use a
proxy server for all ftp requests and only allowing white-listed sites.

VI. VENDOR RESPONSE

Microsoft has addressed this vulnerability within MS07-016. For more
information, consult their bulletin at the following URL.

https://www.microsoft.com/technet/security/Bulletin/MS07-016.mspx

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CVE-2007-0217 to this issue. This is a candidate for inclusion in
the CVE list (https://cve.mitre.org/), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

08/16/2006  Initial vendor notification
08/16/2006  Initial vendor response
10/05/2006  Second vendor notification
02/13/2007  Coordinated public disclosure

IX. CREDIT

This vulnerability was discovered by Greg MacManus, iDefense Labs.

Get paid for vulnerability research
https://labs.idefense.com/methodology/vulnerability/vcp.php

Free tools, research and upcoming events
https://labs.idefense.com/

X. LEGAL NOTICES

Copyright © 2006 iDefense, Inc.

Permission is granted for the redistribution of this alert electronically.
It may not be edited in any way without the express written consent of
iDefense. If you wish to reprint the whole or any part of this alert in
any other medium other than electronically, please e-mail
customerservice@idefense.com for permission.

Disclaimer: The information in the advisory is believed to be accurate at
the time of publishing based on currently available information. Use of
the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on, this
information.