Linked by Thom Holwerda on Wed 4th Jan 2006 22:45 UTC
Windows The saga around the WMF flaw in Windows continues. "A cryptographically signed version of Microsoft's patch for the Windows Metafile vulnerability accidentally leaked onto the Internet late Tuesday, adding a new wrinkle to the company's round-the-clock efforts to stop the flow of malicious exploits. The MSRC (Microsoft Security Response Center) acknowledged that a slip-up caused 'a fast-track, pre-release version of the update' to be posted to a security community site and urged users to 'disregard' the premature update."
Thread beginning with comment 81995
To read all comments associated with this story, please click here.
RE: ...
by Nathan O. on Thu 5th Jan 2006 07:04 UTC
Nathan O.
Member since:

Here's my big question I haven't seen asked yet:

How come they have to do so much testing in so many languages for a simple patch to the library that handles an image format?

Where do foreign languages come in to it? Shouldn't it be language agnostic?

In theory, couldn't they completely replace their libwmf.dll (or whatever they call it) with an entirely different one that was built to be compatible and have no reason to worry? (again, in theory)

And for cryin' out loud, there are so few places where WMF is used, and it's a relatively simple format... couldn't they just assign 50 people to testing, give each of them four computers loaded with all sorts of esoteric software, and let them test all day for one day? And let their Big Name Partners do the same for their in-house software?

How much can any patch possibly screw up an image format handler???

Reply Score: 1

RE[2]: ...
by Marcellus on Thu 5th Jan 2006 07:14 in reply to "RE: ..."
Marcellus Member since:

How much can any patch possibly screw up an image format handler???

Has it occurred to you that it's not only the image format handler that is being patched?

AFAIK, this was simply an attack vector that was vulnerable, but fixing the handler itself won't remove the underlying problems.

Reply Parent Score: 1

RE[3]: ...
by Nathan O. on Thu 5th Jan 2006 16:08 in reply to "RE[2]: ..."
Nathan O. Member since:

It occurred to me, yes, but can anyone give me an example of such a thing happening in a properly designed library?

I'm asking seriously. I'm in school for this sort of thing right now, and I'd like to know. I'll have to look up the details of the vulnerability now.

Reply Parent Score: 1

RE[3]: ...
by Nathan O. on Thu 5th Jan 2006 16:44 in reply to "RE[2]: ..."
Nathan O. Member since:

I looked this thing up on Symantec's web site (let me know if they aren't as reputable as I think), and it seems there are two reports of WMF bugs. The first was reported 11-08-05 and allows execution of arbitrary code as SYSTEM user (totally unlimited root, IIRC), and the second, dated 12-28-05, is the same, except code is run as the user viewing the file.

In both cases, it seems to be completely confined to this one library (the former is an integer overflow, the second is less descriptive, citing a single function in the library).

I still don't understand why it has to be so thoroughly tested in so many languages. I'm guessing the November buffer overflow was fixed quickly. I definitely understand, though, that the more recent one is something I understand less.

Reply Parent Score: 1

RE[2]: ...
by yawntoo on Thu 5th Jan 2006 17:04 in reply to "RE: ..."
yawntoo Member since:

Here is an answer ;-)

Take this with a grain of salt since I don't work for MS, and don't have visibility into exactly what they have been doing.

As far as I understand, the flaw is in the GDI call Escape(). This means that the pathch will likely need to be to GDI32.DLL and likely WIN32K.SYS. These are low level core components to the Win32 subsystem (the subsystem the most applications and the shell use).

So here is a bit more detail (as I understand it) into the issue:

The GDI framework is an API used to abstract away the details of graphics devices. This API is used to do basic graphics operations on video boards, and printers, and any other "display" device. Abstractions like this hide the details of the hardware from the appilcations programmer. This is a good thing.

The Escape call is a call that lets the application pass various commands to the driver without having to know the details of the driver. Most of the uses of this call are replaced with newer API calls, so this one has been around for quite a while. IIRC the issue here is that WMF files (which are really a set of GDI commands) can also contain Escape calls that will set a callback into arbitrary code (AbortProc). The proper use for this value is for an application to be able to tell the print driver to notify it if the print job has been canceled. However, a callback is a callback, and a malicious coder can make them do all sorts of nastiness.

Now GDI32.DLL is a rather thin library that mostly passes its work to WIN32K.SYS (In NT based systems).

WIN32K.SYS is the kernel mode component of the Win32 Subsystem. It does the real work of Win32. It _is_ Win32.

Any modifications to these libraries, no matter how trivial, could have wide ranging impact. These changes need to be well tested. Since the updated libraries will likely contain the rest of the Win32 API they need to be localized.

The point is that WMF is not so much an image format as it is a GDI scripting language. So the patch needs to be in GDI not in an image format handler.

Reply Parent Score: 2

RE[3]: ...
by Nathan O. on Thu 5th Jan 2006 17:19 in reply to "RE[2]: ..."
Nathan O. Member since:

Oooh. First sentance of your third paragraph foreshadowed the rest of the explanation nicely. Have you considered becoming a novelist? Your explanation was entertaining, thorough (enough), and clear. Thanks!

I guess a GDI scripting language sounded like a pretty good idea back when malware was comparably unknown.

Reply Parent Score: 1