MS Virtual PC Flaw Defeats Windows Defenses 141
Coop's Troops writes "An exploit writer at Core Security Technologies has discovered a serious vulnerability that exposes users of Microsoft's Virtual PC virtualization software to malicious hacker attacks. The vulnerability, which is unpatched, essentially allows an attacker to bypass several major security mitigations — DEP, SafeSEH and ASLR — to exploit the Windows operating system. As a result, some applications with bugs that are not exploitable when running in a not-virtualized operating system are rendered exploitable if running within a guest OS in Virtual PC."
Re:This gets me every time (Score:5, Interesting)
Simple. How many months will you give them before you go public?
At the possibility of being flamebait here, how the heck does MS keep publishing products full of security holes? I know Linux and Mac have had their share of holes, but it seems as if every week there's a new announcement about some MS product that has either a 0 day flaw, or another MAJOR flaw? And even worse is their failure to deal with them in a reasonable amount of time! I mean 6 months to COMMENT on an advisory? That's ridiculous... Sure, they may have a lot of notices to work through, but if that's the case, hire more developers to deal with the security issues! They are out spreading the message that you can depend on MS products, and then leave gaping holes open for months... Not to long ago (within the month), they delayed a patch --well, wanted to anyway before they were called out on it-- for a 0-day in IE by 3 weeks, so that they could put it in a "planned update to IE"... If this was a popular open source project trying to pull this stuff, how quickly would a fork surface? Then again, it's all about placating the sheeple, right?
Re:Are VMware, Parallels, and VB also vulnerable? (Score:4, Interesting)
It's probably just a bug in the way VirtualPC handles the virtual TLBs or some such. It's not even present on Hyper-V, also from Microsoft, so I think the danger here is pretty low.
It's not like this actually makes the host OS vulnerable, either. I doubt it can even crash the VM software, although it could certainly lead to crashing the virtualized OS.
Re:Are VMware, Parallels, and VB also vulnerable? (Score:3, Interesting)
That's what I'm wondering. Does randomized address still occur on VPC7's competitors? And if VPC is this way, then does Hyper-V thwart host address randomization, and so on? What's the difference in architecture that allows VPC to thwart this, and others go merrily on their way-- with whatever memory ring permitting the randomization of kernel access? Hmmmmm.
Re:This gets me every time (Score:3, Interesting)
then with windows vista why didn't MSFT include an XP mode, than ran in it's own self contained section while using the higher security of a modern OS?
MSFT is trying to maintain compatibly with single user OS's in a networked world and failing miserably. Apple simply included a backwards compatibility mode and with every release slowly stopped installing.
Re:How many people even use VirtualPC/XP mode anyw (Score:3, Interesting)
I mean, talk about small targets. I highly doubt that any hacker would find it worth his time to attempt to exploit this. I mean, first you have to find someone running XP mode. Then you have to get them to open an executable (or exploit some other vulnerability to get onto the system) on the guest OS instead of the host OS. Then the person still has to have more than 2 gigs of RAM and be utilizing more than 2 gigs at once. Then, after all that, you only have access to the XP VM, which may or may not have anything of worth on it.
I'm not surprised that MS shrugged it off for now.
Sorry, nice try, but you don't seem to understand the issue here. You don't need to "get them to open an executable" - the point is that this vulnerability makes it possible to exploit existing vulnerabilities by bypassing mitigation techniques such as SafeSEH, DEP, and ASLR. It also has nothing to do with the amount of physical RAM on the system or how much is being used - the mentions of memory accesses refer to a process's virtual address space.
I agree that this doesn't have nearly the same impact as if it affected Hyper-V or other business-critical virtualization platforms, but if you're going to downplay its significance, at least know what you're talking about. ;)
No kidding (Score:4, Interesting)
To the extent we use it at work, it is for running stubborn old software that won't run in Windows 7 and/or 64-bit OSes. To date, we've discovered two applications like that. We also set them up to run seamless in the host OS (their window appears along any other window) where you don't see or play with the guest VM. It's easier for the user, and less potential trouble. They generally don't even know (or care) that the program is running in a VM.
So yes, it requires some fairly edge situations to exploit. Not many people use XP mode in the first place (most apps run natively in 7), if they do, reasonable bet they are just using it for compatibility for one or two old apps, not on a regular basis. So you have to convince them to get your exploit, and run it in their XP system. While I suppose you could craft it so that it doesn't run in 7, they may just say "Eh, do not want," and ignore it. If not they might wonder why a new app would have that problem. Either way you've got to get them to use it in XP mode and then... Well I guess you can own their XP VM. Wonderful, that does you a whole lot of nothing in general.
Also this isn't a case of "Bypasses any and all security," it just gets by some additional protections that can help in some cases. DEP, for example, doesn't do anything to stop malware, it doesn't check the "evil bit" and stop programs from running. All it does is prevent buffer overflows in some cases. You can't execute code in the data area of a program's memory. Ok, fine, however to even matter at all you have to have a program that is vulnerable to that kind of thing. If programs are checking their inputs and so on, then DEP never even comes in to play.
Don't get me wrong, I'm happy that MS has added some additional protections to make common problems harder to exploit, however they are not the first, last, and only line of defense. They are just things that cause additional problems for various sorts of exploits. Something has to find a way to try and get in to the system in the first place before they even matter.
I can't see this as any kind of big deal. I'm certainly not at all concerned with regards to the computers that use it at work.
Re:Ugh, this isn't good. (Score:4, Interesting)
I actually had a chance to talk with one of the guys behind Wirtual PC (including the one that powers Virtual XP Mode) a few months back. His answer was that when MS started work on the Windows Virtual PC (WVPC, the current version) 3 years ago (roughly when VPC2k7 shipped), they contacted Intel and AMD and asked if they were going to offer hardware virtualization on all models going forward. Both companies answered Yes, so to save development and testing costs, the (large block of tricky) code that enabled vitrualization on CPUs without hardware support was cut from WVPC. Skip forward a couple years to WVPC getting ready for release, and... still a lot of Intel CPUs without support for virtualization. At that point it was too late to add the feature without delaying shipping, so they didn't.
I asked whether they would add it in later, and he said they weren't planning to but might change their mainds if it became clear that this was a problem for enough of their customers. In the meantime, they were telling Intel to get its shit together the way it had said it would three years earlier, and he personally recommended going with AMD chips.
On a side note, I didn't hear anything at all about it requiring x64. According to http://www.microsoft.com/windows/virtual-pc/download.aspx [microsoft.com], it works just fine on x86.