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

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

[Anonymous Coward]

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

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

[Attack DAWWG]

Hmm . . . cue the Microsoft apologists in even less time than that, I guess.

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

[yakumo.unr]

cue hahaha I switched to 64bit the moment I could in....er, now.

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

[jbezorg]

Cue the "cue the" comments in 3, 2, 1, 0, -1, -2, -3....

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

[Anonymous Coward]

Windows Sucks. But then you obviously knew that already.

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

[darkpixel2k]

Cue the "cue the" comments in 3, 2, 1, 0, -1, -2, -3....

-1? Looks like you just found a bug that's been in Microsoft's Meta Countdown tool. This one goes all the way back to Windows 2.0.

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.

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

[neoform]

You just managed to make a recursive comment...

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

[IorDMUX]

I'm only 16 bits, you insensitive clod!

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

[bami]

More like cue the comments in 3, 2, 5 days, 3 hours, 23 minutes, 8 minutes, 2 hours 15 minutes, 15 seconds, 'Any moment now', 2 years.

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?

[Jesterace]

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: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?

[Dynedain]

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?

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

[clarkn0va]

Recent events seem to suggest that the biggest threats, from MS's point of view, are media exposure and public opinion. The fact that this has now appeared on /. and other media outlets means it will likely be patched in the coming month or so; sooner if people get really loud about it.

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?

[recoiledsnake]

Yea such exploits do not happen in Linux.

http://news.zdnet.com/2100-9595_22-332141.html

http://www.theregister.co.uk/2008/05/21/massive_debian_openssl_hangover/

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

[clarkn0va]

Any code can potentially be compromised. The difference here is that anybody can audit or fix the Linux code, and many people and organisations have and do. So yeah, you're safer using Linux than Windows in that regard.

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

[TheRaven64]

Assuming, of course, that you're not running any binary blobs like, for example, the nVidia driver that had a remote exploit allowing an attacker to gain kernel privilege and wasn't fixed two years after it was first reported. No one outside of nVidia could audit the code and fix it, but other people (like the person who reported it) had found it and were able to exploit it.

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

[Nadaka]

The same thing "could" happen in the Linux kernel, true. But that does not mean it "isn't safer" to use linux over windows.

You will never be able to review the source code of your windows OS. You "can" do so in linux. For a sufficiently small linux distro, you could inspect the code yourself. There used to be linux distro's that fit on a single 1.44 mb floppy, I have had a hard time finding them now, smallest I can find recently is about 2mb. If you are an expert, thats small enough to review in a couple years. In a modern distro, it would be impossible for an individual to vet the entire code base, it would not be impossible for an organized, determined group of a few thousand experts to do so. I believe that the NSA does just this with selinux, or at least thats the claim.

The point I am making is that under the open development model, every change to the code is reviewed and inspected by several different people before it is included, this may not happen in a closed environment. Even after a change is approved, implemented and distributed, the availability of the source to everyone makes it more likely that such flaws are noted soon and then fixed quickly.

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?

[plague3106]

Except that as those exploits prove, people AREN'T auditing the code. Otherwise, how would they end up in the wild?

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

[John Hasler]

> Guess I'm glad I run 64bit.

Why do you assume that you are not subject to a different but equally appalling set vulnerabilities? The same people wrote 64bit Windows.

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

[TheCycoONE]

You should have probably read the link. Buffer overflow allowed code to run as root (because the nvidia drivers do)

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

[John Hasler]

True. For home users you just pop up a window saying "Click here to install keylogger".

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?

[snemarch]

Good luck auditing even such a "limited" part as the kernel, even if you've got a full team of people - claiming that any individual could audit an entire distro is lunacy.

And it's not like serious bugs haven't had long timespans in linux before they were discovered; probably not any that were present as long as the NTVDM bug :), but still - shows that having the ability to audit the code doesn't help _that_ much if nobody are actually doing it.

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

[0xdeadbeef]

Yes, but Linux is secure the same way OS X is secure - nobody cares enough to exploit it.

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

