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

221 comments

  1. Kernel mode by Tomato42 · · Score: 1, Insightful

    And they told me that Linux is monolithic... But I'm damn sure that the kernel doesn't parse fonts.

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

    2. Re:Kernel mode by Arlet · · Score: 1

      Does fbcon render true type fonts, or only simple bitmaps ?

       

    3. Re:Kernel mode by Anonymous Coward · · Score: 0

      fbcon only handles bitmap fonts in a comparatively simple format. Try again.

    4. Re:Kernel mode by Barefoot+Monkey · · Score: 1

      Parsing, not rendering. Does fbcon parse font files? Or is that done in user space?

    5. Re:Kernel mode by Anonymous Coward · · Score: 0

      That's why it also needs to be so low level.

      Abstraction fail. There is no reason why speed should imply low level, and there is no reason why common should imply kernel. In fact, a process running fully in userspace is most probably faster because it needs less context switching.

      On the other hand, if the NT kernel is so badly implemented that userspace is always slower than the kernel, it would explain a lot...

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

    7. Re:Kernel mode by Anonymous Coward · · Score: 0

      Text rendering != text parsing you, please go back in your cave. It's not wise to speak of things you do not understand.

    8. Re:Kernel mode by hairyfeet · · Score: 1

      TFA also doesn't point out that they already have a workaround that is as simple as clicking a button that says "fix it". No CLI mess, no trying to explain it to Suzy the checkout girl, the CLI is also listed if you want to do that, but for everyone else there is this simple fix it page.

      I don't know about everyone else but I'll be testing this on my own system for a few hours and if there are no adverse effects i'll be shooting an email to my users with the link.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    9. Re:Kernel mode by BitZtream · · Score: 1

      Sigh, the userland program is just a preprocessor, the kernel still has to parse and validate the memory it gets passed to it. The compiler does most of the parsing code for you thanks to those neat things called structures.

      The two kernels may do things differently, but they are both most certainly parsing fonts. You just seem to think that if the compiler does it for you or that if its done exclusively in memory that its not parsing, which is just silly logic.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    10. Re:Kernel mode by Burpmaster · · Score: 1

      Sadly for your worldview, accessing fields at fixed offsets from a pointer isn't parsing. To say that it is redefines absolutely everything that software does as parsing.

    11. Re:Kernel mode by amorsen · · Score: 1

      Sigh, the userland program is just a preprocessor, the kernel still has to parse and validate the memory it gets passed to it.

      How difficult exactly is it to parse the Linux kernel font format? It's 5 ints plus an array which the kernel doesn't even need to understand (only boundary check)! Good luck exploiting that. Most ordinary programs/users don't even have ACCESS to the console; even if there was a bug you'd need to log in and run programs on the text console to exploit it. It is somewhat unusual to run word processors on the text console these days, you may have noticed.

      Compare that to a Turing-complete hint format where you need to implement a virtual machine as part of the font parser, accessible and used by practically every GUI program.

      --
      Finally! A year of moderation! Ready for 2019?
    12. Re:Kernel mode by Anonymous Coward · · Score: 0

      There's an important misconception in this post: that moving code into the kernel makes it faster. Userspace code runs on the same processor and at the same level, just with altered permissions.

      Moving to kernel space will only give you performance if doing so lets you eliminate context switches. For example, high-frequency trading algorithms sometimes run in kernel (I've heard) so that sending out network requests (to make trades or read quotes) can occur without a round trip to the kernel, shaving a few hundred cycles off the total request time.

      Font parsing is definitely not one of these cases, though. The only kernel calls necessary are to read the font file, and the cost of each call will be dominated by the time to actually read the file.

      I strongly suspect there's some inaccuracy we're missing about this article because, on the face of it, putting TrueType parsing in kernel mode is such a boneheaded move that I just can't believe MS engineers would actually do it.

    13. Re:Kernel mode by shutdown+-p+now · · Score: 1

      Besides, font rendering is quite common task and needs to be fast. That's why it also needs to be so low level.

      Doing something in kernel space does not magically make it faster. What it does is, it gets it all closer to other kernel space code, and so you don't need to waste time on userspace-to-kernelspace transitions if you need it.

      In this case, I suspect the fonts are in the kernel because high-level graphics (i.e. GDI) is in the kernel, which in turn is because the graphics driver is in the kernel. It's a design that dates back to the earliest NT versions, where this kind of thing was very much justified if you wanted a responsive UI. These days, not so much.

    14. Re:Kernel mode by DeathFromSomewhere · · Score: 1
      The claim:

      the kernel doesn't parse fonts.

      The counter:

      fbcon is part of kernel and handles, along other things, text rendering

      Your response:

      fbcon only handles bitmap fonts

      If you want to agree with someone, why be so snarky?

      --
      -1 overrated isn't the same thing as "I disagree".
  2. Nearly as insane as executing code in images by dbIII · · Score: 1

    NT4 and later fonts are parsed in kernel mode!

    It looks like somebody was half asleep that day as well and the long "focus on security" didn't go deep enough.

    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:Nearly as insane as executing code in images by moderators_are_w*nke · · Score: 1

      I am surprised they haven't gone back to the old model now the hardware is up to it. It would make a lot of sense.

      --
      "XML is like violence. If it doesn't solve your problem, use more." - Anonymous Coward
    3. Re:Nearly as insane as executing code in images by gmueckl · · Score: 1

      Well, the graphics drivers were moved out of the kernel and into a special user-space-like environment with Vista. This allows Windows to restart crashed graphics drivers on the fly (and this even works most of the time). Looks like other parts of the graphics subsystem are still where the don't belong, though.

      --
      http://www.moonlight3d.eu/
    4. Re:Nearly as insane as executing code in images by yuhong · · Score: 1

      I once suggested to Larry Osterman of MS that this be done, now that there is a *separate CSRSS for each session* and has been since NT4 TSE. If one of them crashes, only the session is lost.

    5. Re:Nearly as insane as executing code in images by yuhong · · Score: 1

      Yea, partly because of the need to support old XP display drivers. The good news is support for that is eliminated in Windows 8, which may even allow the DWM to be part of the new CSRSS.

  3. 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 Anonymous Coward · · Score: 0

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

      NT 3.1 to NT 3.51 had a pretty nice design - very microkernel-like, portable/hardware-agnostic, win32/OS2/Unix subsystems, ...

      However it was slow as a dog and with NT4 Microsoft sacrificed much of the virtues of the NT design in favor of speed gains by running as much as possible in kernel mode.

    4. Re:brb banging head against wall by Zamphatta · · Score: 1

      It's not a mistake, it's a feature -- for Windows users & for hackers! ;-)

    5. 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
    6. Re:brb banging head against wall by CODiNE · · Score: 0

      Right, and when Microsoft added ActiveX to the browser, nobody warned them it would be a security issue... why remote execution was still seen as a feature in those days.

      When the browser was embedded into the OS, nobody imagined it could one day be a problem... the geeks were thrilled at the wonderful new design innovations occurring at Microsoft, security wasn't even on the radar back then.

      Right.

      --
      Cwm, fjord-bank glyphs vext quiz
    7. Re:brb banging head against wall by gmueckl · · Score: 1

      They still supported non-x86 architectures back then. And on those, there is only a kernel mode and a user mode. Rings 1 and 2 don't exist there. So putting the graphics in ring 1 or 2 would have hurt portability. OS/2, on the other hand, actually started to put stuff in all 4 rings because it was designed to run only on 386 and up.

      --
      http://www.moonlight3d.eu/
    8. Re:brb banging head against wall by cynyr · · Score: 1

      no we weren't thrilled... lots of sites stopped working anywhere other than in IE, and certainly not in Slackware! NOW GET OF MY LAWN!!! PULL UP YOUR PANTS!

      --
      All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
    9. 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.
    10. Re:brb banging head against wall by buglista · · Score: 1

      Bollocks. I remember saying it was a stupid idea at the time, and for stability as well as security reasons. Microkernels looked like a good way to go at the time, whereas MS were doing the exact opposite of what good design principles dictate. Have you not read Structured Computer Organisation?

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

    12. Re:brb banging head against wall by Spazntwich · · Score: 1

      I'm a college dropout and have no idea what any of this means... so... uh... kudos to you; you have my envy, younger yet superior nerd.

      Seriously. I feel like this post comes across as sarcastic but I mean it.

    13. Re:brb banging head against wall by jimicus · · Score: 1

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

      They had. But this is Microsoft we're talking about here, and their ability to predict the future has always been notoriously terrible; the great majority of viruses at the time were assembler-written things that did all sorts of clever stuff bypassing the OS entirely - and they were able to do that because memory protection was scant at best on DOS/Win3.x/Win9x. Few viruses even worked in NT, and with a proper security model, how could they?

    14. Re:brb banging head against wall by MobileTatsu-NJG · · Score: 1

      Umm, yeah, so we also have no excuse for kitting our asses kicked in an alien invasion, right?

      --

      "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

    15. Re:brb banging head against wall by dbIII · · Score: 1

      It wasn't about predicting the future - it was about learning from the lessons of the past! Unix and others had been cracked in all directions by students before NT was even thought of which is one reason why security was a consideration there, in VMS and in earlier versions of NT.

    16. Re:brb banging head against wall by yuhong · · Score: 1

      Well, when they designed ActiveX, they did realize that there would be security issues, which is why they created code signing and "safe for scripting" and "safe for initialization" etc... One of the problems however was that back in 1996 buffer overflows etc was not well-known security threats, which is now one of the biggest reasons why nowadays MS is adding kill bits in security updates.

    17. 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.
    18. Re:brb banging head against wall by yuhong · · Score: 1

      And in particular it took until IE4 in 1997 before MS's own web browser supported embedded fonts.

    19. Re:brb banging head against wall by yuhong · · Score: 1

      Note here that MSDN has completely get rid of compatibility info for any Windows versions before Win2000. Look in the old Platform SDK for WinServer 2003 SP1 from 2005 for the true compatiblity info.

    20. Re:brb banging head against wall by Anonymous Coward · · Score: 0

      Netscape IPO: Aug 9, 1995
      Windows NT4 release date: July 29, 1996, amost a WHOLE YEAR LATER

      I'm sorry, but your revisionist history attempt to apologize for Microsoft's security practices are utter bullshit.

    21. 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
    22. Re:brb banging head against wall by peppepz · · Score: 1

      Microkernels don't do drivers and file systems.

    23. Re:brb banging head against wall by dryeo · · Score: 1

      I don't think that OS/2 ever used ring 1 and ring 2 was used for DOS compatibility, allowing DOS device drivers to work in a DOS virtual machine.

      --
      https://en.wikipedia.org/wiki/Inverted_totalitarianism
    24. Re:brb banging head against wall by CODiNE · · Score: 1

      Alrightie, quick question for you since you clearly have been doing this longer than I have.

      Back in 1996 when I was learning C it was pointed out many times that gets() was dangerous and should not be used. It was common knowledge by then.

      So when and who started making a big fuss out of gets and the danger of buffer overflows? I find it strange that a teenager back then knew of them when Microsoft apparently didn't think it was a problem.

      --
      Cwm, fjord-bank glyphs vext quiz
    25. Re:brb banging head against wall by yuhong · · Score: 1
    26. Re:brb banging head against wall by sjames · · Score: 1

      If someone in WinDiv allowed anything in ring0 to depend on anything unprivileged to keep it from being exploited (such as depending on Office to not load insecure fonts), then they were wrong, full stop. No exceptions, no excuses. Whoever made that decision needs to wear the paper bag now.

      Ideally, a privileged gatekeeper would get the request from unprivileged processes, parse it out and sanitize it, simplify it and pass it up to ring 0.

    27. 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/
    28. Re:brb banging head against wall by Anonymous Coward · · Score: 0

      You are in highschool and never used anything less then Windows XP. Get off the lawn or tell me what the exact issue is besides "omg stupid, user space vs kernel". Tell me how fonts exploit a system in both NT and Unix and how the security is different.

    29. Re:brb banging head against wall by shutdown+-p+now · · Score: 1

      It wasn't done to "cut corners" - remember that earlier version of NT (3.1, 3.5) did it all in user space. It was moved to kernel space, deliberately, so that it would sit there together with the graphics driver for maximum rendering perf. On the hardware of that time, it did make a visible difference, and let it run well on less powerful machines.

      You can argue that choosing speed over safety was a wrong priority, especially for a server OS. And I would agree with that. But it wasn't done just for giggles, or because someone was that stupid.

    30. Re:brb banging head against wall by shutdown+-p+now · · Score: 1

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

      If you're a highschooler, I bet you never had to write code that's supposed to run a 486 with 8Mb of RAM and a crappy S3 video card that barely does 2D. Try that, then have your clients come screaming at you about how your OS is so slow as to be unusable (sure it is, when you've almost got a microkernel there and nice isolation levels for all stuff, including graphics!) - then get back to us.

    31. Re:brb banging head against wall by antdude · · Score: 1

      Q&A = Questions & Answers. :P

      How did that easy mistake get through you? :P

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  4. How to deactivate custom fonts in a browser? by muon-catalyzed · · Score: 1

    Any idea how to turn-off custom fonts in webpages? Can't find that setting in Firefox at the moment. You are only vulnerable if custom fonts are enabled.

    1. Re:How to deactivate custom fonts in a browser? by Anonymous Coward · · Score: 1

      install GNU/Linux

    2. Re:How to deactivate custom fonts in a browser? by thejynxed · · Score: 2
      --
      @Mindless Drivel: 100% of Twitter posts ever Tweeted.
    3. Re:How to deactivate custom fonts in a browser? by Anonymous Coward · · Score: 0

      just like javascript and flash objects on html pages, noscript in firefox blocks them all by default

    4. Re:How to deactivate custom fonts in a browser? by Anonymous Coward · · Score: 0

      Use Noscript.

    5. Re:How to deactivate custom fonts in a browser? by muon-catalyzed · · Score: 1

      Turning off "allow pages to choose their own font" switch should quench this flaming 0-day.

      http://support.mozilla.com/en-US/kb/Changing%20fonts%20and%20colors

      Thanks!!

    6. Re:How to deactivate custom fonts in a browser? by yuhong · · Score: 1

      I think recent versions of Firefox uses the OTS font sanitizer which tries to prevent attacks.

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

    3. Re:WTF by TheRaven64 · · Score: 1

      The sane way of doing this would be to have a font service that would run as an unprivileged user, parse TrueType fonts and pass the beziers to the graphics subsystem in the kernel. This was possible with the NT security model from the start. This wouldn't even have cost anything in terms of performance - parsing the font file is not performance-critical, only rendering the resulting glyphs is.

      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

      Kind of. It did, but only of fonts installed on the X server. This meant that it was not parsing untrusted font data. This approach was problematic, because it meant that if you installed an office suite on a server then you needed to install all of its fonts on every thin client machine, or it needed to do all of the font rendering and then just send images to the X servers. Modern (i.e. for about the last decade) X systems have done font parsing and rendering on the client but stored the rendered glyphs on the server, where they can be composited quickly. This also has the advantage that the same rendering code can be used for any font format without the display server needing to know how it works.

      --
      I am TheRaven on Soylent News
    4. Re:WTF by NeoMorphy · · Score: 1

      X server runs as root because it needs to directly access your video hardware.

    5. Re:WTF by ultranova · · Score: 1

      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.

      UAC is irrelevant, since it doesn't tell the user what the program is actually trying to do, so the choices are to accept and hope everything goes well, or deny and have the program not work. Add the fact that random programs will require admin rights at random times, and the only real effect of UAC adds up to blame shifting.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    6. Re:WTF by shutdown+-p+now · · Score: 1

      UAC is irrelevant, since it doesn't tell the user what the program is actually trying to do, so the choices are to accept and hope everything goes well, or deny and have the program not work.

      Well, it's exactly like su/sudo, and Unix world has somehow managed to live with that for decades.

      Then again, it didn't have large quantities of users whose first reaction to the file named amateur_lesbian_threesome.jpg.exe was to click it (and then click "Yes, just fuck off!" in every warning dialog that would appear).

    7. Re:WTF by Anonymous Coward · · Score: 0

      However, the vulnerability wouldn't be any less worse if it was in userspace.

      Excuse me?

      Are you referring to the vulnerability as such (specific logic and/or lines of code) or to the impact and consequential seriousness of the vulnerability?

  6. Re:let me guess... by nzac · · Score: 1

    It says it just a true type font parsing.

    I don't know why but image and font file parsing and thumb-nailing is a common security problem (about once a month or so my distro has a security update for a potential hole).

    I think they generally work by tricking the computer to run arbitrary code from elsewhere rather than contain the code themselves.

  7. This is why proprietary software is bad. by Anonymous Coward · · Score: 0

    If this was an open-source project (like linux), a flaw like this would have been spotted YEARS ago.

  8. 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 Anonymous Coward · · Score: 0

      No linux system parses externally-provided font data in kernel mode. Are you referring to framebuffer fonts here? You can't get a web-browser to hand those to the kernel. This is by design.

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

      I've been bitching about the Microsoft Shill Takeover of Slashdot for awhile now.
      Glad to see someone else "gets it".
      And again, we see that Microsoft doesn't.

    4. Re:There are a lot of Microsoft shills here... by Old+Sparky · · Score: 1

      Ooo! You must have lots of Microsoft Skin in your game, Mr Anonymous. Or should we call you Mr. Ballmer?

    5. 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:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      I regret to inform you your tinfoil hat has been delayed but should arrive sometime next week.

    7. Re:There are a lot of Microsoft shills here... by BitZtream · · Score: 0

      You do realize your modern Linux parse fonts in the kernel as well right?

      When you pass in a new font to the frame buffer, via ioctl, the kernel then parses that data and validates it. This font information is FAR less complex than what MS is doing, and is FAR less likely to be exploited as parsing is done mostly by the C compiler (via the use of structures) and fixed data sizes so its relatively easy to not fuck up.

      None the less, EVERY OS does this to different extents, this is just a bug like all others. You can blame MS for allowing such a complicated format to end up being parsed by the kernel and increasing the odds of this happening, but you can't call them out like they are unique in doing it.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    8. Re:There are a lot of Microsoft shills here... by peppepz · · Score: 1
      Fixed-length bitmap buffers cannot be "parsed". All the kernel has to do is to check that the referenced memory does exist, which is a kernel's primary job, and then load it into the VGA registers.

      True type fonts need to be decoded, parsed, and interpreted.

      The two things are completely incommensurable.

    9. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      Untrue. You can parse any data via pointer usage fixed length or not. His points on iocl are also worth noting because this is about fonts (and you yourself concede parsing goes on with them), and yes, they are part of the graphics subsystem data. Everything in the system is a file in modern Operating System, and any file can be parsed. Period.

    10. Re:There are a lot of Microsoft shills here... by peppepz · · Score: 1

      Please provide an example of how I can parse a sequence of pixels.

    11. Re:There are a lot of Microsoft shills here... by Ant+P. · · Score: 1

      Rendering precompiled bitmap data to screen.

      That's a very bullshit definition of "parse fonts" you have there, MS apologist.

    12. Re:There are a lot of Microsoft shills here... by johanatan · · Score: 1

      But you know that splitting the parsing logic from the rendering logic and creating the interface between would take precious keystrokes from a programmer with limited time on his hands (and this was probably only one of many such points where splits would have to be made). Looks like they did the quick and easy thing by putting the GDI subsystem as a whole into the kernel.

    13. Re:There are a lot of Microsoft shills here... by peppepz · · Score: 1

      The sequence of pixels is not stored in a file, it is already loaded in a buffer of the required length and in the machine format.

    14. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      Anything in a modern operating system is a file and any file can be opened and parsed, even in memory, with pointers (this includes buffer areas). End of subject.

    15. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      God you're a moron.
      (another anon here)
      TTF are freakin' turing complete.
      The idiots at microsoft are actually running a freakin' VM in their freakin kernel.
      How stupid can you be?
      Hell. That's why NoScript blocks font loading by default.
      But at least that's userspace if you enable it.

    16. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      If the best you have is name calling in response, you make it obvious you failed.

    17. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      Lol.
      Naw, I was drilling down the list of comments and your eyeblinding stupidity jumped out at me.
      The idea that you are seriously comparing loading a bitmap directly to the graphics card with something the equivalent of (roughly)
      running javascript in the kernel just called out to me. Thankfully anonymity allows being insulting without repercussions 'cause you sooooo
      deserve it.

      Dude you were "debating" with was considerably more civil. Lord knows why...

    18. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      BMO down modded this also? Talk about admitting defeat on his part!

    19. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      I'm civil pointing out facts. With pointers you can do anything just about, including parse areas of memory (not just files). Most all languages have them, and everything's abstracted as a file in modern operating systems. Fact, and you can always open/read-write/close/flush them since it's all files by abstraction in modern operating systems. The fact that you're calling myself and others names here only shows you failed.

    20. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0
    21. Re:There are a lot of Microsoft shills here... by bmo · · Score: 1

      Funny, I haven't had mod points in 2 weeks.

      Oh look, it's apk projecting again.

      You got modded down because you're a fucking spammer.

      --
      BMO

    22. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      Doesn't look like spam bmo, it looks like documented facts http://tech.slashdot.org/comments.pl?sid=2510534&cid=37957838 and ones you couldn't get the best of. Everyone knows that dorks like you keep multiple accounts here to play games with so you're not fooling anybody. If what he wrote above is spam disprove it.

    23. Re:There are a lot of Microsoft shills here... by Anonymous Coward · · Score: 0

      Seems you project here on meds http://slashdot.org/comments.pl?sid=2510534&cid=37957792 and if that is the best you have in response on a technical topic then by default your opponent is correct.

    24. Re:There are a lot of Microsoft shills here... by shutdown+-p+now · · Score: 1

      My suspicion was that, when they moved GDI to kernel space back in NT4, it was done wholesale - likely because re-architecturing it completely to properly separate into things that had to go into the kernel for perf reasons, and things that could stay in userspace, and making them interoperate (since that now requires a bunch of new kernel calls) simply didn't fit the release schedule even after considerable stretching.

    25. Re:There are a lot of Microsoft shills here... by TheRaven64 · · Score: 1

      Yup, that's more plausible. It wasn't done because it was sensible, it was done because it was easy.

      --
      I am TheRaven on Soylent News
  9. I guess so.. by CFBMoo1 · · Score: 1

    "This is the first time that the exact location and nature of the flaw has been made public."

    They want to push Metro out as the replacement. Anything that knocks down older technologies that even they sold at one time helps. Great way to push people off another possible Internet Explorer 6 so to speak for Windows 8.

    --
    ~~ Behold the flying cow with a rail gun! ~~
    1. Re:I guess so.. by BitZtream · · Score: 1

      Why do you feel the need to force your crappy monospaced font on the rest of us when you post? Its not even a freaking attractive one for fucks sake.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:I guess so.. by Ant+P. · · Score: 1

      They want to push Metro out as the replacement.

      They do? Well it's about time they switched to a more stable system.

    3. Re:I guess so.. by Anonymous Coward · · Score: 0

      Not to reflect in any way on the GP, but it's fun to imagine you expecting monospaced fonts to be freaking attractive.

  10. 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 Rockoon · · Score: 1

      Hello Mr Low ID number.

      I'll bet you anything that this code was in the kernel before you signed up here at slashdot. What does that say about your pretense that this was recently thought up?

      I await your snarky reply.

      --
      "His name was James Damore."
    2. Re:deserved by Anonymous Coward · · Score: 0

      yeah, maybe thats the low-digit UID /. auctioned for charity on its tenth birthday?

      ---- just a wild guess ---- :)

    3. Re:deserved by dbIII · · Score: 1

      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.

    4. Re:deserved by Anonymous Coward · · Score: 0

      Around here:

      why do they keep on making the dumbest mistakes

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

    6. Re:deserved by Anonymous Coward · · Score: 0

      What kind of bullshit, inverted Appeal to Authority argument is this?
      People with low IDs suddenly have to watch their mouths or else get accused of hiding behind them? Why exactly does having a 3-digit ID suddenly hold you to a higher standard than every other pseudonymous fucknut with an opinion on Slashdot?

    7. Re:deserved by Waffle+Iron · · Score: 1

      I'll bet you anything that this code was in the kernel before you signed up here at slashdot..

      What was supposed to have happened during Microsoft's security "rebirth", where they put Longhorn development on ice for about a year so they could overhaul XP for Internet-worthy security robustness? What about since that time where they've supposedly been using the most advanced code verification tools on the planet to verify their OS?

      Shouldn't they have reimplemented this feature in userspace at some point during that long process?

    8. Re:deserved by Tom · · Score: 1

      I'll bet you anything that this code was in the kernel before you signed up here at slashdot. What does that say about your pretense that this was recently thought up?

      I didn't say anywhere this was recent. Adding something like that to kernel code was an obviously stupid idea even at that time.

      And yes, it is probably about two years older than my /. membership.

      --
      Assorted stuff I do sometimes: Lemuria.org
    9. Re:deserved by Tom · · Score: 1

      "keep on making" and "dumb idea of the month" imply a level of immediacy and concurrency that is absolutely unwarranted.

      Ah, I see the misunderstanding.

      No concurrency was intended. "keep on making" was intended to cover basically the entire existence of MS, who have been doing stupid mistakes like this for as long as I can remember. And the "dumb idea of the month" is a figure of speech not referring to any specific month, neither present nor past.

      The guy is hiding behind a 3 digit ID

      No, the ID is too short to hide behind. :-)

      --
      Assorted stuff I do sometimes: Lemuria.org
    10. Re:deserved by dbIII · · Score: 1

      Get your English teacher to look at the post and draw some pictures for you to explain what it means. Tell me if they contain a clock or calendar.
      What is it with these idiots trying to get something out of nothing?

    11. Re:deserved by dbIII · · Score: 1

      Why are you pretending to be too stupid to understand the above post? Surely you know to look at the words around the ones you've taken out of context?

    12. Re:deserved by Anonymous Coward · · Score: 0

      I did have a nice, long, thought out response to your comments regarding him hiding behind a low UID, but it's irrelevant because you are the one who created the issue out of thin air.

      So, I'll just regress to this retort: You, sir, are a complete fuckwad.

    13. Re:deserved by Bender0x7D1 · · Score: 1

      No, the ID is too short to hide behind.

      That is one of the greatest smack-talk comebacks of all time. My hat is off to you good Sir.

      --
      Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
    14. Re:deserved by BitZtream · · Score: 0

      Shouldn't they have reimplemented this feature in userspace at some point during that long process?

      No.

      Doing so would have broken compatibility of a LOT of applications that use that API, and you don't do that between major OS releases. Well, okay, people with customers don't do that between real OS releases, I realize no one in OSS gives a flying fuck about compatibility since 'YOU HAVE THE SOURCE' but for OSes that people care about, API compatibility is important.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    15. Re:deserved by BitZtream · · Score: 1

      Just curious, can you name an OS that doesn't do it in one form or another?

      Keep in mind, just because you aren't parsing raw file data doesn't mean you aren't parsing. Parsing memory from an ioctl is still doing the same thing, might be a simpler file format, like say a C structure, but its still parsing.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    16. Re:deserved by Waffle+Iron · · Score: 1

      Tell me how an application can tell whether a particular parsing task takes place ring 0 or in user space.

    17. Re:deserved by Tom · · Score: 1

      Just curious, can you name an OS that doesn't do it in one form or another?

      I can name two that had a font-rendering kernel exploit in 2009. You'd have thought their manufacturer would check his other products for the same or similar problems...

      And yes, I know quite a few OS who don't do complex operations like that in kernel space, but push it into user land and reserve the kernel space part to simple operations that are more likely to be done with less bugs.

      Yes, you need to do stuff with data, and sometimes that data comes from the outside. But name me one reason why font rendering - instead of the pixel result that the graphics card needs to know - has to happen in kernel space.

      --
      Assorted stuff I do sometimes: Lemuria.org
    18. Re:deserved by bill_mcgonigle · · Score: 1

      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?

      It's faster and easier and they're able to externalize the consequences.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  11. NoScript helps by impaledsunset · · Score: 1

    That's why NoScript disables embedded fonts along with other possible attack vectors.

    Even on GNU/Linux, font rendering is not to be assumed safe. In particular, freetype was never designed with the idea to parse fonts from various untrusted sources, so security in the font parser has always been secondary up until recently, so there might be many security holes in it lurking. It also had a vulnerability lately, of course it got quickly fixed.

    http://hackademix.net/2010/03/24/why-noscript-blocks-web-fonts/

    1. Re:NoScript helps by Tomato42 · · Score: 1

      Well, yes, X server still is run as root on many distros, but they are moving away from it.

    2. Re:NoScript helps by fatphil · · Score: 1

      Worse than just being root, it has read and write access to /dev/mem. Which in theory means if it's stack smashed it could scan memory for sensitive information (such as the cached/saved passwords in your browser), and even rewrite the syscall vector table and handlers i.e. maliciously "patching" your kernel on-the-fly.

      --
      Also FatPhil on SoylentNews, id 863
  12. A lot of MS bashing going on in here.. by Anonymous Coward · · Score: 0

    If anyone is interested why MS does a lot of things in the kernel mode and how that isn't a bad thing I suggest him/ her to read Windows Internals 4th edition, chapter Operating system model. Of course you can screw up quite easily in k-mode and that's apparently what some unfortunate dev at MS did, but it doesn't mean that the whole design is flawed. That's for all those "omg bbq kernel mode is bad mmmkay" blokes.

  13. Re:let me guess... by Anonymous Coward · · Score: 0

    Oh, go ahead, mod me down

    You think people would mod you down for making fun of MS, here, of all places?

  14. Actually Apple made TTF fonts executable by Anonymous Coward · · Score: 0

    But I am an AC and this is slashdot, and I am not engaging in microsoft bashing so this comment will never see the light of day.

    http://en.wikipedia.org/wiki/TrueType

    1. Re:Actually Apple made TTF fonts executable by Fred+Or+Alive · · Score: 1

      You seem to be attempting to engage in Apple bashing, and that's fine here as well. It's a pity the article you linked to doesn't back up your assertion that TTFs contain executable code, at least not in the normal sense (it mentions code for a virtual machine to run hinting, but not normal executable code). This doesn't seem to be any issue with the True Type format itself, just an issue with Microsoft's implementation of it.

      --
      10 PRINT "LOOK AROUND YOU ";
      20 GOTO 10
    2. Re:Actually Apple made TTF fonts executable by Anonymous Coward · · Score: 0

      http://developer.apple.com/fonts/TTRefMan/RM02/Chap2.html#environment

      suck on it #738779

    3. Re:Actually Apple made TTF fonts executable by flonker · · Score: 1

      Pffft. Apple bashing is a perfectly respectable thing to do on slashdot these days.

  15. Sampo Kaasila an Apple employee by Anonymous Coward · · Score: 0

    Sampo Kaasila an Apple employee was the genius who designed True Type Fonts, and is also responsible for TTF's being executable files rather than some sort of parsed file. I am guessing he did it for performance reasons way back in the late 80's or very Early 90's when all we had to work with was 386/486 cpu's.

    http://en.wikipedia.org/wiki/TrueType

    1. Re:Sampo Kaasila an Apple employee by peppepz · · Score: 1
      Type-1 fonts are PostScript, hence executable, too.

      There's nothing wrong with that as long as you set the appropriate operational limits.

      Oh, and as an extra precaution, you might consider not parsing them in ring 0.

  16. 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 BitZtream · · Score: 1

      I'm fairly certain that since they've fixed this flaw so quickly that if they had known about it specifically, they probably would have fixed it.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:Xbox by Anonymous Coward · · Score: 0

      Assuming you're talking about the original Xbox, it was hacked with a hardware mod (involving a motherboard trace and a header for an external flash chip).
      The later software hacks were all based on HDD locking/unlocking, or vulnerabilities in games that Microsoft didn't code.

    3. Re:Xbox by crdotson · · Score: 1

      Sorry, I was pointing out the attack vector, not this exact vulnerability. A specially crafted font file on the original Xbox allowed for complete control of the system despite the fact that the BIOS would only boot a signed kernel. Given that fonts can be shipped inside PDF files, web pages, etc. now, the Xbox hack could have served as a good warning.

    4. 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...
    5. Re:Xbox by crdotson · · Score: 1

      The gamesave vulnerabilities allowed you to execute arbitrary code from the game to install the hack (you could also do so by hot-plugging the HDD so that you could access it unlocked). However, I believe it is the font vulnerability that allows it to boot 'hacked' each time without a hardware modification, even though the BIOS loads a signed kernel.

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

  18. Re:win32000? What? by rossdee · · Score: 1

    I was wondering if it was Windows Version 32768 - and since they are only up to Win 8 now that has to be way in the future.
    It will probably need a googolplex of RAM to run, and while it is booting up, you can go have lunch at Milliways

  19. Re:win32000? What? by Anonymous Coward · · Score: 0

    Windows crowd here -- no, we didn't. The referenced file is, in fact, a driver called win32k.sys.

  20. 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.
    1. Re:They should have known better by cavreader · · Score: 0

      I know in today's society it's become popular to blame the victim but don't you think the people who actually hacked the security share some of the responsibility for the time and money lost?

    2. Re:They should have known better by Anonymous Coward · · Score: 0

      I know in today's society it's become popular to blame the victim

      I don't think anyone in this thread has tried to blame the customers of a convicted monopolist, can you point me to such posts?

    3. Re:They should have known better by jthill · · Score: 1

      So it's ok to sell faulty armor into a war zone then.

      --
      As always, all IMO. Insert "I think" everywhere grammatically possible.
    4. Re:They should have known better by cavreader · · Score: 1

      This is a total BS comparison. It's not even an apple-orange type comparison it is more like an apple-Twinkies comparison. There is not a single operating system today that is 100%completely secure so are you willing to indict the entire industry? Software has always been a constantly and rapidly moving target. What was safe yesterday could very well be non-safe today. Hardware changes alone are frequent and require the existing software security at the OS level to be modified and re-tested. Changes from the client-server model to web based model also introduces numerous security issues. Hardware changes and computing architecture changes are required to provide backwards compatibility. You could end up making a OS so secure that it can not even run existing applications. Built-in system security is improving across the board because the main causes of security breeches now rely on social engineering, poor application development practices, and poor system administration practices.

    5. Re:They should have known better by jthill · · Score: 1

      Give it up. There's a difference between not being perfect and deliberately introducing flaws. Not one of your other objections has any bearing at all.

      --
      As always, all IMO. Insert "I think" everywhere grammatically possible.
    6. Re:They should have known better by rrohbeck · · Score: 1

      I can very well remember how many people criticized MS for moving the graphics subsystem into the kernel for a slight performance advantage. I liked NT3 with all its VMS heritage and it was clear that MS was spoiling the clean design.

    7. Re:They should have known better by cavreader · · Score: 1

      "deliberately introducing flaws" Do you have single variable instance of this happening or do you just create your on version of reality to compensate for your stupidity. And please point out what statement is factually incorrect in my previous post.

    8. Re:They should have known better by jthill · · Score: 1

      "Deliberately introducing flaws": I don't know where the actual failure in their code was, but truetype rendering is done by a full virtual machine. This isn't an exaggeration. Do chase that link: that machine is not simple, not by any measure. They're firing up an arbitrary user-supplied VM image in the kernel, and yes I say that constitutes a conscious introduction of a security flaw. Nobody could possibly have thought that was safe.

      True but obviously irrelevant statements "have no bearing" on the point. You might as well have said the air is cleaner now than it was then because we've had the EPA longer. It's true, but it's got nothing to do with them gratuitously importing an interpreter for an unusual, sophisticated VM into their kernel and then using that interpreter to run arbitrary VM images from userland. I gots a little clue for you: that was never, ever, ever safe, and they knew it. They did it deliberately.

      --
      As always, all IMO. Insert "I think" everywhere grammatically possible.
    9. Re:They should have known better by cavreader · · Score: 1

      Do you think a companies introduce functionality knowing before hand that it has exploits because they don't care? I would argue the exact opposite because of the time and money companies like MS, and many others as well, have had to expend to secure their systems. The only people quietly applauding security problems, besides those who exploit them for criminal purposes, are the companies who build the tools and sale the products to address security issues. Before the Melissa virus back in the dark ages there was no market for anti-virus products. After the virus was released it created a new and profitable industry overnight. I have always wondered if the person behind the Melissa virus had intended this to happen for the specific purpose of reaping the financial rewards. There have to be compromises and risk factors applied in any OS or application being developed. If no one released an OS because it *might* be exploitable there would not be a single OS in use. The font exploit vector in this thread requires manipulating the delivery method and getting specific user actions to activate the exploit. If you are talking about the overall security of the current state of all PC software architectures you could be correct. But how do you go about introducing a whole new paradigm and design architecture while still being able to support existing applications? At some point there will be a consumer OS that is designed from the ground up with no attempt to provide any backwards application compatibility but that won't be happening anytime soon. Even using a VM based approach which basically sandboxes the current operating systems and application processes require changes in the existing software systems. The heart of the matter is that a computers only purpose is to execute programs and malware falls into that category. The difficulty is trying to determine what operations are safe and what operations are not. When you get down to most basic OS level this determination becomes hard to identify.

    10. Re:They should have known better by jthill · · Score: 1

      introduce functionality knowing before hand that it has exploits

      What's with the red herrings, dude? Are you really unable to spot the gaping difference between that and what I actually said?

      On second thought, never mind.

      --
      As always, all IMO. Insert "I think" everywhere grammatically possible.
  21. Re:Microsoft's already issued a FIX by bmo · · Score: 1

    Come at me, bro.

    After you take your fucking meds.

    --
    BMO

  22. Re:Microsoft's already issued a FIX by Anonymous Coward · · Score: 0

    They did not publish a fix; they published a workaround that reduces the functionality of the apps running on the machine. This may be a good tradeoff for people who are especially worried about this particular attack, but even Microsoft doesn't try to spin it as a fix. They also announced that they will NOT have a patch for this out on the November patch Tuesday. That should actually be pretty obvious due to their test cycles and when this particular issue became known. At this point we don't know if they will issue an out of band patch later in November or wait for the December patch cycle.

  23. Re:Let the Penguins "chew on this" by Old+Sparky · · Score: 1

    Hey Mr Anonymous - you sound more like Ballmer every minute. And hold Microsoft accountable for security issues? Hyuk! That's FUNeee raht thar!!!

  24. 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 Gr8Apes · · Score: 1

      The graphics drivers I mentioned had all their utilities directly interacting at Ring 0, instead of running in User Mode.

      --
      The cesspool just got a check and balance.
    3. Re:NT4 was such an abomination... by Anonymous Coward · · Score: 0

      I ran a bbs on nt3.51, at the time, people at my local college could not answer the question "what is windows NT?" They simply didn't know the answer. IIRC at the time there was a bunch of A: drive worms swarming the college.

      Really though, when IDE drives finally came along, what an improvement over the good old days of having a pascal CMOS setup disc for the MFM drives, with the michael angelo virus on it. As soon as the operating system was installed, it would have to be cleaned from the michael angelo virus, (which only formats C on one day a year) is that ironic or what?

      Over the years, I never did get the correct pascal compiler, to create a clean setup disc. IF you were to find that disc in my collection today it would still have the virus on it.

      Oh and for the record I still have a few working 286's.

    4. 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
    5. Re:NT4 was such an abomination... by fatphil · · Score: 1

      I'll see your NT3.51 and raise you OS/2. Yes, it (version 2.0, IIRC) was sloooow on my 486/33 with 16MB of RAM, but as we're now running machines more than 100 times more powerful than that, such concerns should be irrelevant.

      --
      Also FatPhil on SoylentNews, id 863
    6. Re:NT4 was such an abomination... by yuhong · · Score: 1

      BTW, GDI is no longer single threaded in Win7.

    7. Re:NT4 was such an abomination... by RCL · · Score: 1

      To be fair, screens are also order of magnitude larger than they used to be (even more if you count memory and not pixels, since 99% of us have 32 bits per pixel these days and back then 8 bit was common), not to mention that having 2+ monitors is now standard for desktops. This, plus proliferation of antialased rendering offsets advancements in CPU power - to the point that navigating source code in QtCreator on my Linux box is not that smooth as I'd like it to be. Generally speaking, concerns about font rendering performance are still relevant.

    8. Re:NT4 was such an abomination... by shutdown+-p+now · · Score: 1

      NT 4 moved a lot of user space Windows GDI functionality (as defined by Win 95/98/ME)

      Did Win9x even have the concept of "user space" and "kernel space" as such?

      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

      That's bullshit. It doesn't "lockup your entire machine" - at best it would lock up Outlook, and that would be because it'd use a synchronous file API (open or read) for something that's on the network, from a UI thread. This doesn't have anything to do with GDI, or userspace/kernelspace distinctions.

    9. Re:NT4 was such an abomination... by Lorkki · · Score: 1

      This, plus proliferation of antialased rendering offsets advancements in CPU power - to the point that navigating source code in QtCreator on my Linux box is not that smooth as I'd like it to be.

      That almost certainly has more to do with either display sync issues (which sadly aren't uncommon on a composited X desktop especially with non-free drivers) or the various services of the IDE. Anti-aliased font and line drawing aren't that demanding to begin with, and can be GPU-accelerated with pretty much any hardware you might have picked up within the last five years or so.

    10. Re:NT4 was such an abomination... by Gr8Apes · · Score: 1

      NT 4 moved a lot of user space Windows GDI functionality (as defined by Win 95/98/ME)

      Did Win9x even have the concept of "user space" and "kernel space" as such?

      Of course not, but these functions or their predecessors originally resided in user mode in the original version of NT. On that time's hardware, it was slower than molasses and only ran acceptably for office type applications.

      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

      That's bullshit. It doesn't "lockup your entire machine" - at best it would lock up Outlook, and that would be because it'd use a synchronous file API (open or read) for something that's on the network, from a UI thread. This doesn't have anything to do with GDI, or userspace/kernelspace distinctions.

      You haven't tried this experiment on the appropriate software/hardware then. Downloading that through Outlook will lock up every other program that depends upon the GDI layer. This leaves any open Command Prompts responsive, and the Task Manager. You can't even open a new program from Task Manager because that also queues up in the GDI layer. From an open command prompt, you can run/launch anything that is not GDI bound. Alt-Tab still works, kind of. This particular pain is best experienced on a congested network with a large server load where a 10MB download can take 5 minutes or more.

      And before you go calling BS again, not all GUI programs utilized the GDI layer. Besides Task Manager, PMMail was one, ported from OS/2, it followed OS/2 conventions on I/O, utilizing separate threads for input/output and network connectivity.

      --
      The cesspool just got a check and balance.
    11. Re:NT4 was such an abomination... by Gr8Apes · · Score: 1

      I did say at least through all versions of XP, and as one commenter pointed out, this continued through Server 2003, which makes sense since XP64 (based on Server 2003) still exhibited this extremely annoying behavior.

      I haven't used any MS products for my main desktop in over 5 years, so I can't comment on Vista or W7, except that my exposure to W7 and Server 2008 R2 was more than a little underwhelming on the architecture and performance sides. IOW, nothing had changed, or rather, some things had gotten worse.

      --
      The cesspool just got a check and balance.
  25. Kick their ass APK (all they have is moddowns) by Anonymous Coward · · Score: 0

    They can't fight ur facts on security where "feeble freebie Linux" utterly BLOWS here http://tech.slashdot.org/comments.pl?sid=2510534&cid=37957838

    1. Re:Kick their ass APK (all they have is moddowns) by Anonymous Coward · · Score: 0

      Right. All BMO could do was mod this down http://tech.slashdot.org/comments.pl?sid=2510534&cid=37959052

  26. Pretty sure I was a victim by msobkow · · Score: 0

    The past week or so, my WIndows XP boot partition started behaving strangely. I had problems with Firefox and other applications that had never had problems before, and which had not been upgraded, and noticed a significant impact on download speeds.

    Avast didn't detect whatever it was, even with a boot-scan.

    Rather than play around trying to get rid of an unidentified virus, I nuked the XP boot partition completely and switched over to Linux full-time for now.

    On the bright side, it was over 8 years since the last time I got infected with an XP box, so I don't think it did too badly for it's time.

    --
    I do not fail; I succeed at finding out what does not work.
  27. Re:HOW TO KILL Duqu (w/ tools U own) by Anonymous Coward · · Score: 0

    ease on the paint from Redmond, bro

  28. Duqu DRIVERS & DLL's 2 KILL w/ RC by Anonymous Coward · · Score: 0

    Duqu uses cmi4432.sys, jminet7.sys, nfrd965.sys, & adpu321.sys 4 drivers & NETP191.PNF DLL

    (This is per Symantec's updated notes on it here http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf ).

    I.E. -> Use RC's DISABLE command on 'em (to stop them om loading at all period) - this will stop them from protecting a bogus bootsector @ least (which IS what most bogus rootkits do via drivers).

    * Also, if you want to "spot them", you can use LISTSVC (shows the state of ALL drivers AND EVEN SERVICES), first... to be sure they are there @ all!

    APK

    P.S.=> Once more - this SHOULD work, as it did vs. "the indestructible rootkit"'s HELLO_TT.SYS protectant of the bogus bootsector it uses... as long as the drivers don't protect their registry init/load areas? Again - this SHOULD work & with tools you already own, quickly... "Here endeth the lesson"... apk

  29. Why? FIX=logical per duqu mechanics by Anonymous Coward · · Score: 0

    As far anyone knows them in this current build @ least.

    Ala:

    1.) Kill the drivers in kernelmode/ring 0/rpl0

    2.) Refresh the bootsector using fixmbr

    3.) AND, if needed clean up usermode/ring3/rpl 3 using ProcessExplorer (for usermode malware it MIGHT haul in) OR just use RC DEL command... either way, it works!

    (Per my 1st post, you MAY have to do bootsector FIRST, & then driver disable, reboot to RC, & then do FixMBR! Depends on HOW this thing works!)

    * Fact is - I've done this before on "the indestructible rootkit" that used hello_tt.sys in fact, & it worked

    Should vs this too, that is, as long as those drivers do NOT protect their own reg init-load area? This works... period! I haven't seen documentation they do so... there you go!

    APK

    P.S.=>

    "ease on the paint from Redmond, bro" - by Anonymous Coward on Saturday November 05, @12:53PM (#37958834)

    You "penguins" might not LIKE the fact I make MS look good, but "tough cookies"...

    BOTTOM-LINE: I am just out to help folks "victimized" by this & other malicious code (like rootkits like these) is all with tools they already own!

    ... apk

  30. Kaspersky may have pointde to the bug before MS by AftanGustur · · Score: 1
    A Kaspersky Malware Lab expert blogged about this Here on the 2nd November and even gave the suspected DLL file win32k.sys:

    Symantec and Microsoft still haven’t made the actual dropper file available to other antivirus companies yet, nor have they provided information about which Windows component contains the vulnerability that results in privilege escalation. However, indirect evidence suggests that the vulnerability is in win32k.sys.


    We discovered a similar vulnerability (see MS10-073) a year ago when analyzing the Stuxnet worm. Another interesting problem in win32k.sys (MS11-077) was fixed by Microsoft on 11 October this year – a code execution vulnerability than can be exploited through font files.

    --
    echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
  31. Re:HOW TO KILL Duqu (w/ tools U own) by The+Askylist · · Score: 1
    I've only been working with Windows boxes since NT3.1 beta, so excuse my ignorance when I say that the reason I don't run Windows personally is because I prefer *nix (having been a HP-UX user for years before they inflicted NT on me).

    I'm sure that Windows now is much better than it was - in fact I'd go as far as to say that it's a pretty stable environment and OK for server use if the load's not too high. SQL Server's OK too, despite Microsoft rewriting bits of the Sybase code when it was stable to start with.

    But why do you have to be so shrill in your defence of what is, after all, a jumped up desktop operating system with poor file serving and stability that is conveniently full of holes and subject to frequent exploits? Yes, you can fix your MBR and disable the rootkit-installed drivers, but why run something that can be so easily owned in the first place?

    And on the point in question - NT pre version 4 really was a dog. Slow, unstable, prone to eating its own filesystem and becoming unbootable after a crash - NT4 was an improvement in terms of stability and speed, but at the cost of moving stuff like font parsing into the kernel, which people said at the time was stupid and dangerous, but Microsoft did it anyway.

    I'm sure you'll come back with some pre-teen styled rant, but don't bother - I'm far too old to bother with kiddies.

  32. Time 2 "kick penguin asses" (w/ facts) by Anonymous Coward · · Score: 0

    Are you too old to deal with facts on security then? This topic IS about security (and I gave you a way to remove it as well). You spoke of SERVER problems & exploits?? Here is some recent history below on THAT note (the only kind that counts, what's out there GOING ON TODAY)!

    Still - since you called me a "kiddie" (and I almost GUARANTEE I've done more of note than you have in the art & science of computing that did well in commercial software, tech trade shows, publication around computing from respected publications & more - AND, if you want FACTS ON THAT TOO? Just ask...)?

    This data's ALL from a respected source (secunia.com) for known security vulnerabilities unpatched & LINUX GETS BLOWN AWAY, badly!

    ---

    Vulnerability Report: Microsoft SQL Server 2008: (11/05/2011)

    http://secunia.com/advisories/product/21744/

    Unpatched 0% (0 of 1 Secunia advisories)

    Vulnerability Report: Microsoft Internet Information Services (IIS) 7.x: (11/05/2011)

    http://secunia.com/advisories/product/17543/

    Unpatched 0% (0 of 6 Secunia advisories)

    Vulnerability Report: Microsoft Exchange Server 2010: (11/05/2011)

    http://secunia.com/advisories/product/28234/

    Unpatched 0% (0 of 0 Secunia advisories)

    Vulnerability Report: Microsoft SharePoint Server 2010: (11/05/2011)

    http://secunia.com/advisories/product/29809/

    Unpatched 0% (0 of 3 Secunia advisories)

    Vulnerability Report: Microsoft Forefront Endpoint Protection 2010: (11/05/2011)

    http://secunia.com/advisories/product/34343/

    Unpatched 0% (0 of 1 Secunia advisories)

    Vulnerability Report: Microsoft Baseline Security Analyzer 2.x: (11/05/2011):

    http://secunia.com/advisories/product/6436/

    Unpatched 0% (0 of 0 Secunia advisories)

    Vulnerability Report: Microsoft Office 2010: (11/05/2011)

    http://secunia.com/advisories/product/30529/?task=advisories

    Unpatched 0% (0 of 9 Secunia advisories)

    Vulnerability Report: Microsoft Project 2010: (11/05/2011)

    http://secunia.com/advisories/product/31177/

    Unpatched 0% (0 of 0 Secunia advisories)

    Vulnerability Report: Microsoft Windows Services for UNIX 3.x: (11/05/2011)

    http://secunia.com/advisories/product/5244/

    Unpatched 0% (0 of 3 Secunia advisories)

    Vulnerability Report: Microsoft Internet Explorer 9.x: (11/05/2011)

    http://secunia.com/advisories/product/34591/

    Unpatched 0% (0 of 4 Secunia advisories)

    Vulnerability Report: Microsoft Virtual PC 2007: (11/05/2011)

    http://secunia.com/advisories/product/14315/

    Unpatched 0% (0 of 1 Secunia advisories)

    Vulnerability Report: Microsoft Visual Studio 2010: (11/05/2011)

    http://secunia.com/advisories/product/30853/?task=advisories

    Unpatched 0% (0 of 2 Secunia advisories)

    Vulnerability Report: Microsoft DirectX 10.x:
    (11/05/2011)

    http://secunia.com/advisories/product/16896/

    Unpatched 0% (0 of 3 Secunia advisories)

    Vulnerability Report: Microsoft .NET Framework 4.x

    1. Re:Time 2 "kick penguin asses" (w/ facts) by Anonymous Coward · · Score: 0

      Get lost, we don't want to learn "facts" of Microsoft here. We don't like you. Get over it.

    2. Re:Time 2 "kick penguin asses" (w/ facts) by Anonymous Coward · · Score: 0

      Facts: Linux = more unpatched security bugs than Windows Server 2008. Don't like it? U can't handle truth. Take ur own advice: Get lost (because you LOST, and you can't handle the truth of it).

  33. Re:FACTS vs. your "FUD" (that the "best you've got by Anonymous Coward · · Score: 0

    How on earth is it even possible for you to have so many letters in a post, and yet say nothing?

    Why don't you make sense? :(

  34. Re:HOW TO KILL Duqu (w/ tools U own) by Anonymous Coward · · Score: 0

    Shouldn't have shot ur mouth off. U got shot down 4 it http://tech.slashdot.org/comments.pl?sid=2510534&cid=37959108 and worst part is, he was helping U help ur ignorant obviously amateur self. What an ingrate U are.

  35. Re:win32000? What? by Anonymous Coward · · Score: 0

    I guess the title of the article should have included the ".sys" part.

  36. And this is why I have font downloading disabled by fast+turtle · · Score: 1

    In both Ie and FF. I'm sorry but those damn idiot web designers who insist that a 4px font is readable because they still use a 320x240 screen need to upgrade to something reasonable like 1024x768, means I've been forced to learn enough about CSS to begin creating my own overriding page to prevent those damn pesky and funky fonts/colors/sizes that make it impossible to read their sites. Of course, when I hit one of those sites, I add them to my block list though if I can get the custom css page working correctly, then I'll be a happy turtle.

    --
    Mod me up/Mod me down: I wont frown as I've no crown
  37. Nope, 3.5x had graphics in Ring 0 still by Anonymous Coward · · Score: 0

    NOT until NT 4.0 did they move GUI into RPL 3/Ring 3/Usermode.

    Just some refresher "FYI" for you - & your "oops" is OK, because it HAS been ages since those OS "walked the earth" (lol, like the ancient dinosaurs that they are).

    * Dave Cutler almost QUIT MS over it (He's NT's designer, & VMS before THAT for DEC... he was concerned over stability & it was a VALID concern, especially early on, drivers for graphics WERE unstable - that is, until the MS DDK got stable templates for it, & graphics card vendors got used to using it that way...)

    That's for BOTH user32 &/or GDI (which ran the GUI) in NT4x/2000/XP/Server 2003 too, mind you.

    APK

    P.S.=> Nowadays though, since the DirectX interface for GUI operations in VISTA/Win7/Win2k8Server are in AEROGLASS? It's back in Ring 3/RPL 3/Usermode, better for stability (not speed, yes, even though DirectX handles it, diff. tasks & data, but better suited for AERO to do it this way by far for speed) - and yes, it "holds true" in Classic Display shell too, and you can prove it easily:

    Install drivers there in VISTA onwards, & it DOES NOT REQUIRE A REBOOT in either case (Aero, or Classic)

    ... apk

  38. Re:Microsoft's already issued a FIX by Anonymous Coward · · Score: 0

    All you had's a weak unjustified mod down vs this http://tech.slashdot.org/comments.pl?sid=2510534&cid=37957838 ? Piss poor of you.

  39. Re:GLAD YOU ARE MODDED UP +5 by Anonymous Coward · · Score: 0

    It's funny both OldSparky and BMO took off after the thrashing you gave them.

  40. Only MS by bell.colin · · Score: 1

    Only MS can have a font compromise security.

    Somehow i was immediately reminded of this:

    http://www.theregister.co.uk/2001/02/02/bofh_gets_to_the_back/

  41. Both Old Sparky n' BMO left by Anonymous Coward · · Score: 0

    After U destroyed 'em here. Downmods of ur posts're all they have now.

  42. Re:GLAD YOU ARE MODDED UP +5 by Anonymous Coward · · Score: 0

    Funny that BMO n' Old Sparky left n' ur posts're being downmodded. Wonder who's doing that? Not. It's them n' all they have left is downmods n' off topic attacks which are weak. How humiliating for them both. They're probably the same person using TOR or alternate registered user accounts thru remote desktops to other machines to post thru to pull that fake register luser account crap that goes on here like mad and we all know it.

  43. Re:They should have known better, yes they should by Anonymous Coward · · Score: 0

    Unix networks and Novell networks existed long before NT4, remote exploits were already known.

    Microsoft failed.

  44. lol WTF??? by inode_buddha · · Score: 1

    Parsing fonts in-kernel...???
    Reminds me of how parts of IE were in kernel, or ActiveX.... I notice how much crap MS stuffed into their kernels over the years, and how each feature seems to correspond to a vuln.

    --
    C|N>K
    1. Re:lol WTF??? by shutdown+-p+now · · Score: 1

      How do you think ActiveX in the kernel would look like?

      Actually, let me rephrase that: do you know what ActiveX even is?

  45. Downmods of posts don't hide it from us BMO by Anonymous Coward · · Score: 0

    Posts like this http://tech.slashdot.org/comments.pl?sid=2510534&cid=37960506 and this http://tech.slashdot.org/comments.pl?sid=2510534&cid=37959052 and your down moderating them is a total admission of your failure here. Unjustified down mods don't hide facts from the rest of us you know. You're the one that has to live with it now. Oh the shame of it, hahaha, another penguin, blown away with facts.

  46. Modding a post down didn't hide it by Anonymous Coward · · Score: 0

    Who modded down the post parent to mine's a fool. That technique would work.

  47. Re:HOW TO KILL Duqu (w/ tools U own) by The+Askylist · · Score: 1

    Shot down? He merely reposted the same shit he'd already posted above, complete with shouty capitals, textish abbreviations and all the rest of the shit you expect from some paranoid and probably over-ritalined windows shill. I've only been programming since 1979, though, so perhaps he has done more than me. Wanker.

  48. Re:HOW TO KILL Duqu (w/ tools U own) by Anonymous Coward · · Score: 0

    The technique is sound, should work. This isn't about programming either (can you read?): It's about how to kill duqu or other rootkits that use the bootsector and drivers to protect it. Your name calling only makes you look even more foolish than mentioning programming here because it's not required.

  49. Re:let me guess... by Anonymous Coward · · Score: 0

    It even works second-hand. :-)

  50. Re:Illogical off topic adhominem attacks? by catman · · Score: 1

    You are sounding more and more like the wintrolls on c.o.l.a.
    Wipe the foam off your mouth and go to the rear of the class. You may come forward when you have gained some understanding of what you are talking about.