New security flaw found in NT-VDM affects all versions of NT

[Guest wsxedcrfv]

Apparently, Google told Microsoft about this more than 6 months ago, but decided to go public because Microsoft seemed to be sitting on their hands on this one.

http://www.theinquirer.net/inquirer/news/1...nt-windows-flaw

---------

According to Full Disclosure, the security hole in Windows allows users with restricted access to escalate their privileges to system level.

It can be done on all 32-bit versions of Windows from Windows NT 3.1 to Windows 7. This is not likely to bother consumers much, but corporate IT managers will be wetting themselves.

The problem is caused by flaws in the Virtual DOS Machine (VDM) that was fitted under the bonnet of Windows NT in 1993 to support 16-bit applications. The 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 worked out how an unprivileged 16-bit program can manipulate the kernel stack of each process and this can enable an attacker to execute code at the system privilege level.

--------

If I'm not mistaken, win-9x/me also implements a form of VDM for 16 bit apps - no?

[cluberti]

I'm not sure I'd laugh at NT when running an OS with a flat memory model, but yeah, it's a pretty annoying privilege escalation vulnerability. It wouldn't be a remote code execution vuln, and would require local access to the machine, but it's still not good to have a hole.

[rloew]

There isn't enough information in the linked article for me to determine if the vulnerability mentioned in the article is the one that I found.

I use the Trap Handler as one of three methods for gaining Ring 0 access from a 16-Bit Application such as my Non-EMS RAMDisks.

[cluberti]

It basically allows the NTVDM to run as the LOCALSYSTEM user, it has nothing to do with the CPU execution ring. It's a user privilege level escalation from a user (still lacking some power, even as admin) to the SYSTEM account, which can do literally anything, anywhere.

[dencorso]

Did you refer to the Full Disclosure article, RLoew? Did you actually look at the example code mentioned?

[jaclaz]

I am failing to see how this vulnerability can make an OS that substantially allows anyone Admin or System privileges from the start to laugh at the NT family.

I would understand if some of the good Linux guys would take advantage of it for some mocking, but on access privileges, the otherwise good 9x guys have nothing to put on the other plate of the scale.

Also remember that the NT people can always take from their sleeves the "Me" argument card, a win all wildcard!

It's a nuisance, and a rather severe one, but on really "protected machines", any savvy Corporate IT would have disabled the 16 bit sub-system anyway.

jaclaz

[MrJinje]

but corporate IT managers will be wetting themselves.

Yawns pejoratively: Wet myself, not a chance. Like Cluberti says, this will take some form of social engineering, email, or visiting a bad website to be affected. Not to mention that there are plenty of rootkits available that any script kiddie can deploy without additional coding. This is still in the proof of concept stage, wake me when some hacker includes it in Conficker F.

any savvy Corporate IT would have disabled the 16 bit sub-system anyway.

You would think so, but it's not true, I can personally attest that at least three Fortune 500 companies are still heavily invested in 16 bit apps and use them daily for mission critical operations. These are mostly software from now defunct companies, or internally built, but some of the older stuff is just in use because it isn't worth the downtime that can occur when employee's are forced to learn a new system. The WFA systems used by the telecoms since the 80's are a perfect example of this, also any mainframe apps that requires a PCOMM/3270 emulator. Edited January 21, 2010 by MrJinje

[jaclaz]

These are mostly software from now defunct companies, or internally built, but some of the older stuff is just in use because it isn't worth the downtime that can occur when employee's are forced to learn a new system. The WFA systems used by the telecoms since the 80's are a perfect example of this, also any mainframe apps that requires a PCOMM/3270 emulator.

Good point.

Nonetheless it seems to me as well an unlikely to be put in practice kind of attack, it seems like an attacker needs local access (rather than remote) and in these cases, all you need, besides some knowledge, is a boot CD or a USB stick, proportionally I have often seen many more "loose" BIOS/access restrictions to the physical machine than Network protection.

Also, if the hard disk is not encrypted, an user with local access could always access it physically and be done with it (besides the fact that on most workstations, if you look hard enough you can find in first drawer or under the keyboard the login/password.....

jaclaz

[MagicAndre1981]

I've disabled the VDM system for years now:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat

VDMDisallowed (DWORD) = 1

and I'm now only using DOSDox.

This works fine and also brings "DOS" back to x64 Windows Version. Btw, the x64 Windows Versions are save, because they can't run 16Bit code any longer.

[cluberti]

Correct - you can't switch an x86-64 processor running in Long mode (the native 64bit mode) into Legacy mode (where protected mode 16bit apps in DOS or Windows must run) - it's not possible, it's a hardware limitation (and a good one, at that, I'd wager).

[rloew]

Did you refer to the Full Disclosure article, RLoew? Did you actually look at the example code mentioned?

I missed the link to Full Disclosure. So many website use in-line links like this one for either useless information or advertising that I ignored it.

My method is basically the same in principle, but I get into Ring 0 from which I can do anything I want including what they did.

Despite the multiple pages documenting the IRET Instruction, creating a Stack Frame to return to User Mode is pretty straightforward.

[dencorso]

You have the precedence in the discovery, for sure. The oldest archived version of the RAMDSK3S I have in archive is dated 07/14/2008, and that was already the 1st beta!!! Wow!

And, yes, as you know, I remain using precisely that method (from the three you offer) in my day-to-day usage of your current Non-XMS RAMDSK32: it's reliable, and windows never notices it's there!

[rloew]

You have the precedence in the discovery, for sure. The oldest archived version of the RAMDSK3S I have in archive is dated 07/14/2008, and that was already the 1st beta!!! Wow!

And, yes, as you know, I remain using precisely that method (from the three you offer) in my day-to-day usage of your current Non-XMS RAMDSK32: it's reliable, and windows never notices it's there!

Sorry, wrong one. The old RAMDSK3S and the method you are using is the SYSENTER Method.

The Trap Handler method is described as the INT30 Method in my Documentation and is enabled by the "/I" option in HIMEMEX. The old RAMDSK30 used it.

It was the second method I developed. SYSENTER was the third. So it is actually older than the SYSENTER Method.

It is the only method of the three that stands alone, not needing setup in DOS or a support VXD.

The oldest file I could find was a test Program dated 07/06/08. The RAMDisk came two days later.

[dencorso]

You're right, of course. I mixed things up somehow while I searched my archived files looking for the oldest versions of your programs. I stand corrected. The Int30 method worked right away, and I used it until you found and fixed the last bug in the SYSENTER method (in 05/10/08), and then I switched over to the SYSENTER method, and remain using it to this day.