Microsoft are under the pump fighting vulnerabilities at the moment. Just six-and-half hours after blogging that the Operation Aurora Internet Explorer fix would be ready the next day, they blogged about a publicly-announced Windows kernel vulnerability.
Microsoft’s 979682 advisory about the vulnerability is sadly devoid of any useful (or even interesting) technical details at the moment. You are referred to CVE-2010-0232, but that’s still a holding page. The vulnerability number was reserved two weeks ago, but no documentation has been published there yet.
The elevator pitch (Brit: lift summary) is that NTVDM, the 16-bit DOS subsystem in 32-bit Windows, can be abused to trick the kernel into trusting userland memory addresses that it shouldn’t. That almost always means an escalation of privilege exploit is close to hand.
The bad news is that a handily-commented C source code of a proof-of-concept exploit is available. The discoverer of the exploit claims that Microsoft didn’t fix it when he reported it in June last year. So he decided to go public, presumably to push things along, a tactic which seems to have worked.
The good news is that an effective and centrally-deployable workaround is available. Simply turn off the 16-bit DOS subsystem. You won’t be able to run your old 16-bit DOS applications, of course. But then you gave those up years ago, right? As you gave up making all your users Local Admins. So 1999.
I’m not usually a fan of full disclosure, especially where a working but unpatched exploit is published for all to use and abuse. In this case, I don’t mind.
Kernels aren’t supposed to have bugs. When security assumptions in kernels turn out to be broken, either the bug should be fixed promptly or the faulty code be removed entirely.
In this case, fondly though I remember DOS, I recommend the latter approach. Forget about the patch for the moment, though it will come and you should apply it. Say “G’day” to the Twenty-first Century and say “Exit” to the Virtual DOS Machine.
DOS applications have never cohabited well with Windows NT and NTFS – there are too many impedance mismatches between the OSes in file and directory handling alone for their coexistence ever to be satisfactory for more than a brief transitional period.
To be fair to Microsoft, the 16-bit DOS subsystem was ejected from 64-bit Windows, apparently without any tears or regret. I have no doubt they’d love to eject it from 32-bit Windows as well, but I bet that organisations with legacy applications have leaned heavily on Microsoft not to do so.
Sometimes, the change control guys need a stick to make them let go of the past.
Perhaps this is an ideal stick for Microsoft – if their “patch” to this vulnerability were to get rid of NTVDM altogether instead of fixing the bug, would you mind? Or do you expect Microsoft to keep maintaining the worn-out VDM almost as if it were a tradition?