Scientists Propose Guaranteed Hypervisor Security
schliz writes "NCSU researchers are attempting to address today's 'blind trust' of virtualization with new security techniques that 'guarantee' malware does not infect hypervisors. Their HyperSafe software uses the write-protect bit on hypervisor hardware, as well as a technique called restricted pointer indexing, which characterizes the normal behavior of the system and prevents any deviation. A proof-of-concept prototype has been tested on BitVisor and Xen, in research that will be presented (PDF) at an IEEE conference today."
It's very dangerous to say "guaranteed" when it comes to security. It's very rarely true.
Link to a pdf version of the paper? Given recent security problems with that format, does anyone else find it funny?
I wish that I had Hypersafe installed so I could open Acrobat on a virtual machine instead.
If it really guarantees no infection with malware, then it cannot be update-able or extendible. All it is suggesting is that the hypervisor cannot be altered from within a client operating system. I don't think that this gives you anything that you don't already get with a user-mode virtualisation like virtual box, where the host's system will write-protect pages.
Because if anybody could get a machine infected it'd be him.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
The more you tighten your grip, the more will slip through your fingers.
I want to delete my account but Slashdot doesn't allow it.
From what I understand, this is only during runtime, what about attacks which occur during boot-up?
What about securing a VM from the host? so you can run secure corporate VM images on an untrusted host. now that would interest me...
Dave
What about the evil bit?
Fill your server full of concrete and chuck it into an active volcano.
Otherwise, there's just varying degrees of risk.
Regards;
While this sounds like a step in the right direction, any claims of "unhackability", are frankly lies and both unethical and unprofessional in the extreme. Most currently used attacks were never expected and quite a few were regarded as impossible before somebody went ahead and demonstrated them.
On a related note, those technologies advertised as "unhackable", "absolutely secure", "provably secure", etc. consistently fail to deliver. In fact, these claims are usually an indicator of low quality, because they show the people proposing them do not really understand IT security.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Okay so One can protect the hypervisor execution. How do we protect the OS and the software the hypervisor's software storage?
There has to be a way to update the hypervisor, and presumably that update comes over the web. You can guarantee the that code will execute in a protected space but can you guarantee you are executing the right code or that the code itself does not have a security hole.
The there is the OS. Presumably this can still be infected. Also presumably some attacks will run in a layer between the hypervisor and OS. That is they will create a virtual hypervisor of a malicious type.
Still it's a great advance. I expect the military and banking industry will be the early adopters.
And an even bigger assumption :
How does the über-secure hypervisor it-self know that it is running on the real hardware ? And is not simply stacked upon another layer of abstraction in the control of the malware ?
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Why is it no one told these guys that adding more features never adds more security?
Lets go over the x86 history.
Start multitasking, need some sort of memory protection in HARDWARE cause software can't do it.
Realize that software implementations working with the hardware are buggy ... Damn.
Add other protections such as NX ... realize software implementations are buggy ... Damn.
Virtualize the OS into its own little space under a hypervisor, realize its slow and implementations are buggy ... Damn.
Add a hypervisor with hardware virtualization support directly on the chip ... realize that its no longer as slow, but software implementations still are buggy and result in ways to exploit ... Damn.
Now we're at ... add NEW flags for the hypervisor to make it 'secure'.
Do I need to explain what happens next?
They idea that a hypervisor is more secure at all is one of the most ignorant things a hardware or software developer can have. If the OS can't be made secure, neither can the hypervisor. You can argue that its less code so its got fewer bugs but that number is still greater than 0.
I'm going to repeat. If you can't make the OS secure and capable of protecting itself, adding another layer on top isn't going to help you.
Whats better is their 'proof' was written as 'synthetic hypervisor exploits' ... so they made some shit up and it didn't work? Guess what, my Arduino's can't run x86 code, but that doesn't make them secure, it just means I didn't use the right exploit.
When will people learn from history?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Wikipedia is wrong.
Citation needed. I'd like to read a review of a newer version of Mac OS X that mentions Preview's newly added support for PDF forms so that I can go make Wikipedia no longer wrong.
so the first technique just requires getting your code set up so it will be in the hypervisor upon reboot, then force a reboot. And the second one can probably be bypassed by a bug in the hypervisor code, or your own code injected by bypassing the first technique.
Now if you required someone to have physical access to the machine to update the hypervisor and you could somehow guarantee that there isn't any exploitable bugs in the hypervisor, then that might be something towards keeping external users from remotely compromising a hypervisor, but this looks to just be some checks to say that your hypervisor has some security.
Provable security... Forgive me for laughing out loud. Everytime this is asserted a few months go by and ... surprise ... an expliot. The one posture that is exceptionally unhealthy in the security industry is drum beating to the sound of ones own arrogance.
Does this hypervisor protect the host from CPU glitching?
If someone thinks that adding software is going to do much for security in the long run, then go no further than contemplating what happens when your BIOS, chipset, NIC, GPU, or microcode get re-flashed by an adversary running ring0. If the hypervisor is deemed to be ring(-1) then bios should be considered ring(-2). Game over, but then the machine hasn't even started yet. If you are not even in control of your own hardware (e.g DMA, boot strap load vector) then what does your hypervisor really do for security? Yes its better than not having it of course, because it will prevent something like HyperDBG from inserting itself during run time. He who loads first wins, and usually the firmware devices will boot up faster than the main OS will. Timing counts, and they can just sit in memory waiting their own turn. So should we really be using the 'guarantee' word? Likely not, as long as we have human ingenuity we won't have absolute 'garenteed' security.
If they REALLY make a true firewall around the hypervisor then performance will be terrible.
If you want decent network or display performance on a vm then you have to use special drivers for the virtual devices that bypass the firewall.
We have already seen security flaws in these special drivers.