Slashdot Mirror
MS Virtual PC Flaw Defeats Windows Defenses
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."
Arce said Core reported the flaw to Microsoft last August... Microsoft officials declined to comment until they had a chance to review Core’s advisory on the issue
So how many months do you need to review once you are told about it???
Every time I read an article like this, it gives me a smug face wondering why more people don't switch.
Swtch to what, VMware or Parallels?
Oops.
The good news is that this doesn't affect the big iron (Hyper-V). However, for people who have Windows 7 and XP mode, using it for Web browsing, this will cause them a world of hurt.
Since this essentially doesn't affect servers, I'm going to recommend to people that they move to VMWare Workstation if they want commercial support, or VirtualBox if they desire an open source solution. Either one of these has as many features as VirtualPC (although VirtualPC has one nice advantage -- it drops changes to the undo disk fast compared to the 2-3 minutes VMWare does.)
A hole in a hypervisor is a really bad thing. A lot of people use VMs for honeypots, and this would cause unintended infections, or other damage, perhaps catastrophic.
Answer: Because their apps run on windows. That's all there is to it.
Copyright 2010. All rights reserved. This comment may not be copied in any way including, but not limited to caching.
So Virtual PC is virtually as secure (or insecure) as a real PC? If you wanted the security of a real PC then they should have, um, well ... never mind.
This is definitley a bug, but all it does is allow bypassing of security features in the virtualized system. In other words, you can exploit the VM client, but you still can't get at the host.
It's worth of a patch, but not of a panic. If you're virtualizing for security, you don't really care what happens to the virtual system (that's the point). If you're virtualizing so you can run an old OS, it's going to be full of holes anyhow. If you're virtualizing for any other reason, why the hell are you using consumer-grade virtualization software?
There's no place I could be, since I've found Serenity...
Virtualbox.
I've got better things to do tonight than die.
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.
There's no place I could be, since I've found Serenity...
I would like to add that the exploit writer at Core Security Technologies that discovered this vulnerability is Nicolás Economou and congratulate him on the great work he has made.
Disclaimer: I also work at Core
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.
---- Teach Peace. It's Cheaper Than War.
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.
Don't take life so seriously. No one makes it out alive.
Not all of us can afford Macs.
You are welcome on my lawn.
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. ;)
When we face a choice between adding features and resolving security issues, we need to choose security.
- Bill Gates, January 16, 2002 .
Help stamp out iliturcy.
It's a matter of priorities. Do I want to a) fight Windows security and have the apps I want, b) ignore security and have the apps I want, or c) have security, but have to learn some other app, or maybe do without that app.
The whole point of having a computer is to run the programs you want to run. If you're going to have to "do without", you might as well unplug the damn thing (thereby achieving perfect security).
Visual IRC: Fast. Powerful. Free.
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.
This is really a vulnerability in any meaningful sense of the word. Rather, this means that certain advanced protections that Windows uses are less effective in a Virtual PC. Microsoft is actually in a leading postion when it comes to memory protection features as compared to anyone this side of OpenBSD.
What isn't someone issuing an "advisory" that the MacOS implementation of things like GS, ALSR, early-heap-termination and SafeSEH are either weak or nonexistent?
ASLR could use more entropy. Stack coookies could be present in every function, instead of just some. Every defense can be improved, and I don't think Microsoft has ever claimed that ASLR or GS is a reason NOT to produce a patch.
IMHO, Microsoft is completely correct to not issue a bulletin for this since that is an indication of a severe issue. And Core is free to make the issue known publically as well, and people can decide for themselves. But the Slashdot title is midleading at best.
RTFA and re-read what I said:
Article: "It causes memory pages mapped above the 2GB level to be accessed with read or read/write privileges by user-space programs running in a Guest operating system."
Me: "Then you have to get them to open an executable (or exploit some other vulnerability to get onto the system)"
Don't take life so seriously. No one makes it out alive.
Aren't those called "exploits"?
No, you're misunderstanding the article. A "security mitigation" is something that stops exploits working without actually removing the hole that allows the exploit. Stuff like checking your stack is still intact before returning from a function in order to make stack overflow exploits fail: the stack can still be overflowed, but you can't (easily) exploit this any more.