Four New Unpatched Windows Vulnerabilities

peeon writes "Right before Christmas, four new Windows NT/2k/XP vulnerabilities were posted to the Bugtraq list. This story discusses two of the vulnerabilities in the LoadImage function (buffer overflow) and Windows Help program (heap overflow), but the Chinese company discovered two more exploits in the parsing of a specially crafted ANI file (causes DoS). A Bugtraq posting has more details."

Comments

bugtraq links for the vulnerabilities / demo

[tsager]

Demonstration of exploits:
http://www.xfocus.net/flashsky/icoExp/index.html

http://www.derkeiler.com/Mailing-Lists/securityfoc us/bugtraq/2004-12/0387.html
http://www.derkeiler.com/Mailing-Lists/securityfoc us/bugtraq/2004-12/0360.html
http://www.derkeiler.com/Mailing-Lists/securityfoc us/bugtraq/2004-12/0359.html

(Source: http://www.heise.de/newsticker/meldung/54610 [German])

Re:I don't get it....

[cnettel]

This doesn't have to apply to kernel stuff. A lot of Windows apps rely on for example the "common controls" API. It handles toolbars, tooltips, listviews and so on. Quite a lot of UI goodies. Most of those are implemented without any kernel side, they're normal user mode controls/"windows" with their own drawing.

Now to the point: This DLL was updated quite a few times with Internet Explorer 3, 4 and 5. The versions in Windows 98, 2000 and XP are/were directly related to the matching (sub-)version of Internet Explorer. If you wrote an app for Win-95 and wanted to use one of those common controls, the recommended redistribution scenario was redistributing IE.

If they simply ripped out anything that is officially part of the "IE codebase", it's completely true that quite a few apps would fail.

This is of course even more true of some of other APIs with a more apparent connection to Internet Explorer, like WinInet for interacting with HTTP/FTP without doing sockets yourself (and using the IE cache and other stuff) or employing the IE HTML/XML parsing and possibly rendering hosted in another application. I chose common controls because they're very frequently used, and some quite significant updates were introduced through IE. These updates are still there in "Win98 lite" and whatever you would do to a Windows system to rip out IE, but retain a reasonable level of compatibility. Just because it's part of the OS and a frequently used API doesn't mean it's kernel mode. And very little IE related code is *in the kernel*.

Now to the point: LoadImage is quite a low level function. Display drivers are allowed to use it on their own and modify its functionality. That makes it belong in kernel mode. Even if they moved back some more UI stuff from the kernel, stuff like this probably belongs there, if you buy the concept of placing display drivers in kernel mode at all.