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

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

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: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: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!"

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.