MS Traces Duqu Zero-Day To Font Parsing In Win32k 221
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."
Kernel mode (Score:1, Insightful)
Re:brb banging head against wall (Score:5, Insightful)
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?
WTF (Score:5, Insightful)
Whiskey Tango Foxtrot Microsoft. What genius thought font parsing belonged in ring 0?
There are a lot of Microsoft shills here... (Score:5, Insightful)
... 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
Re:brb banging head against wall (Score:4, Insightful)
The world was a different place in the early days of NT 4
No, it wasn't. NT4 was released in 1996. By that time, many people here on /. had been exploiting bugs like that for 10 or 20 years already. Granted, mostly for fun or to cheat in (single-player) games, but still...
NT4 already had a security architecture. There was a different place available (basically anywhere outside ring0) and it should have been put there, and it definitely should have been obvious to anyone with three grams of brains that stuff like this doesn't belong into ring0.
Re:let me guess... (Score:5, Insightful)
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.
Re:There are a lot of Microsoft shills here... (Score:4, Insightful)
Seeing as speed (on 15+ year old equipment) was the reason they did it, you're not going to get an answer you like.
Sorry, but that reason is bullshit. Rendering fonts is performance-critical. Parsing the fonts is not. The vulnerability is in the code responsible for turning a font file into a set of bezier paths that the display subsystem can render. This code is not performance critical, nor does it need to run with any privileges other than the ability to read the font file (or read font data from a pipe or memory buffer) and write the bezier paths somewhere.
Moving the code that takes the output from this bit of code into the kernel makes sense, because that really is performance critical. Rendering text is one of the most CPU-intensive things a modern windowing system does. Parsing font files is not.