Linked by Thom Holwerda on Wed 20th Jan 2010 22:45 UTC, submitted by kragil
Windows 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).
Order by: Score:
kragil
Member since:
2006-01-04

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.

Reply Score: 3

kaiwai Member since:
2005-07-06

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:

The problem is caused by flaws in the Virtual DOS Machine (VDM) introduced in 1993 to support 16-bit applications (real mode applications for 8086). VDM is based on the Virtual 8086 Mode (VM86) in 80386 processors and, among other things, intercepts hardware routines such as BIOS calls. Google security team member Tavis Ormandy has found several vulnerabilities in this implementation that allow an unprivileged 16-bit program to manipulate the kernel stack of each process via a number of tricks. This potentially enables attackers to execute code at system privilege level.


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.

Reply Score: 2

f0dder Member since:
2009-08-05

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

Reply Score: 3

hurdboy Member since:
2005-09-02

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

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.

Reply Score: 1

f0dder Member since:
2009-08-05

AFAIK, it's a hardware issue. AMD dropped 16-bit PM operation in 64-bit mode.
Yep - that's another way to say "long mode doesn't support V86 tasks" ;)

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

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

But AMD probably doesn't have a license for EFI, and even if they had held one, Windows didn't support it. ;)
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 ;)

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

Reply Score: 2

Drumhellar Member since:
2005-07-12

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.

Reply Score: 2

Bill Shooter of Bul Member since:
2006-07-14

(16bit Windows apps do run protected mode rather than DOS/realmode,


Nope. Not necessarily

http://en.wikipedia.org/wiki/Real_mode

Win 3.0 supported real mode. win 31 removed real mode support.

Reply Score: 2

f0dder Member since:
2009-08-05

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

Reply Score: 1

Uh, no...
by umccullough on Wed 20th Jan 2010 23:40 UTC
umccullough
Member since:
2006-01-26

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?


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

Reply Score: 3

RE: Uh, no...
by f0dder on Thu 21st Jan 2010 01:32 UTC in reply to "Uh, no..."
f0dder Member since:
2009-08-05

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.

Reply Score: 1

Haha
by 3rdalbum on Thu 21st Jan 2010 03:29 UTC
3rdalbum
Member since:
2008-05-26

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

Reply Score: 3

Lots still use 16-bit apps
by Drumhellar on Thu 21st Jan 2010 04:18 UTC
Drumhellar
Member since:
2005-07-12

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?


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.

Reply Score: 2

RE: Lots still use 16-bit apps
by Soulbender on Thu 21st Jan 2010 13:14 UTC in reply to "Lots still use 16-bit apps"
Soulbender Member since:
2005-08-18

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.

Reply Score: 2

RE[2]: Lots still use 16-bit apps
by f0dder on Fri 22nd Jan 2010 18:08 UTC in reply to "RE: Lots still use 16-bit apps"
f0dder Member since:
2009-08-05

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.

Reply Score: 1

funny_irony
Member since:
2007-03-07

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.

Reply Score: 1

Andre Member since:
2005-07-06

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.

Reply Score: 1

f0dder Member since:
2009-08-05

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

Reply Score: 1