Submitted by I guess it’s Windows-flaw-week or something. First, we had the Internet Explorer vulnerability used in the Google attack, and now we have a bug that’s been sitting undetected in Windows NT for 17 years. The bug can be used to escalate privileges, but from what I understand, it only works locally (although that isn’t made clear).
The flaw exists in the Virtual DOS Machine, which is a system that allows Windows NT to run DOS and 16bit applications on 386 (and up) machines. Google security team member Tavis Ormandy discovered a vulnerability in the VDM and reported it to Microsoft in the summer of 2009, but since it still hasn’t been patched, he went full-disclosure.
Basically, what happens is that a 16 bit program can escalate its privileges and gain unrestricted access to the entire system, but as far as I can tell (please correct me if I’m wrong) this is a local exploit: you need physical access to the system. This usually means normal users have relatively little to worry about, but of course, it can be used in social engineering attacks, or someone might find a way to exploit it remotely.
The vulnerability is present in all 32bit versions of Windows NT, starting with NT 3.51 and ending with Windows 7. Since 16bit support was dropped from the 64bit versions of Windows, users of Windows 64bit are not affected. The work-around is extremely simple and straightforward: disable the 16bit subsystem on 32bit machines.
This can be done one of three ways (but they all do the same thing: edit the registry). First, you can use the Group Policy Editor to enable the “Prevent access to 16-bit applications” in Computer Configuration\Administrative Templates\Windows Components\Application Compatibility. Second, you can also simply go rogue and edit the registry directly (backup! backup!) by placing a key in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat with a D-Word value of VDMDissallowed = 1.
The last method automates it all: create a text file called vdmdisallow.reg, and paste the following into the file, and double-click it:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat] “VDMDisallowed”=dword:00000001
Again, 64bit users needn’t worry. All this does raise a question we’ve sure raised before: at what point should Microsoft drop support for applications? How many people still use 16 bit applications? Wouldn’t it have made more sense to have it disabled by default on 32bit systems, and then enable it as soon as Windows detects someone is trying to load a 16bit application?
This is a local exploit and quite easy to fix, but my uninformed guess is that in conjunction with the IE flaw it could be used to escape protected mode.
Can a 32bit application like IE use the VDM? Any Win32 devs around?
PS. The Palin link is priceless.
According to the article:
So why would a win32 being interacting with a Virtual DOS Machine? Doth gentleman may not have read the article too much it seems.
With that being said, as far as I know, VDM along with win16 support has been ripped out of Windows x64 editions so the vulnerability seems to only affect 32bit version of Windows rather than Windows across the board. Hopefully this is even more incentive to companies to finally get away from Windows 32bit and start moving their internal applications to either web based on standards or using Silverlight instead of dinky VB6 based crap I still see floating around in the corporate world – even today.
Yup, 16bit support has been ripped from Windows x64 editions, since x64 Long Mode doesn’t support V86 tasks – Microsoft would’ve needed to include an x86 emulator in order to run 16bit DOS apps (16bit Windows apps do run protected mode rather than DOS/realmode, but I dunno whether Long Mode supports 16bit PM code segments; wouldn’t be surprised if it doesn’t).
Microsoft actually did include an x86 emulator with x64 Windows editions, albeit a very limited one. A very few things need to call 16bit BIOS code, so MS whipped up an emulator. It’s not usable for generic 16bit execution, though: undocumented, very limited CPU support, stringent checks on what memory can be accessed).
In case anybody’s interested (or wants proof), check these links:
http://x86asm.net/articles/calling-bios-from-driver-in-windows-xp-x…
http://www.geoffchappell.com/studies/windows/km/hal/api/x86bios/ind…
Edited 2010-01-21 01:37 UTC
AFAIK, it’s a hardware issue. AMD dropped 16-bit PM operation in 64-bit mode. The solution for Windows 7 is the fully-emulated VirtualPC copy of XP running in 32-bit mode. Ugly hack in a lot of ways, but it’s part of the price to be paid for adopting amd64/x64. If they were going to break backwards compatibility, they should have broken it good, and ditched the ability to make direct BIOS calls or boot 16-bit DOS at all. But AMD probably doesn’t have a license for EFI, and even if they had held one, Windows didn’t support it.
FWIW, I’m really curious whether this might potentially affect other OSes that support 16-bit PM applications. OS/2 would be one of the first ones that might be worth looking at.
Yep – that’s another way to say “long mode doesn’t support V86 tasks”
Yeah, that’d work, but it’s quite overkill for running 16bit DOS code… I’d start by trying my luck with http://www.dosbox.com/ , or perhaps even http://qemu.org/ .
Well, there’s a few situations where you’ll need it – the only one I know of, though, is the vanilla video driver that’s used until you install a vendor specified driver. Also, the x86Bios*() functions are so limited that they can’t really be used for much else…
A shame, EFI is a nice idea in many ways… but was introduced far, far too late. Windows does have EFI support btw, at least Vista and onwards, but I dunno if it’s generally available or you need a special version, and apparently it requires a bit of mucking about to install. But it’s there
Other OSes are going to implement their “V86 monitor” differently – but it’s probably a good bet that V86 monitor code hasn’t been touch for several years for the OSes that include it, so it might be interesting to snoop around
AMD can make EFI if they choose to, as they are members of the Unified EFI Forum.
Vista and Windows 7 support EFI, but only the x64 versions. Windows 7 may support EFI on 32-bit, but I’m not sure.
Nope. Not necessarily
http://en.wikipedia.org/wiki/Real_mode
Win 3.0 supported real mode. win 31 removed real mode support.
True, win3.x had real vs. “enhanced” mode – I should’ve specified that I meant win16 apps running under win32.
Edited 2010-01-21 09:40 UTC
Since the exploit is done via a 16-bit app, I fail to see how enabling the potentially-vulnerable feature when running a 16-bit app would somehow prevent it from being vulnerable… to quote the article:
that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks
If you’ve found a remote exploit that lets you attempt local privilege escalation, chances are you’ll be able to drop an executable… so, you drop a 16bit .com or .exe that handles the exploit – b00m.
The first thing I thought of was all those Windows fanboys who had declared Linux to be insecure because of that 8-year-old kernel vulnerability that could only be exploited if you have Wine or Dosbox installed. Our vulnerability was only present for half the time of this one 😛
For a long time, fully 32-bit programs were installed via 16-bit installers, if only to pop a window up in 16-bit Windows to tell you to upgrade.
Sure, but it has now been almost 15 years since Windows 95 came out. That’s a pretty damn long time to hold on to 16-bit applications.
Even if you do need them, just run them in DosBox or a virtualized DOS+Windows 3.x.
DosBox doesn’t run win16 installers… Drumhellar was referring to 32bit programs installed with 16bit installers, which has happened *a lot* (iirc one of the big sinners was InstallShield).
First time I was bitten by it was while I was still back on 32bit Windows, but had disabled “8dot3 filename creation” for my NTFS partitions. I’ve also been bitten by lack of 16-bit support a few times after switching to 64bit Windows – again, it’s been those pesky installer stubs.
Many DOS apps need direct access to bios in order to work. To have 100% compatibility with 16 bits DOS. It is necessary to have admin privileges.
It would be funny if nobody in MS knows about it. Either the developer left the company without telling them or the code are included without permission from the supervisor.
This bug was introduces in the early days of Windows NT. In that time, according to what I have read, the policy wasn’t as strict as it is nowadays. So, I can imagine, if the bug was introduced in that early stage, that noone would have known about it years later.
Exactly.
I don’t find it unlikely that NTVDM has sat pretty much untouched since NT4 – it’s not the kind of subsystem that’s going to need a lot of updates, since the stuff it supports is pretty much feature-frozen… and it’s not the first place you’d expect to be exploitable, since the CPU handles most of the encapsulation via V86 mode.
And the exploit is nontrivial, pretty interesting piece of code