How server names can compromise IE

A boundary error problem, which can be triggered by an especially long server name, may allow remote attackers to run arbitrary code on affected systems. Secunia, which credits this report to Rodrigo Gutierrez, says this vulnerability has been proven to exist in Windows XP even though the problem was thought to have been fixed by the service packs mentioned above.

Gutierrez has actually published an exploit demonstration for this problem, which was described in a Microsoft Knowledge Base Article (322857). The vulnerability occurs when IE is used to map a network drive, and the name of the drive contains more than 300 characters. Gutierrez was also credited in that June 23, 2003, Knowledge Base Article (he reports having initially told Microsoft about it in 2002).

From the meager information in the article, it isn't clear whether the problem was fixed in SP1 for WinXP and SP4 for Win2K as far as the 300-plus mixed case or lowercase characters are concerned. The actual problem confirmed by Gutierrez specifically refers to long names that contain no lowercase characters (he uses a string of -AAA...A" to demonstrate the exploit).

Additionally, although article 322857 and the released service packs covered WinXP and Win2K systems, any Windows operating system after 3.1 that shipped with or was updated to run IE 5.01 or later is also apparently vulnerable. The Secunia report on this threat contains an update confirming that Windows NT 4.0 is affected. Windows Server 2003 apparently isn't vulnerable.

It appears that this vulnerability affects all Windows operating systems that have IE 5.01, IE 5.5, or IE 6 installed, with the only exception being Windows Server 2003.

Secunia rates this vulnerability as highly critical.

Users would have to visit a malicious site or connect to a malicious file server. You can't create such a long filename under Windows, but the initial report explains how an attacker can easily do this using a Linux/Unix Samba server.

Since at least a portion of the vulnerability remains after the first Microsoft fix was installed, there is currently no patch that will block this problem. As a workaround, you should use firewall settings to restrict access to systems on your LAN that could be compromised by one of these attacks.

As a workaround, Gutierrez recommends that you alter your network connections settings by disabling Client for Microsoft Networks (presumably, you can disable the Workstation service in Windows NT 4.0 to accomplish the same thing).

Just when you thought it was safe to allow your Web browser to look at remote servers, it turns out that a simple buffer overrun problem we thought was fixed almost a year ago is still alive and well. Please note that I specifically did not provide a link to the original report simply because it contains a detailed exploit for this vulnerability, and I don't want to make it any easier to locate than it already is.

TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.

©2004 TechRepublic, Inc.