5 ms·

The DrK Attack: De-randomizing Kernel ASLR

159 points by tsgates 10y ago

Cyph0n 10y ago
I attended a talk on DrK by Yeongjin a few weeks back at Georgia Tech. Keep up the awesome work guys, and welcome to the front page of HN ;)
cheiVia0 10y ago
Scary :(
shamsalmon 10y ago
I would have loved for this kind of research to be my job. Should have done better in my classes :(
- andrewstuart2 10y ago
  It's never too late to set a goal. If you're looking for more knowledge, this [1] is a great place to start, as well as just watching interesting DefCon talks on YouTube. :-) [1] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-858-computer-systems-security-fall-2014/video-lectures/ https://ocw.mit.edu/courses/electrical-engineering-and-compu...
JoshTriplett 10y ago
Providing user control over page faults and using that for a security exploit reminds me of the classic UNIX tale of password checking. A version of UNIX had a privileged mechanism that would check a password (provided by pointer); it did so character-by-character. It also had a way for userspace processes to handle page faults themselves. So, put a password buffer across two pages, with the page boundary after the first character, and change the first character until you get a page fault. Repeat for each character of the password...
- Aissen 10y ago
  It's nice because it allows a slow and controlled timing attack, but you don't need a page fault to do that, you can simply measure elapsed time with high resolution timers, perf or whatever you have on hand :-)
  - JoshTriplett 10y ago
    True, a privileged process having data-dependent execution time for secure data can lead to a variety of side-channel attacks. For more complex cases than password validation, it would help if it were easier to write side-channel-resistant algorithms in something other than assembly. Even a C compiler, let alone something higher-level, can introduce side-channel leaks through optimization.
- Animats 10y ago
  That wasn't UNIX. It was TOPS-20 on the DEC 36-bit machines.
- shenberg 10y ago
  The system mentioned is TENEX (not *nix) according to http://research.microsoft.com/en-us/um/people/blampson/33-Hints/WebPage.html http://research.microsoft.com/en-us/um/people/blampson/33-Hi... (a great paper from '83 that was posted here recently. search for password to find the exact reference there)
  - JoshTriplett 10y ago
    Thanks for the correction. The version of the story I saw came from a systems programming book, which attributed it vaguely to some past UNIX system of yore. Glad to have a more accurate reference.
josteink 10y ago
To me it seems like every time intel tries to create a security safeguard, it almost always without exception ends up being a new attack-vector instead (see "x86 considered harmful"). I'd love to run simpler versions of the modern intel cpus stripped of all this insecure bloat. Surely I can't be the only one?
- willvarfar 10y ago
  (Mill CPU team) I'm putting together a security white paper at the moment. We've been quiet because we've been real busy and we have more new stuff to talk about if only we had time to write it up for public, so watch this space :)
- djsumdog 10y ago
  We can't even get newer x86/64 boards without closed binary blobs everywhere. Look at Librem. I think the last truly open laptop in the x86 world was the X200 Thinkpad. All the newer opensource laptops are all ARM based, which is just going to mean a lot of fragmentation until things like the ARM config/device-tree stuff catches up to EFI.
- nickpsecurity 10y ago
  There's potentially room for a cloud or datacenter company to pull it off by paying Intel to do it via semi-custom business they have. Or AMD who started that model in x86. Just the high-performance HW and microcode without any other crap with other stuff in trust boundary offloaded to coprocessors we can build and verify. We can also add in some real security like in Watchdog or CHERI CPU's while we're at it. CHERI already runs FreeBSD so we'd have that immediately if we ported their toolchain to x86.
- 0xfeba 10y ago
  https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation https://www.crowdsupply.com/raptor-computing-systems/talos-s... There are few "open" hardware/firmware efforts going on now.
- anonymousDan 10y ago
  What has tsx got to do with security? It's for efficient transactional memory.
