Forgot your password?
typodupeerror
Windows Bug Microsoft Security Technology

Newly-Found Windows Bug Affects All Versions Since NT 393

Posted by Soulskill
from the staying-power dept.
garg0yle writes "A researcher has found a security bug that could allow privilege escalation in Windows. Nothing new there, right? Well, this affects the Virtual DOS Machine, found in every 32-bit version of Windows all the way back to Windows NT. That's 17 years worth of Windows and counting. 'Using code written for the VDM, an unprivileged user can inject code of his choosing directly into the system's kernel, making it possible to make changes to highly sensitive parts of the operating system. ... The vulnerability exists in all 32-bit versions of Microsoft OSes released since 1993, and proof-of-concept code works on the XP, Server 2003, Vista, Server 2008, and 7 versions of Windows, Ormandy reported.'"
This discussion has been archived. No new comments can be posted.

Newly-Found Windows Bug Affects All Versions Since NT

Comments Filter:
  • by Anonymous Coward
    Cue "Windows Sucks" comments in 5, 4, 3, 2, 1....
  • by jollyreaper (513215) on Wednesday January 20, 2010 @11:19AM (#30832206)

    Every time I read about one of these long-undiscovered instant pwn bugs, I always have to wonder if there's someone sitting deep underground in an NSA computer center saying "Well shit, looks like we'll not be using that exploit anymore."

    Is this a hole nobody knew about or a hole nobody but the people who knew about it knew about, and those people weren't talking?

    • by Skratchez (1304839) on Wednesday January 20, 2010 @11:24AM (#30832262)
      My first thoughts exactly. I've always assumed any Windows PC I'm using could have been rooted long ago to an extent that no security tool could detect or repair it. I guess I'm just paranoid, I should really just switch to a Linux distro and start compiling my own kernels. As if I wouldn't screw that up too.
        • by aztektum (170569) on Wednesday January 20, 2010 @12:58PM (#30833872)

          One of the big differences here is that those bugs are fixed and were fixed rather quickly. How long will we have to wait for MS to do anything about this one? Will they simply suggest people use 64-bit Windows? They're going to take a stance that they feel best benefits them and, until they do, Windows users are in the dark and fucked.

          • Re: (Score:3, Funny)

            by H0p313ss (811249)

            Windows users are in the dark and fucked.

            You make that sound like a bad thing.

          • by Bacon Bits (926911) on Wednesday January 20, 2010 @02:24PM (#30835138)

            Well, look at the vulnerability. It's in the Virtual DOS Machine. That means you have to get 16-bit code onto the system and then make Windows execute it. So, in order to exploit the vulnerability, you've already got to have local access. No wonder Microsoft is dragging their feet. It's only exploitable in cases where you can already gain access to the system. If you're not logged on, I don't see any way to exploit this. It's not like you could even put 16-bit code in a buffer overrun and expect the kernel to execute it. It's got to be run through the NT Virtual Dos Machine or Windows-on-Windows, or it's not executable code.

            I'm sure someone will correct me if I'm wrong, but AFAIK there's no possible way to remotely exploit this (outside of another vulnerability). It's a Moderate vulnerability at best.

            • Re: (Score:3, Insightful)

              by JesseMcDonald (536341)

              This exploit lets any unprivileged local user inject arbitrary code into the kernel, and you think it only deserves a rating of moderate? Apparently you've never heard of local privilege escalation. This reduces the actual security of every NT-based Windows system to the single-user "security" last seen in Windows ME.

              Sure, it's not a remote exploit (yet). That doesn't mean it's not a major issue, particularly for those administering multi-user systems and/or network domains.

            • by steelfood (895457) on Wednesday January 20, 2010 @05:02PM (#30837480)

              there's no possible way to remotely exploit this (outside of another vulnerability)

              Your caveat says more than the rest of your post. Considering how many external-facing exploits exist, and how many probably remain undiscovered, I wouldn't be surprised if this one is often used to root a machine once it's been compromised. You can clean infected files, but only if you can detect them, and they're separate and distinct from your files.

              One external-facing exploit can wreck havoc before it's fixed or the machine's reformatted. Add this one into play, and the operator simply won't realize the machine's compromised.

      • by Chatterton (228704) on Wednesday January 20, 2010 @12:11PM (#30833042) Homepage

        If you are really paranoid, you will write yourself your own C compiler or else this could happen:
        http://scienceblogs.com/goodmath/2007/04/strange_loops_dennis_ritchie_a.php [scienceblogs.com]

      • by kalirion (728907)

        I should really just switch to a Linux distro and start compiling my own kernels

        Don't forget to compile your own compiler...... Oh wait.... Better write it in binary on a computer you've assembled yourself from parts you've created yourself.

      • by sconeu (64226) on Wednesday January 20, 2010 @12:38PM (#30833540) Homepage Journal

        You've got to build your own toolchain, too.... from the bare metal.

        Reflections on Trusting Trust [bell-labs.com].

        And I guess you have to trust the CPU not to have backdoors, too...

    • Re: (Score:2, Insightful)

      by Jesterace (914041)
      Well the article says that Microsoft was notified of this bug June 2009. Guess they feel it isn't that big of a threat if they haven't patched it as of yet. But then again that's nothing new. Guess I'm glad I run 64bit.
    • Re: (Score:3, Interesting)

      by TheRaven64 (641858)

      For a lot of them, that's almost certainly true. This one is interesting though. It's in the virtual MS DOS subsystem. This hasn't changed a huge amount of attention since NT 3.5. Someone might have found it back then, but if they didn't then it's more likely that they'd have focussed their attention on new code in new versions.

      It's also worth noting that this doesn't affect 64-bit kernels for the very simple reason that they don't support 16-bit compatibility and so don't have the affected subsystem

    • Re: (Score:3, Insightful)

      by Dynedain (141758)

      Is this a hole nobody knew about or a hole nobody but the people who knew about it knew about, and those people weren't talking?

      Well we don't really know do we?

      • by timeOday (582209)
        We can be pretty sure it wasn't widely exploited, otherwise somebody somewhere would have noticed.
      • Is this a hole nobody knew about or a hole nobody but the people who knew about it knew about, and those people weren't talking?

        Well we don't really know do we?

        That is usually how it works with a lot of zero day or hardcore exploits from security researchers. Vendors/Developers are notified and given time to fix it until it is made public so the said fix is there before it is widely known.

    • by think_nix (1467471) on Wednesday January 20, 2010 @11:33AM (#30832392)

      funny how the security researcher (TFA) works at google , and now with the google china scenario this bug is now getting press when it was reported back in june 2009 , and still has not been fixed.
      Wonder if all these new MS & IE bugs exploits being made known through google are due to lack of solidarity on some issues between google / ms ?

    • Re: (Score:2, Interesting)

      by maxume (22995)

      It's a problem for corporate security, but for home users that were running XP as Administrator already, it doesn't do much to help the untrusted code that they chose to execute.

    • by noackjr (541550)
      Requisite Rumsfeld:
      http://www.youtube.com/watch?v=_RpSv3HjpEw [youtube.com]
    • Re: (Score:3, Interesting)

      by ei4anb (625481)
      Two of the vulnerabilities that I discovered (and wrote exploit code for) in 1979 still have not been rediscovered, or at least not published. They were useful for about 12 years but that OS is no longer widely deployed. So, yes it is possible.
  • by recoiledsnake (879048) on Wednesday January 20, 2010 @11:30AM (#30832338)

    This is the cost of backward compatibility at the expense of everything else. That is what made Microsoft and that is what may break it.

    • Re: (Score:2, Insightful)

      This is the cost of backward compatibility at the expense of everything else. That is what made Microsoft and that is what may break it.

      Yeah, people hate it when their applications continue to work after buying a new computer.

      • by Taevin (850923)
        Short-term backwards compatibility is one thing, but when do you draw the line? If I remember my history correctly, Windows 95 was the first 32-bit Windows operating system, the last release of which was 12 years ago.
        • Re: (Score:3, Interesting)

          by NJRoadfan (1254248)

          Short-term backwards compatibility is one thing, but when do you draw the line? If I remember my history correctly, Windows 95 was the first 32-bit Windows operating system, the last release of which was 12 years ago.

          Windows NT 3.1, which this bug first appeared, was released in 1993. The one nice thing about NT's VDM and WoW subsystem is that it froze the Win16 API/environment so any 16-bit applications that worked with NT basically kept working without any new bugs up to Windows 7 32-bit. My old Windows 3.x apps kept working through various versions of NT, yet my Win32 apps kept breaking with each upgrade, go figure.

      • Re: (Score:3, Funny)

        by sacrilicious (316896)

        Yeah, people hate it when their applications continue to crash after buying a new computer.

        There, fixed that for ya. :)

      • by JustOK (667959)

        Yah. Same thing when I converted from a horse to a car. Had a hard time converting all that hay to gas.

      • by nedlohs (1335013)

        Which is the "what made" point. Do you enjoy just repeating half of the posts you reply to?

      • Re: (Score:3, Insightful)

        by slimjim8094 (941042)

        Mac OS X managed to move from MacOS to a Unix - a far more significant change than anything Windows has done - without breaking much at all. Same with PowerPC to x86.

        Backwards compatibility doesn't need to be integral. In fact, it's probably safer if what's been deprecated is made really obvious.

        • by Blakey Rat (99501) on Wednesday January 20, 2010 @02:47PM (#30835546)

          Mac OS X managed to move from MacOS to a Unix - a far more significant change than anything Windows has done - without breaking much at all.

          Buulllshiiittt.

          Spoken like a true, "I never touched Classic Mac in my life." The reason people say shit like this is only because Apple has *always* been so bad about breaking apps, that they didn't break any *more* than expected when OS X came out. (Remember the legions of apps that System 7 busted when it came out? Christ. Expectations are pretty low compared to that.)

          I switched away from OS X when it became apparent that:
          1) Classic would never be fixed to run more apps, nor would its more substantial flaws be fixed. (For example, how it drained laptop batteries like crazy for no reason.)
          2) Apple doesn't give a shit about anything older than about 3 years. For example, my parents can't use their camcorder with their laptop because, while OS X supports USB camcorders, it only supports them on x86 and their computer is a very-late-model PPC

          In the Mac world, if you don't upgrade once a year, you're fucked. I don't have the money or patience for that.

          Same with PowerPC to x86.

          That went smoother, as did their transition from 68k to PPC. But that just means they usually break apps for reasons other than CPU changes. :)

  • A lot of people don't care about local vulnerabilities, until they can be turned into remote or turn "secure" browsers running everything with limited privileges into something that runs with administrative rights.

    In particular, if that could be used to turn the "safe" IE8 into something unsafe could lead into more governments asking their citizens to stop using IE, any version of it.

    • It's a privilege escalation vulnerability, so if there is a hole in IE 8 then it becomes a remote root hole, rather than a remote unprivileged hole. I'm not certain about IE 8 in limited mode. It's possible that the ACL for this is configured to prevent starting VDM processes, but if it isn't then it becomes possible to escape from the sandbox after compromising IE 8 (that, at least, is easy to fix with a minor tweak).

      Really though, VDM should be thrown away. It works less well than DOSBox and requires

      • by TheLink (130905)
        Privilege escalation isn't a big deal for "desktop users" in practice because:

        1) The windows crowd are already running as admin, or they'll just click "OK" as many times as it takes to see the dancing pigs/bunnies.
        2) The linux crowd if they are not running as admin, are often running unsandboxed browsers (e.g. firefox) using the same account they are logged in as. That means if the browser is exploited, the malware can access all their precious data, credentials, certs, emails on their local filesystems and
  • Ormandy said the security hole can easily be closed by turning off the MSDOS and WOWEXEC subsystems. The changes generally don't interfere with most tasks since they disable rarely-used 16-bit applications. He said he informed Microsoft security employees of the vulnerability in June.

    So, to be clear, is this only about 32-bit Windows builds then?

    64-bit Windows doesn't even support running 16-bit applications. And that's what WOWEXEC is all about. However, I'm less sure about this "MSDOS" subsystem in 64-bit builds? What's that for, anyway? The console emulation?

  • by Dystopian Rebel (714995) * on Wednesday January 20, 2010 @11:47AM (#30832632) Journal

    Slashdot makes me sick. It's just not fair to go digging 14 years prior to the date when Microsoft finally starting taking security seriously.

    • by HotBits (1390689) on Wednesday January 20, 2010 @01:33PM (#30834444)

      ... Microsoft finally starting taking security seriously.

      Where starting is the operative word. Here is one indication of how far they still have to go:

      Visit the Microsoft Online Safety password checker (https://www.microsoft.com/protect/fraud/passwords/checker.aspx). Try “Password1”.

      Wow, a "Strong" password! They don’t even do a simple dictionary check. Same is true in the OS from what I’ve seen so far.

      How long has that been built into Linux?

      From what I’ve seen in the field, dictionary attacks are the first thing malware attempts to gain control of a network.

      They are just starting to be serious about security.

  • So much for 'nobody writes hacks for old stuff anymore, if we just keep running NT we'll never get hacked' Sounded good at the time.
  • by filesiteguy (695431) <kai@perfectreign.com> on Wednesday January 20, 2010 @11:50AM (#30832670) Homepage
    Actually, I was just messing around. I'm kind of suprised it took someone this long to find a vulnerability in wowexec. I'm sure MS is not even thinking much about this, yet pretty much any program can have the possiblity of a buffer overrun or some sort of registry memory shift.

    I found it funny that the Google ad displayed next to the article was for Microsoft forefront touting the security features.

    http://www.perfectreign.com/stuff/2010/forefront.jpg
  • by idontgno (624372) on Wednesday January 20, 2010 @12:04PM (#30832908) Journal

    Vulnerability applies to 32-bit Microsoft Windows operating systems with Windows NT 3.5 heritage.

    Vulnerability arises from ancient coding or design flaws in the MS-DOS execution subsystem. This subsystem is not present in 64-bit Windows OSs.

    The workaround is to disable the MS-DOS subsystem.

    Great article at the SANS Institute Internet Storm Center: http://isc.sans.org/diary.html?storyid=8023 [sans.org]. This includes links to Youtube videos on how to use Windows Group Policy tools to disable this subsystem.

    However, once you do this, you won't be able to run 16-bit DOS-based software, so if you really need that you may have to wait for a patch. Or build a dedicated DOS machine, where at least you'll have no illusions of security. (Cynics would say this is true of any MS operating system, but I leave that debate to others.)

  • This isn't a "Newly-found" bug. It was discoverd and reported to Microsoft on 12-Jun-2009. Not sure what's worse: An OS vendor whom doesn't patch holes quickly or a blog editor whom is clueless and uses inaccurate headlines to waste readers time.

  • Not "Newly-Found" (Score:5, Insightful)

    by Len (89493) on Wednesday January 20, 2010 @12:18PM (#30833162)

    Microsoft was informed about this vulnerability on 12-Jun-2009, and they confirmed receipt of my report on 22-Jun-2009. Regrettably, no official patch is currently available. As an effective and easy to deploy workaround is available, I have concluded that it is in the best interest of users to go ahead with the publication of this document without an official patch.

    from Tavis Ormandy's disclosure [neohapsis.com]

    So the bug was found six months ago, but Microsoft only decided it was serious enough to fix after it was publicized. Seems like another case of "responsible disclosure" being used to cover up a vulnerability, instead of fixing it (or publishing a workaround) before the bad guys find out about it.

  • I told you! (Score:4, Funny)

    by Yvan256 (722131) on Wednesday January 20, 2010 @12:21PM (#30833232) Homepage Journal

    Windows 98SE rules!

  • by Animats (122034) on Wednesday January 20, 2010 @02:05PM (#30834854) Homepage

    Does any major software still need the 16-bit subsystem?

    Amusingly, when I first installed Windows NT 3.51, back around 1996, the 16-bit subsystem was optional, like the OS/2 subsystem, and I had it turned off. Everything worked fine. In NT 4, they let the kode kiddies from the Windows 95 group put legacy code into NT, some of which still ran in 16-bit mode, and the 16-bit subsystem was always on.

  • by chentiangemalc (1710624) on Wednesday January 20, 2010 @02:53PM (#30835674) Homepage
    I've tested the exploit in virtual machine in Windows 7 x32 and Windows XP SP3 and it doesn't work. These are default installs of OS with no config changes. When run in Windows 7 x32 as Administrator it did cause BSOD. Running as standard user it did nothing, the process supposed to have escalated priviliges did not. anybody else found it working?

Those who can, do; those who can't, simulate.

Working...