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).
Thread beginning with comment 405220
To view parent comment, click here.
To read all comments associated with this story, please click here.
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 Parent 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 Parent 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 Parent 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 Parent 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 Parent Score: 1