willvarfar 10y ago
(This popped up on proggit the other day, but got deleted for some reason: https://www.reddit.com/r/programming/comments/58fpi6/aslr_protection_on_intel_haswell_takes_only_60ms/ https://www.reddit.com/r/programming/comments/58fpi6/aslr_pr... )
dooglius 10y ago
For a system as complex and intricate as a modern processor, it seems impossible to avoid a userspace application from figuring out at least some basic information about the kernel's state. It would be better to focus on avoiding actual privilege escalations.
ryuuchin 10y ago
So yet another KASLR bypass. Reminds me of[1]: > Consider this our "I told you so" that we hope you'll remember in the coming years as KASLR is "broken" time and again. Then again, in this offensive-driven industry, that's where the money is, isn't it? [1] https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=ee9f8c1bacede4863bcab77b96eff623 https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=e...
- Animats 10y ago
  That article is correct. Address-space randomization wasn't a fix. It was a way to avoid fixing problems, by claiming that the ability for attacks to execute hostile code in some other process's space wasn't a problem. The problem is giant kernels that change constantly. It doesn't have to be that way. Look at L4 and QNX. With sufficient code bloat, all bugs are deep.
  - nickpsecurity 10y ago
    "With sufficient code bloat, all bugs are deep." That's an interesting statement. Might have to think on it. While we're on secure kernels, did you ever have any experience with the ASOS system or hear about it from someone who did? It was the only Ada OS aim for A1 class that actually got delivered far as I can tell from papers. Then info disappears into a black hole. Be interesting to find out how well it worked or didn't as putting a modern version of that in a container or on top of seL4 might be worth trying. Note: MaRTE OS is an Ada-based, open-source RTOS still in development and use. Not security-focused, though. Muen is just a separation kernel. A secure one could draw on them a bit.
    - Animats 10y ago
      Not ASOS, no. I worked on KSOS-11, an attempt to cram a secure OS written in Modula into a PDP-11. It ran, but the 64K address space was too much of a limitation. As for "with sufficient code bloat, all bugs are deep," that's my answer to Torvalds' "given enough eyeballs, all bugs are shallow". Time has proven him wrong - the number of bugs in the Linux kernel continues to increase as the kernel becomes more bloated. 16 million lines of code and still growing![1] This is why microkernels are the way to go. Good microkernels run about 10,000 lines of code. It's possible with 10,000 lines of code to have a steadily decreasing number of bugs. We now have a situation where neither Linux nor Windows is securable. We're paying the price for that. [1] https://www.linuxcounter.net/statistics/kernel https://www.linuxcounter.net/statistics/kernel

159 points by tsgates 10y ago

I attended a talk on DrK by Yeongjin a few weeks back at Georgia Tech. Keep up the awesome work guys, and welcome to the front page of HN ;)

cheiVia0 10y ago

Scary :(

shamsalmon 10y ago

I would have loved for this kind of research to be my job. Should have done better in my classes :(

andrewstuart2 10y ago
It's never too late to set a goal. If you're looking for more knowledge, this [1] is a great place to start, as well as just watching interesting DefCon talks on YouTube. :-) [1] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-858-computer-systems-security-fall-2014/video-lectures/ https://ocw.mit.edu/courses/electrical-engineering-and-compu...

JoshTriplett 10y ago

Providing user control over page faults and using that for a security exploit reminds me of the classic UNIX tale of password checking. A version of UNIX had a privileged mechanism that would check a password (provided by pointer); it did so character-by-character. It also had a way for userspace processes to handle page faults themselves. So, put a password buffer across two pages, with the page boundary after the first character, and change the first character until you get a page fault. Repeat for each character of the password...

Aissen 10y ago
It's nice because it allows a slow and controlled timing attack, but you don't need a page fault to do that, you can simply measure elapsed time with high resolution timers, perf or whatever you have on hand :-)
- JoshTriplett 10y ago
  True, a privileged process having data-dependent execution time for secure data can lead to a variety of side-channel attacks. For more complex cases than password validation, it would help if it were easier to write side-channel-resistant algorithms in something other than assembly. Even a C compiler, let alone something higher-level, can introduce side-channel leaks through optimization.
Animats 10y ago
That wasn't UNIX. It was TOPS-20 on the DEC 36-bit machines.
shenberg 10y ago
The system mentioned is TENEX (not *nix) according to http://research.microsoft.com/en-us/um/people/blampson/33-Hints/WebPage.html http://research.microsoft.com/en-us/um/people/blampson/33-Hi... (a great paper from '83 that was posted here recently. search for password to find the exact reference there)
- JoshTriplett 10y ago
  Thanks for the correction. The version of the story I saw came from a systems programming book, which attributed it vaguely to some past UNIX system of yore. Glad to have a more accurate reference.

