5 ms·

to demonstrate how to jump malicious code from the paltry ring 0 into the deepest, darkest realms of the processor. So you already have to be in ring 0. Pretty

by Moral_ 11y ago

to demonstrate how to jump malicious code from the paltry ring 0 into the deepest, darkest realms of the processor. So you already have to be in ring 0. Pretty click baity title.

dmix 11y ago
"Privilege Escalation" implies you start from an unprivileged state does it not? That sentence might just be poorly structured.
- geofft 11y ago
  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.
  - pgeorgi 11y ago
    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).
- weland 11y ago
  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.
zerohp 11y ago
VT-x allows guest operating systems to run in Ring 0. If this exploit works then a guest OS can exploit the hypervisor.
- Moral_ 11y ago
  Good call didn't tihnk about VT-x
- tptacek 11y ago
  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.
thomnottom 11y ago
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.
- zobzu 11y ago
  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 :)
  - prof_hobart 11y ago
    I read it as meaning "escalating to give you universal privilege".
  - fit2rule 11y ago
    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 ..
    - zobzu 11y ago
      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
exDM69 11y ago
> 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.
- edmccard 11y ago
  >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?
  - exDM69 11y ago
    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.
frik 11y ago
Intel CPUs support Ring0-3. But... http://en.wikipedia.org/wiki/Protection_ring 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."
- j-pb 11y ago
  Actually we should abandon the ring concept all together for more promising security models. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - frik 11y ago
    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_based_os_what_do_you_think/ 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 https://news.ycombinator.com/item?id=7605687 Nevertheless an interesting topic, that doesn't deserve a downvote of my parent.
- hga 11y ago
  For better or worse, AMD dropped rings in x86-64.
  - deleted 11y ago
    [deleted]

by Moral_ 11y ago

to demonstrate how to jump malicious code from the paltry ring 0 into the deepest, darkest realms of the processor. So you already have to be in ring 0. Pretty click baity title.

dmix 11y ago

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

geofft 11y ago
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.
- pgeorgi 11y ago
  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).
weland 11y ago
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.

zerohp 11y ago

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

Moral_ 11y ago
Good call didn't tihnk about VT-x
tptacek 11y ago
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.

thomnottom 11y ago

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.

zobzu 11y ago
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 :)
- prof_hobart 11y ago
  I read it as meaning "escalating to give you universal privilege".
- fit2rule 11y ago
  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 ..
  - zobzu 11y ago
    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

exDM69 11y ago

> 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.

edmccard 11y ago
>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?
- exDM69 11y ago
  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.

frik 11y ago

Intel CPUs support Ring0-3. But... http://en.wikipedia.org/wiki/Protection_ring 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."

j-pb 11y ago
Actually we should abandon the ring concept all together for more promising security models. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- frik 11y ago
  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_based_os_what_do_you_think/ 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 https://news.ycombinator.com/item?id=7605687 Nevertheless an interesting topic, that doesn't deserve a downvote of my parent.
hga 11y ago
For better or worse, AMD dropped rings in x86-64.
- deleted 11y ago
  [deleted]