Microsoft 'wininet.dll' FTP Reply Null Termination Heap Corruption Vulnerability iDefense Security Advisory 02.13.07 http://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: http://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. http://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 (http://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 http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://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@private 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.
This archive was generated by hypermail 2.1.3 : Thu Feb 15 2007 - 19:15:33 PST