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

Comments

How do we know it's not already in use?

[jollyreaper]

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?

Re:How do we know it's not already in use?

[Skratchez]

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.

Re:How do we know it's not already in use?

[TheRaven64]

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:How do we know it's not already in use?

[think_nix]

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:How do we know it's not already in use?

[maxume]

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.

Re:How do we know it's not already in use?

[Xest]

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.

Re:How do we know it's not already in use?

[Chatterton]

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

Re:How do we know it's not already in use?

[sconeu]

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

Re:How do we know it's not already in use?

[ei4anb]

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.

Re:How do we know it's not already in use?

[Anonymous Coward]

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.

Re:How do we know it's not already in use?

[recoiledsnake]

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

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

How long until we see the NT4 patch?

[gimmebeer]

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.

Re:Backward compatibility

[NJRoadfan]

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.

Small, small world...

[Zocalo]

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

You can review Windows OS code.

[140Mandak262Jamuna]

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()?

Re:Cue "Windows Sucks" comments in 5, 4, 3, 2, 1

[xtracto]

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

What still needs the Windows 16-bit subsystem?

[Animats]

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.

exploit as published doesn't work

[chentiangemalc]

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?

Re:WARNING: Technical stuff follows

[mantis2009]

does DOSbox require the MS-DOS subsystem?