Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
iDefense Security Advisory 02.13.07: Microsoft 'wininet.dll' FTP Reply Null Termination Heap Corruption Vulnerability
From: iDefense Labs NO-REPLY (labs-no-replyidefense.com)
Date: Tue Feb 13 2007 - 14:32:06 CST
Microsoft 'wininet.dll' FTP Reply Null Termination Heap Corruption
iDefense Security Advisory 02.13.07
Feb 13, 2007
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:
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
Successful remote exploitation of this vulnerability would allow a attacker
to execute arbitrary commands in the context of the currently logged in
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
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
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.
iDefense has verified that Internet Explorer 6 on the following Microsoft
operating systems, with all security patches applied as of May 2006, are
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.
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.
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 (http://cve.mitre.org/), which standardizes names for
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
This vulnerability was discovered by Greg MacManus, iDefense Labs.
Get paid for vulnerability research
Free tools, research and upcoming events
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
customerserviceidefense.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