[X0563511]

Yes, exactly. You will notice that that error was found and corrected fairly quickly, and didn't rot around for almost two decades...

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

[tacarat]

So it's not Windows vs Linux security, but a Closed vs Opens source security discussion.

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?

[dpilot]

Elsewhere in this thread there are comments like, "Just because it can be audited doesn't mean that it is," etc. Those comments are to a true, to a certain extent. Certainly long-hiding bugs have been found in the Linux kernel and software.

But there is one other factor at work, here. I've spent a few decades in the corporate world, and I can guarantee that the first response will be political/legal. Technical issues will come later. Let's say that Joe Coder-in-the-trenches finds a lurking bug in the source code that can be exploited. He reports it, and it starts moving up the management chain, probably gaining urgency as it goes. But at some point, some level of management is going to say, "What would an emergency patch for this look like to our customers?", "What does this do to our statistics?", "What are the potential liabilities?", etc. At that point, the patch will go in, and it will get fixed, but it will be put into "the process" and run through as quietly/non-disruptively as possible. The longer a bug has existed without being exploited, the more delay in "the process" will be tolerated.

I've also seen situations where patching a bug is interpreted by management as "admission of guilt," and then they start worrying about liability/recall type issues. In particular there was once a situation where they stonewalled a problem so hard that it when it finally broke, of course they got dynamic, let us fix it the way we'd been pushing to do, took credit, and gave themselves nice pat$ on the backs. In that case, it was at least decent that they didn't punish us other than during the stonewalling phase. We even got some pat$ on the back, too.

I have more confidence that such decisions in Linux will be technically, not politically based. I also know that there are personality issues, so it's not 100%, but it will generally be better.

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

[aztektum]

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

[kellyb9]

You must be new here. Negative media exposure for Microsoft on /. is pretty much the norm.

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?

[Lunix Nutcase]

You will notice that that error was found and corrected fairly quickly

Actually it wasn't found until 2 years after the code was originally committed.

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

[welsh git]

Ahhh, Gcc doesn't like the smiley face at the end of line 20

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?

[H0p313ss]

Windows users are in the dark and fucked.

You make that sound like a bad thing.

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

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

[Bacon Bits]

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

[Obfuscant]

Presumably one has to have local access, since to provide input to the NVidia driver one needs a display server running locally and provide bogus input to it.

Since it was a display driver, all you had to do to exploit it was be able to see the screen.

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

[JesseMcDonald]

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.

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

[steelfood]

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.

Backward compatibility

[recoiledsnake]

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:Backward compatibility

[sys.stdout.write]

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.

Re:Backward compatibility

[sacrilicious]

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

There, fixed that for ya. :)

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.

Re:Backward compatibility

[slimjim8094]

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.

Re:Backward compatibility

[Blakey Rat]

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

Re:But does it run on Linux?

[recoiledsnake]

Linux has it's own version of such bugs. Yes, even with the 'many eyes' looking at the source, it does happen, F/OSS is no panacea.

From http://news.zdnet.com/2100-9595_22-332141.html

A hole has been found in Linux kernel versions stretching back eight years that is 'as trivial as it can get to exploit', according to the Google employees who discovered it.

Julien Tinnes and Tavis Ormandy, the security researchers who discovered the vulnerability, have already issued a patch for the flaw. According to a blog post written by Tinnes on Thursday, the hole "affects all 2.4 and 2.6 kernels since 2001 on all architectures", and is "the public vulnerability affecting the greatest number of kernel versions".

Re:64 Bit

[TeknoHog]

Yet another reason people need to abandon 32-bit OSs. Seriously. What's the point of using half the power of your CPU?

I only have 32-bit hardware, you insensitive clod!

Re:Free time.

[taviso]

Applications Welcome ;-)

Re:64 Bit

[simcop2387]

