Slashdot Mirror
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."
Very easily.
The world was a different place in the early days of NT 4 - and remember this design dates back to before then, because the design decision would have been made some time before NT 4 was released.
NT 4 was, arguably, the first version of Windows to really enjoy any sort of success in the server room. The Internet was only just starting to attract attention outside of academic circles; it would be some years before it became apparent how bad Windows was security-wise. Microsoft's priority wasn't security, it was making an OS with a sophisticated GUI you could install on a 486 with 16MB of RAM that could act as a server to a whole network. Historically it's always been somewhat quicker to run code in the kernel; NT 4 moved most of the GUI to the kernel for exactly this reason. Security? Why would that even appear on the radar?
Whiskey Tango Foxtrot Microsoft. What genius thought font parsing belonged in ring 0?
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
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!!!
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
... And I want at least one of them to give a good reason why parsing fonts in kernel mode is a good idea. Speed is not a good reason. Not even on 10 year old equipment it's not.
--
BMO
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: /* KD_FONT_OP_* */ /* KD_FONT_FLAG_* */ /* font data with height fixed to 32 */
struct console_font_op {
unsigned int op;
unsigned int flags;
unsigned int width, height;
unsigned int charcount;
unsigned char *data;
};
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.
Oh, go ahead, mod me down
I wish people would for your karma whoring. The "mod me down" is a standard trick to get modded up on Slashdot.