VT-x allows guest operating systems to run in Ring 0. If this exploit works then a guest OS can exploit the hypervisor.

Maybe. VT hypervisors still mediate stuff done in VM kernels. The attack could still work on native OS kernels and still not be effective on VMs.

Good call didn't tihnk about VT-x

"Privilege Escalation" implies you start from an unprivileged state does it not? That sentence might just be poorly structured.

It means you go from some level of privilege (which could be none at all) to more privilege. For instance, "a WordPress author can get a shell on the server" would be a privilege escalation, even though being able to write blog posts is quite privileged on its own.

That said, I'm not particularly convinced that (unvirtualized) ring 0 to SMM is really a violation of a security policy... it's not like SMM really tries to confine what ring 0 can do, it just wants things like interrupt priority.

Since SMM allows for all kinds of things that ring 0 can't do (one example: writing to flash even if write protections are enabled, unless a second set of write protections, added in later chip generations, is _also_ enabled), arbitrary code execution in SMM is a bad thing.

Also later ring 0 code can't get rid of code installed into SMM earlier (that may still trigger through events or timers).

If you go from having your own ring 0 (as a guest in a hypervisor) to messing around with everyone's ring 0, it's very much a privilege escalation.

Not intended as click bait. I saw it on twitter and was wondering just how serious a flaw people thought this could be. Or if the presenter might just be blowing smoke.

well it still says "universal" but in fact, its universal if you are root/can insmod/etc.

it reminds me of the unlimited data plans that are limited after 5Gb.

Not sure what happened to language :)

From a security perspective, this:

"universal if you are root/can insmod/etc."

.. only needs to be true once, and from that point on the hardware no longer belongs to the owner.

So, if you could for example get your secretNSA$hit installed on the Linux box that is used to test hardware at the PC assembly/manufacturing plant, before its sent off to be 'securely configured' by the sysadmin/ops as supposedly fresh equipment.

Lots of ways that can happen, of course its theatrical to consider it, but little in security these days is without drama it seems.

Truly, not being able to trust the microcode in my CPU is a worry, but it always has been. There are no guarantees that there aren't already CPU embeds that are configured to ship data to some quantum-bearing government spy satellite, and thus we're all fools for thinking we have any kind of security on this theatrical stage at all ..

even the non-microcode part you are forced to trust but then again so goes for the rest of the hardware, not just the cpu

I read it as meaning "escalating to give you universal privilege".

Intel CPUs support Ring0-3. But...

http://en.wikipedia.org/wiki/Protection_ring

Multics supported 8+ rings, OpenVMS 3 rings, OS/2 3 rings, Windows NT and Unix only 2 rings. Some hypervisor like XEN use afaik ring 1 (Intel VT-x "Vanderpool").

We need better ring support in modern operating systems and hypervisors (VM hosts).

"The x86-processors have four different modes divided into four different rings. Programs that run in Ring 0 can do anything with the system, and code that runs in Ring 3 should be able to fail at any time without impact to the rest of the computer system. Ring 1 and Ring 2 are rarely used, but could be configured with different levels of access."

Actually we should abandon the ring concept all together for more promising security models.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

The suggested solution is to have process isolation implemented using software - namely asm.js-enabled JavaScript virtual machines embedded in a Linux kernel, which save you from needing hardware isolation, reducing overhead. Gary calls this idea "METAL".

I found little resource about the project, but there is a discussion on Reddit: http://www.reddit.com/r/compsci/comments/25w7vt/javascript_b...

And we had the discussion on HN too: https://news.ycombinator.com/item?id=7605687

Nevertheless an interesting topic, that doesn't deserve a downvote of my parent.

Actually hypervisors (VT-x) run in Ring -1: http://en.wikipedia.org/wiki/Protection_ring#Hypervisor_mode

That's actually not really how it works[0].

It's more that a ring 0 can manipulate an alternate context, but only for contexts that it can create. So guests can themselves be hypervisors for contexts that they themselves create. There's nothing stopping a guest from executing virtualization instructions[1].

That being said there is a sort of ring -1 called SMM mode.

[0] And this is why you shouldn't rely on wiki. Particularly since it looks like the deletionists are winning their war. It's source is informationweek in this case...

[1] Well, that's not totally true. When setting up the context for a guest you can signal that you as the hypervisor want to get trapped on lots of different types of privileged operations. ie. you can optionally, explicitly disallow the guest to use virtualization extensions. But it's opt in, not policy set by AMD/Intel.

For better or worse, AMD dropped rings in x86-64.

> So you already have to be in ring 0.

Yes, but the article implies that you can e.g. do bad things in a bootloader and then have the OS run while the exploit stays resident and undetected by the OS.

This definitely has previously undocumented exploit potential if you can force the target to e.g. boot from a malicious USB device.

>if you can force the target to e.g. boot from a malicious USB device.

If you can control the boot media, aren't you already past the point where you need further exploits to control the machine?

Yes - but that's a bit besides the point. The situation is a lot worse if you can remain undetected after tampering with the boot media or firmware. This can be a lot more damaging than a ring-0 exploit.