josteink 10y ago

To me it seems like every time intel tries to create a security safeguard, it almost always without exception ends up being a new attack-vector instead (see "x86 considered harmful"). I'd love to run simpler versions of the modern intel cpus stripped of all this insecure bloat. Surely I can't be the only one?

willvarfar 10y ago
(Mill CPU team) I'm putting together a security white paper at the moment. We've been quiet because we've been real busy and we have more new stuff to talk about if only we had time to write it up for public, so watch this space :)
djsumdog 10y ago
We can't even get newer x86/64 boards without closed binary blobs everywhere. Look at Librem. I think the last truly open laptop in the x86 world was the X200 Thinkpad. All the newer opensource laptops are all ARM based, which is just going to mean a lot of fragmentation until things like the ARM config/device-tree stuff catches up to EFI.
nickpsecurity 10y ago
There's potentially room for a cloud or datacenter company to pull it off by paying Intel to do it via semi-custom business they have. Or AMD who started that model in x86. Just the high-performance HW and microcode without any other crap with other stuff in trust boundary offloaded to coprocessors we can build and verify. We can also add in some real security like in Watchdog or CHERI CPU's while we're at it. CHERI already runs FreeBSD so we'd have that immediately if we ported their toolchain to x86.
0xfeba 10y ago
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation https://www.crowdsupply.com/raptor-computing-systems/talos-s... There are few "open" hardware/firmware efforts going on now.
anonymousDan 10y ago
What has tsx got to do with security? It's for efficient transactional memory.

willvarfar 10y ago

(This popped up on proggit the other day, but got deleted for some reason: https://www.reddit.com/r/programming/comments/58fpi6/aslr_protection_on_intel_haswell_takes_only_60ms/ https://www.reddit.com/r/programming/comments/58fpi6/aslr_pr... )

dooglius 10y ago

For a system as complex and intricate as a modern processor, it seems impossible to avoid a userspace application from figuring out at least some basic information about the kernel's state. It would be better to focus on avoiding actual privilege escalations.

ryuuchin 10y ago

So yet another KASLR bypass. Reminds me of[1]: > Consider this our "I told you so" that we hope you'll remember in the coming years as KASLR is "broken" time and again. Then again, in this offensive-driven industry, that's where the money is, isn't it? [1] https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=ee9f8c1bacede4863bcab77b96eff623 https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=e...

Animats 10y ago
That article is correct. Address-space randomization wasn't a fix. It was a way to avoid fixing problems, by claiming that the ability for attacks to execute hostile code in some other process's space wasn't a problem. The problem is giant kernels that change constantly. It doesn't have to be that way. Look at L4 and QNX. With sufficient code bloat, all bugs are deep.
- nickpsecurity 10y ago
  "With sufficient code bloat, all bugs are deep." That's an interesting statement. Might have to think on it. While we're on secure kernels, did you ever have any experience with the ASOS system or hear about it from someone who did? It was the only Ada OS aim for A1 class that actually got delivered far as I can tell from papers. Then info disappears into a black hole. Be interesting to find out how well it worked or didn't as putting a modern version of that in a container or on top of seL4 might be worth trying. Note: MaRTE OS is an Ada-based, open-source RTOS still in development and use. Not security-focused, though. Muen is just a separation kernel. A secure one could draw on them a bit.
  - Animats 10y ago
    Not ASOS, no. I worked on KSOS-11, an attempt to cram a secure OS written in Modula into a PDP-11. It ran, but the 64K address space was too much of a limitation. As for "with sufficient code bloat, all bugs are deep," that's my answer to Torvalds' "given enough eyeballs, all bugs are shallow". Time has proven him wrong - the number of bugs in the Linux kernel continues to increase as the kernel becomes more bloated. 16 million lines of code and still growing![1] This is why microkernels are the way to go. Good microkernels run about 10,000 lines of code. It's possible with 10,000 lines of code to have a steadily decreasing number of bugs. We now have a situation where neither Linux nor Windows is securable. We're paying the price for that. [1] https://www.linuxcounter.net/statistics/kernel https://www.linuxcounter.net/statistics/kernel