While its true that there will be some overhead from the increased address size, there is however something significant to be said about the increase in the number of General Purpose Registers in the cpu that you get access to when using x86_64 rather than just x86. It is very important to realize that x86 being such a register starved architecture has significant gains from the doubling of the number of registers available to a program, this can mean that many more loops can have some or most of their main variables in the extremely fast registers rather than having to go out and fetch them from memory on each use. Even with a large fast cache next to the CPU you still cannot beat the performance gains from being able to have twice as many things in GPR.

Re:Windows 7

[recoiledsnake]

Windows 7 64-bit is not vulnerable to this, and thats the version that is pushing heavily to OEMs and companies.

"OSs released since 1993"

[Dystopian Rebel]

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.

Re:"OSs released since 1993"

[HotBits]

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

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:But does it run on Linux?

[TheRaven64]

That's not an equivalent bug, because it affects all architectures. This bug is in some architecture-specific code for running the VM86 mode on IA32 chips. It doesn't affect NT 4 on Alpha, PowerPC, or MIPS, or any more recent versions on x86-64 or IA64.

WOWEXEC is still in use?

[filesiteguy]

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

Re:Free time.

[JustOK]

There's an app for that?

Re:But does it run on Linux?

[PitaBred]

The difference is how much faster it was fixed once it was discovered, and how much less work and money that it takes to run a new version of Linux. Switching from a vulnerable Win2K or NT to 7 is a VERY costly endeavor. Switching to a new version of Linux is not nearly as big of an undertaking.

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

WARNING: Technical stuff follows

[idontgno]

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

Re:WARNING: Technical stuff follows

[mantis2009]

does DOSbox require the MS-DOS subsystem?

Warning: Clueless editor writes panic headline

[flerlerp]

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.

Re:Warning: Clueless editor writes panic headline

[idontgno]

Relative to a 17-year latency period, yeah, 7 months is new-found. And full disclosure was new as of yesterday. To everyone but the discoverer and the OS vendor, that makes it new.

To crib some TV network's advertisement, "It's a rerun, but it's new to you!"

Not "Newly-Found"

[Len]

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

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.

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

I told you!

[Yvan256]

Windows 98SE rules!

Re:But does it run on Linux?

[TeXMaster]

Linux has it's own version of such bugs. Yes, even with the 'many eyes' looking at the source, it does happen, F/OSS is no panacea.

From http://news.zdnet.com/2100-9595_22-332141.html

A hole has been found in Linux kernel versions stretching back eight years that is 'as trivial as it can get to exploit', according to the Google employees who discovered it.

Julien Tinnes and Tavis Ormandy, the security researchers who discovered the vulnerability, have already issued a patch for the flaw. According to a blog post written by Tinnes on Thursday, the hole "affects all 2.4 and 2.6 kernels since 2001 on all architectures", and is "the public vulnerability affecting the greatest number of kernel versions".

Eight year is a pretty 'good' record, but Windows still wins by 7 more (NT3.5 released in 1994, more or less the time of release of Linux 1.0). Also notice that then Linux bug was fixed almost contextually with its report, whereas the one this article is about has not not been fixed 6 months+ after the report was acknowledged. This is where open source wins.

Re:Brought it on yourself

[daveime]

I have a 32 bit processor on a 32 bit motherboard and 2GB of DDR2.

Why in fucks name would I want 64 bit OS to do the same thing as I can do with a 32 bit OS, and mores to the point, why do *I* deserve crappy code written by someone else ?

You don't *have* to upgrade just because "it's the latest thing". And saying 64 bit is somehow better when it can't even run the same legacy code that 32 bit still can is hardly a valid reason to upgrade. (The fact that some of that legacy code is vulnerable is beside the point).

Re:Windows 7

[yuhong]

WOW is for 16-bit Windows apps, not DOS apps.

Wasn't rewritten?

[palmerj3]

So, you mean to tell me Microsoft lied all those times they claimed Windows was rewritten? Didn't see that one coming...

Re:Only 32-bit Windows builds?

[The Wild Norseman]

Oh, fuck me for not even reading the summary properly. :p

Nice try, dude. If that really worked, we'd all be getting laid like rock stars.

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?