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

28 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. brb banging head against wall by admiralranga · · Score: 2, Funny

    FFS microsoft, I'm a highschooler and I think that a really bad idea. How do mistakes like that get through q&a?

    1. 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?

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

      The world was a different place in the early days of NT 4

      Arguably true... but only for the monolithic win 9x series releases, which aren't relevant to this topic since the NT kernel was developed independently within Microsoft by Dave Cutler from DEC. It was Microsoft's first truly modern operating system. As many comm enters above me have mentioned NT originally did have functions such as font rendering in userspace due to its heavy hardware abstraction. As the pending issues with 9x loomed however MS could read the writing, on the wall; porting 9x to Unicode (it was ANSI throughout, a separate "Layer for Unicode" had to be used to run Unicode programs on 9x machines) as well as supporting newer hardware (AHCI, USB, true Plug and Play) was going to be nearly impossible (the attempt was called Windows ME). So Microsoft began with NT4 to prep for the mass migration from 9x. Since the average consumer at the time didn't want to drop $3k for a workstation that would be able to run the NT model correctly, Microsoft made some compromises to the OS for the sake of speed.

      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.

      You however are making the assumption that everybody in Microsoft talks to each other. A most incorrect assumption. The reality is most likely that WinDiv (The division responsible for the OS) made the assumption that fonts would not be loaded from insecure sources, e.g. Word documents. The Office division however faced the problem of what do you do when some user uses a font that is not on another users system? So they made the decision to allow the embedding of fonts into the file format, along with a bunch of other really bad decisions in hindsight (remember the Melissa virus?) that would have been caught if they had had the same security reviews as WinDiv did. To compound the problem, Office used unpublished and most likely unhardened APIs (it probably still does in parts) that allowed it the capabilities to do things like on the fly font loading something that wasn't exposed to the rest of us until Windows 2000 (NT 5.0). My point being that at the time it WAS a safe decision as far as WinDiv was concerned. Should they have been a little more careful with those unpublished APIs... yes they should have, it would have prevented a lot of anti-trust issues, but they weren't. So here we are with yet another security bug.

      --
      Any and all content posted above may be ignored, considered irrelevant, or otherwise dismissed.
    5. Re:brb banging head against wall by dbIII · · Score: 2

      The world was a different place in the early days of NT 4

      It wasn't really. Things like this were well known to be a bad idea and were only done to cut corners. Stuff as mainstream as Scientific American had articles on computer viruses in the early 1970s for fuck sake and a few hacking movies let alone popular novels had come out before NT4.

      Security? Why would that even appear on the radar?

      It was nineteen fucking ninety six and personal computer users had been worried about computer viruses for about a decade.

    6. Re:brb banging head against wall by Gr8Apes · · Score: 2

      NT 4 was, arguably, the first version of Windows to really enjoy any sort of success in the server room.

      Only for the first 42 days or 2^20 page outs....

      --
      The cesspool just got a check and balance.
    7. Re:brb banging head against wall by BitZtream · · Score: 2

      The reality is most likely that WinDiv (The division responsible for the OS) made the assumption that fonts would not be loaded from insecure sources, e.g. Word documents.

      The bug here is a kernel level exploit by user land code, not administrative, just normal users. If the kernel team doesn't expect fonts to be loaded from 'insecure' locations then the API should have required special access, as it is, any user can root the machine, Internet or no Internet, Word or no Word. I can write an app to exploit this, just need to get someone to run it.

      Thats not a miscommunication issue, thats a fucking huge mistake, it doesn't MATTER what the word team tried, it shouldn't have worked.

      Second, the kernel should validate ALL INCOMING DATA before doing anything with it. If you can't do this at fast enough rates, you preprocess it and let the kernel put it somewhere in the VM.

      You ALWAYS validate data coming into the kernel from userland. Always. No exceptions. ALWAYS.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    8. Re:brb banging head against wall by gmueckl · · Score: 2

      Seems you almost got it right. A quick Google search turned up the information that ring 1 was unused and ring 2 was home for parts of the graphics and printing system.

      --
      http://www.moonlight3d.eu/
  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.

    2. Re:WTF by larien · · Score: 2

      Wrong - if it was in userspace, it would be tied to the permissions granted the logged on user. I'm not 100% sure, but even as admin, UAC should still have blocked the worst of the behaviour. Once you're running code in the kernel, you can pretty much do whatever you want and the user's permissions and UAC become irrelevant.

  4. Re:How to deactivate custom fonts in a browser? by thejynxed · · Score: 2
    --
    @Mindless Drivel: 100% of Twitter posts ever Tweeted.
  5. Re:Kernel mode by nepka · · Score: 2, Informative

    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.

  6. 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 Fred+Or+Alive · · Score: 2

      Seeing as speed (on 15+ year old equipment) was the reason they did it, you're not going to get an answer you like.

      People said Windows NT was too slow on their 486s, so one of the things Microsoft did to try and fix that was to move the GDI into the kernel. They didn't think the security and stability side through however, and I doubt if many people are going to call it the greatest decision ever made in the design of an OS.

      --
      10 PRINT "LOOK AROUND YOU ";
      20 GOTO 10
    2. 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
  7. deserved by Tom · · Score: 2

    in NT4 and later fonts are parsed in kernel mode!

    anyone who doesn't immediately realize this is a recipe for trouble? Parsing externally-supplied data in kernel mode. Yeah, like that never got anyone...

    For all the really, really smart people that MS employes, why do they keep on making the dumbest mistakes one could come up with if it were a "dumb idea of the month" challenge?

    --
    Assorted stuff I do sometimes: Lemuria.org
    1. Re:deserved by rocket+rancher · · Score: 2

      What does that say about your pretense that this was recently thought up?

      You've lost me. Where outside some dark corner of your own mind with possible chemical assistance is that suggested? Please quote it.

      Dude, you are the one huffing glue. "keep on making" and "dumb idea of the month" imply a level of immediacy and concurrency that is absolutely unwarranted. The guy is hiding behind a 3 digit ID, thinking it shields him when he makes an asinine remark. It doesn't.

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

  9. Xbox by crdotson · · Score: 2

    Isn't this how people hacked the original xbox so many years ago (a font vulnerability)? It's not like they haven't been warned...

    1. Re:Xbox by cbhacking · · Score: 2

      I don't know about the Xbox vulnerability per se, but font parsing vulns are nothing new. For an actually pretty recent example, t least one of the iPhone jailbreaks used a very similar exploit to this one (and was embedded in a web page).

      That said, I know MS fuzzes the heck out of their font parsers. It's a little tricky since it's in kernel - if something breaks, it's slightly harder to debug and takes more time to go through repro steps, since you're basically intentionally bugchecking ("BSoDing") the box - but it's possible, and they do it. On the other hand, nothing much is guaranteed in fuzzing. You can run a billion iterations without finding anything, and the billion-and-first one finds a arbitrary code execution bug like this. Sucks to be you, especially when some black-hat's fuzzer lucks out and finds that bug on the 30th iteration.

      As for the argument that font parsing shoudl be moved out of the kernel, that's arguably true of an awful lot of Win32k.sys. The problem is, that thing is an ancient morass of absolutely critical code. By module, I believe it's responsible for more vulnerabilities than any other portion of Windows since Vista came out. Part of the reason is that a lot of it is so old and crufty, and the risk of regression so high, that it doesn't tend to get re-written or even modified except to fix bugs when they're found or add new features. I strongly suspect that a significant portion of it dates back to NT4, substantially unmodified in all the time since then. From a technical standpoint, Win32k.sys is probably the biggest security in modern Windows, certainly worse than recent versions of IE or Word or IIS. Yet it's so integral to the OS that they can't afford to rip it out and do it over.

      --
      There's no place I could be, since I've found Serenity...
  10. 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.

  11. They should have known better by DragonHawk · · Score: 2

    Security? Why would that even appear on the radar?

    Computer security has been an issue since at least the 1960s, and it's been well-documented and understood since at least the 1980s (when the NSA Rainbow Books appeared). The Morris worm hit in 1988. None of this stuff should have come as a surprise, and there were many people talking about how Microsoft was repeating all the mistakes over and over again.

    As you say, the fact is, Microsoft wasn't concerned with security. I don't give them a free pass for that. The entire world has been paying for their mistakes ever since. Their lackadaisical attitude towards security -- when they certainly could have learned from the literature and from history -- has cost the world billions, if not trillions of dollars.

    Not okay.

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
  12. 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.
    2. Re:NT4 was such an abomination... by dryeo · · Score: 2

      Back in the OS/2 1.x days, MS wanted to put the graphics stuff in ring 0, IBM flatly refused, which was one of the many reasons for the falling out between them.
      OS/2 did its font parsing in user land with a DLL that was easily replaced with Freetype which was quite an improvement.

      --
      https://en.wikipedia.org/wiki/Inverted_totalitarianism