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."

12 of 221 comments (clear)

  1. Re:Nearly as insane as executing code in images by The+Askylist · · Score: 3, Informative
    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.

  2. Re:brb banging head against wall by jimicus · · Score: 4, 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?

  3. WTF by arkhan_jg · · Score: 4, Insightful

    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.
    1. Re:WTF by impaledsunset · · Score: 3, Informative

      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.

  4. Re:brb banging head against wall by snowgirl · · Score: 4, Informative

    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
  5. There are a lot of Microsoft shills here... by bmo · · 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

    1. Re:There are a lot of Microsoft shills here... by TheRaven64 · · Score: 3, 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.

      --
      I am TheRaven on Soylent News
  6. Re:brb banging head against wall by Tom · · Score: 3, 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.

    --
    Assorted stuff I do sometimes: Lemuria.org
  7. Re:Kernel mode by marcansoft · · Score: 5, Informative

    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.

  8. Re:let me guess... by Raenex · · Score: 4, 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.

  9. NT4 was such an abomination... by mosel-saar-ruwer · · Score: 3, Interesting

    in NT4 and later fonts are parsed in kernel mode

    Sometimes I feel like I must be the only geezer remaining who actually had the opportunity to use NT 3.51, so let me tell you: It was a GLORIOUS operating system.

    EVERYTHING was client/server, and all the client stuff ran in Ring 3/User Mode.

    Heck, you could even kill Windows, and run it as a multi-user "DOS" box.

    But, of course, that meant that the video/graphics subsystem also ran as a client service, in User Mode, which [I guess] the suits perceived as being "slow", and therefore as being an impediment to the gaming experience which would come with the impending merger of code bases that we now know as Windows XP [2001].

    So in 1996, some genius at MSFT decided to throw out all of the beauty and elegance and stability and security that had been NT 3.51, and to serve up, instead, the great big steaming pile of sh!t which was NT 4.0 [with its video/graphics subsystem subsumed into the kernel].

    And the world was never again the same...

    1. Re:NT4 was such an abomination... by Gr8Apes · · Score: 3, Interesting

      Actually, IIRC, it was Win NT 3.1 that had the initial full security model you ascribe to Win NT 3.5. Win NT 3.5 had already slid a good portion of the way down the slippery slope of Ring 0 code, including some of the graphics drivers. (Again, IIRC, it's been a while)

      NT 4 moved a lot of user space Windows GDI functionality (as defined by Win 95/98/ME) into a kernel mode GDI API, which is single threaded btw, that persisted at least through all versions Windows XP, if not beyond. (This is one of the reasons why opening a 10MB networked file or attachment in Outlook causes your entire machine to lockup until it's done)

      This was in contrast to OS/2, which continued to follow the original design criteria, and hence was perceived to be slower on the same hardware as NT 4 for single tasks, although multi-tasking was much faster on OS/2. I mention this because NT's original basis was the OS/2 criteria, which was then mutated to be able to support the Win 95/98/ME gaming solutions.

      --
      The cesspool just got a check and balance.