Output Stream of Consciousness

There was something that happened in a security patch Microsoft put out that was wrecking our clip art objects that we store in databases. Since more and more people were applying the patch, we were understandably worried.

It was, albeit harrowing at first, pretty interesting to actually help track down what the patch was doing and why it was failing this one particular circumstance.

Before the patch, all of our database-stored clip art is fine. After the patch, when it goes to save things to the database, all of a sudden, there is "good" clip art and "bad" clip art.

We spent quite a while waiting for Microsoft Tech Support online. ("Oh god, Kenny G hold music!" - I was having flashbacks of Dilbert cartoons like Dogbert's Tech Support centre's "Kevorkian Disconnect" option) We talked to a couple of front line folks, who were pretty nice. It got promoted up the ranks when it was shown we had a genuine issue. So I got 'hooked up with' a longtimer there to help sort things out.

At work, I had tracked things down as far as having the GetWinMetaFileBits return us "zero" for the size on some already-loaded metafiles.

He gave me a old project for dealing with Windows metafiles. I unrolled and extracted the appropriate Delphi code for loading and saving WMFs and EMFs (the problem was in loading and saving WMFs). I made a copy of Delphi's Graphics unit locally and began running small tests, modifying the pieces to match the project he gave us. Unfortunately, I couldn't do it for everything because the project used an API call to load from file by filename, and we do things by stream. All modifications I made had exactly the same behaviour as before.

In the midst of testing this, I noticed some debug output printing, complaining of an invalid EMF header in MF3216 for the "bad" files. That's got to be related.

I didn't think it would necessarily pan out to anything, but I have a modicum of assembly language skills, so I thought I would trace through the assembly code, and keep narrowing down the search until I found the debug message popped out when I stepped over a CALL instruction.

Well, it actually did bear fruit. I had to back up one more level (the last CALL instruction I did this for turned out to be the system call to DebugPrint), but I took a look-see and saw that there was a check rejecting values under 108, and the value was 100 for "bad files".

What could this 108 be? I took a look at the target of the EDI register, and noticed some values that looked a lot like dimensions and such. Turned out that it was the enhanced metafile header.

As you can see in there, though, there are some differences in that structure between version, and the "v5" version (#if (WINVER >= 0x0500)) includes some extra data. Eight bytes extra data, to be exact.

I also went in and, with a coworker's help, spelunked the exact equivalent code before the patch, and the comparison to 108 was gone. 108, I found out, is the size of the Windows XP/v5 enhanced metafile header, and 100 is the slightly older header.

So what was going on?

Well, the contact at Microsoft finally figured it out based on that information and talking to some of the other engineers on the team that it turns out there's a particular difference between the "good" and "bad" metafiles.

The "bad" WMF (old-format) metafiles were actually converted from EMF (new-format). In order to preserve extra information, in case you convert it back, the EMF header is saved as an "escape header" (the printing equivalent of a comment or secret command - it's not processed by the system, but something else that knows about it can read it).

When Windows reads the WMF in, and sees that escape record, it pulls it in for any extra information. It's only 100 bytes long, because it was saved from an older operating system, and there's no code to expand it.

The problem in the security patch happened because it was basically adding a check to make sure the header was at least as long as the enhanced metafile header... the new size, 108. That seems perfectly understandable to me. There was no code to pad that escape record to the new header size.

Problem explained :)

So, there may be a forthcoming patch to that in a service pack at some time. There's a little bit of me in there. Bizarre ;)

Comments:

# Nice job. Your fifteen minutes of fame right there. :)

Comment by ElTwo [Visitor] — 12/20/05 @ 20:51

# *laugh* I don't think they give credit for patches in service packs, do they? Well, I guess the 15 minutes will have to be in 5-second increments.

You know, I've never seen the acronym HTML tag before.

Comment by nimble [Member] — 12/21/05 @ 14:13

# I was impressed. As someone who was there, and saw the author track down this bug, I can say the he is too modest. It was some hardcore debugging. Congrats!

Comment by Ooblik [Visitor] — 12/22/05 @ 23:26

# That's Ritchie all over. One of these days I'll see him fully take credit but I haven't yet.

Comment by Adam [Visitor] — 12/24/05 @ 16:57

# Dude, you just may be famous soon. Check this out:

http://sunbeltblog.blogspot.com/2005/12/new-exploit-blows-by-fully-patched.html

Comment by Ooblik [Visitor] — 12/28/05 @ 10:42

# *laugh* I doubt it's directly related to what we're doing, but it might be nice if our little fix could actually make its way into a security patch! (What are the chances, though?) At least there are a group of folks that are "primed" on the code in question already.

I didn't know that WMF was a valid web page graphics format. Hmm! Learn something new every day :)

*laugh* Sorry for the modesty - it's just that even though it was fine debugging (thanks for the compliment!), I enjoyed hunting it down, and somewhere in the back of my head it says that there wasn't even pain involved for me to get kudos :)

Comment by nimble [Member] — 12/28/05 @ 10:59

# http://isc.sans.org//diary.php?storyid=972

Comment by Ooblik [Visitor] — 12/28/05 @ 19:44

# Doesn't look like our fix made it in, at least according to the thank yous...

http://www.microsoft.com/technet/security/Bulletin/MS05-053.mspx

Comment by nimble [Member] — 12/28/05 @ 22:54

# ya, apparently not. sux.

Comment by Ooblik [Visitor] — 12/29/05 @ 14:22

# Someone has released a 3rd party patch....

http://www.hexblog.com/

Comment by Ooblik [Visitor] — 01/03/06 @ 08:51

# Yep. This one's turning out to be a fairly big glitch. I decided to go with the patch and unregister shimgvw.dll after the Internet Storm Center endorsed it. Both sites are getting hit hard today.

Once MS gets around to an official patch, I just have to uninstall the other.

Comment by ElTwo [Visitor] — 01/03/06 @ 15:10