Slashdot Mirror


Newly-Found Windows Bug Affects All Versions Since NT

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

24 of 393 comments (clear)

  1. How do we know it's not already in use? by jollyreaper · · Score: 5, Interesting

    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?

    --
    Kwisatz Haderach
    Sell the spice to CHOAM
    This Mahdi took Shaddam's Throne
    1. Re:How do we know it's not already in use? by Skratchez · · Score: 5, Interesting

      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.

    2. Re:How do we know it's not already in use? by TheRaven64 · · Score: 2, Interesting

      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.

      --
      I am TheRaven on Soylent News
    3. Re:How do we know it's not already in use? by think_nix · · Score: 5, Interesting

      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 ?

    4. Re:How do we know it's not already in use? by maxume · · Score: 2, Interesting

      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.

      --
      Nerd rage is the funniest rage.
    5. Re:How do we know it's not already in use? by Xest · · Score: 4, Interesting

      More likely Google discovered this one as a result of a security audit in the light of the Chinese attacks against them.

      Interestingly though, the parent may have a point, it could be that this one of the exploits the Chinese used internally at Google precisely because they have known about it so long.

      But still, who knows.

    6. Re:How do we know it's not already in use? by Chatterton · · Score: 4, Interesting

      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

    7. Re:How do we know it's not already in use? by sconeu · · Score: 4, Interesting

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

      Reflections on Trusting Trust.

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

      --
      General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
    8. Re:How do we know it's not already in use? by ei4anb · · Score: 2, Interesting

      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.

    9. Re:How do we know it's not already in use? by Anonymous Coward · · Score: 1, Interesting

      The argument that linux is safer because anyone can audit and fix the code isn't entirely sound. Anyone can also audit and exploit, if they choose. There's no such thing as a secure OS. I'll continue to favour obscurity over openness until the day everyone leaves their house doors unlocked.

    10. Re:How do we know it's not already in use? by Anonymous Coward · · Score: 2, Interesting

      I remember when I found a bug in the network login script at the company I worked for (huge international company btw) in the late 80s.
      A weird combination of commands dropped me through to a network server (NetWare, if I remember correctly) command line interface, allowing me to modify stuff I shouldn't be allowed to.

      I contacted the it-department and told them about the bug. Their first reaction was that I was abusing the network and should be fired, mostly because they were embarrassed by the situation, I think.

      After they discussed the whole thing with my boss I became a member of the company security group instead.

      The next time I found a security hole in a company product I hesitated before reporting it.

    11. Re:How do we know it's not already in use? by recoiledsnake · · Score: 2, Interesting

      So why didn't it stop this 8 yr old exploit?

      http://isc.sans.org/diary.html?storyid=6820

      --
      This space for rent.
    12. Re:How do we know it's not already in use? by Anonymous Coward · · Score: 1, Interesting

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

      I know a penetration tester that went into law enforcement over a decade ago that uses that trick. As well, there's a buffer overflow in the FAT16 code that allows arbitrary code execution in ring 0. Good luck trying to find it, though... it's quite subtle, but like this one also depends on memory pointers being 32bits. /Posting as AC because the NSA is really the least of my worries.

    13. Re:How do we know it's not already in use? by westlake · · Score: 1, Interesting

      The difference here is that anybody can audit or fix the Linux code, and many people and organisations have and do.

      Which - taken literally - implies that Linux could fragment into a thousand or ten thousand unique "distributions."

      Each with their own hodgepodge of patches.

    14. Re:How do we know it's not already in use? by Anonymous Coward · · Score: 1, Interesting

      I'll continue to favour obscurity over openness until the day everyone leaves their house doors unlocked.

      Bad analogy. Leaving the door unlocked on a house implies you don't have any security at all because you trust everyone in your (usually small) community and that's not the case with open source (although that is still the case in some small towns where everyone knows everyone else). Perhaps you could make a case if you said you made your "open" house out of wood and proprietary houses are made out of lead, while knowing that the bad guys can commonly use X-ray machines. Either of the two houses might have ways to break in, through the roof or through unlocked doors or windows. It's easier for both you and the bad guys to use X-ray machines to spot those vulnerabilities in the wooden house but you have to have the discipline and process to do that regularly and fix problems you find. It's also a bigger risk in the wooden house to not check everything if you have young kids unlocking doors and windows. But living in the lead house doesn't help you if you also leave a lot of unlocked doors and windows and someone actually goes up and checks them instead of doing it from the curb with an X-ray machine. However this analogy probably breaks down when you talk about newborns and toddlers gnawing on the lead house.

    15. Re:How do we know it's not already in use? by Anonymous Coward · · Score: 1, Interesting

      Moderate or above! easily
      easy email spam with malicious payload
      MS advice on not using administrator accounts is no defense against this browsing the web or email.

      In corporate environments this is trouble
      1000s of users with limited terminal user access to RDP, 2008 terminal services and Citrix in limited user accounts can install root kits on the shared machines, worse a kernel level keylogger, dos attack or network trawler.

  2. How long until we see the NT4 patch? by gimmebeer · · Score: 2, Interesting

    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.

  3. Re:Backward compatibility by NJRoadfan · · Score: 2, Interesting

    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.

  4. Small, small world... by Zocalo · · Score: 2, Interesting

    Interesting co-incidence that you should bring up that example. Tavis Ormandy, one of those who discovered the Linux kernel bug you mentioned, was also the one who posted the details on the Windows 16bit VDM bug that we're discussing here to Full Disclosure yesterday. I guess he must like his code to be covered in cobwebs or something...

    --
    UNIX? They're not even circumcised! Savages!
  5. You can review Windows OS code. by 140Mandak262Jamuna · · Score: 4, Interesting

    You will never be able to review the source code of your windows OS.

    All you have to be is Chinese Government. That is all. You think the Google hack was found by relentless probing of defenses of the WinOS? Or did they have to just grep through the WinOS source code for things like strcpy()?

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  6. Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1 by xtracto · · Score: 2, Interesting

    I am using Windows XP SP3 right now and the POC code provided does not work.

    --
    Ubuntu is an African word meaning 'I can't configure Debian'
  7. What still needs the Windows 16-bit subsystem? by Animats · · Score: 2, Interesting

    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.

  8. exploit as published doesn't work by chentiangemalc · · Score: 4, Interesting

    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?

  9. Re:WARNING: Technical stuff follows by mantis2009 · · Score: 2, Interesting

    does DOSbox require the MS-DOS subsystem?