MS Traces Duqu Zero-Day To Font Parsing In Win32k

yuhong writes "MS has traced the Duqu zero-day to a vulnerability in font parsing in win32k. Many file formats like HTML, Office, and PDF support embedded fonts, and in NT4 and later fonts are parsed in kernel mode! Other possible attack vectors, for example, include web pages visited using web browsers that support embedded fonts without the OTS font sanitizer (which recent versions of Firefox and Chrome have adopted)." Adds reader Trailrunner7: "This is the first time that the exact location and nature of the flaw has been made public. Microsoft said that the permanent fix for the new vulnerability will not be ready in time for next week's November patch Tuesday release."

Re:Nearly as insane as executing code in images

[The Askylist]

Nope - it was definitely a deliberate decision to make most of the GUI run in kernel mode on NT4.

If you remember what 3.5 and 3.51 were like, it's possible to have some sympathy for this, but IIRC it was highlighted at the time as a bit of a silly thing to do.

Re:brb banging head against wall

[snowgirl]

This right here. The world was a different place back then. One could leave their house without locking their doors, and all that nonsense.

The WMF vulnerability was borne out of the same situation. When designed, there was no consideration made for remote-code execution, because "remote" didn't really exist. Your worries were boot-sector viruses and executable viruses coming in on that floppy of Doom you "borrowed" from your friend. You didn't get viruses from the internet, heck, you were lucky if your computer connected to the internet at all!

To end all this, this design decision clearly and loudly screams: GET OFF MY LAWN!!!

Re:Kernel mode

[nepka]

In fact it does. For example fbcon is part of kernel and handles, along other things, text rendering. It's not wise to assume things.

Besides, font rendering is quite common task and needs to be fast. That's why it also needs to be so low level. Yes, you could isolate everything to higher levels, but that only results in bloat and slowness. This was especially true in NT4.0 days, which this exploit dates back from.

Re:WTF

[impaledsunset]

It's a questionable decision, yes. However, the vulnerability wouldn't be any less worse if it was in userspace. And Microsoft weren't exactly the first. There was a time when the X11 server parsed fonts directly, and it was running as root, perhaps with some privileges dropped along the way. It wasn't kernel mode, but you still had a font parser running as root. So, they weren't the only geniuses who thought so.

But yeah, the X11 world has improved a lot since then, font parsing and rendering by the client, in userspace, and with an unprivileged account -- all great ideas that Microsoft might want to follow.

Re:Kernel mode

[marcansoft]

The kernel doesn't parse fonts. A userspace program parses the fontfile (which could easily be TrueType if someone feels like supporting that, though it would have to be monospaced). The kernel only gets a raw monochrome bitmap data array for the characters, a width and height, and optionally a character map. No parsing is done in the kernel.

KDFONTOP ioctl arguments:
struct console_font_op {
                unsigned int op; /* KD_FONT_OP_* */
                unsigned int flags; /* KD_FONT_FLAG_* */
                unsigned int width, height;
                unsigned int charcount;
                unsigned char *data; /* font data with height fixed to 32 */
};

fbcon blitting rectangular blobs onto the screen doesn't even remotely qualify as "parsing fonts". Doing TrueType in the kernel, which is what Windows does here, is patently insane.