
The DrK Attack: De-randomizing Kernel ASLR - tsgates
https://github.com/sslab-gatech/DrK
======
JoshTriplett
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...

~~~
shenberg
The system mentioned is TENEX (not *nix) according to
[http://research.microsoft.com/en-
us/um/people/blampson/33-Hi...](http://research.microsoft.com/en-
us/um/people/blampson/33-Hints/WebPage.html) (a great paper from '83 that was
posted here recently. search for password to find the exact reference there)

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

------
ryuuchin
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=e...](https://forums.grsecurity.net/viewtopic.php?f=7&t=3367&sid=ee9f8c1bacede4863bcab77b96eff623)

~~~
Animats
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
"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
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)

~~~
nickpsecurity
"Not ASOS, no. I worked on KSOS-11"

Darn. Oh well. I'm aware of KSOS as we discussed it before. I appreciated the
perspective on it.

"This is why microkernels are the way to go."

I've been thinking more about the alternative where you do monolithic ones
decomposed internally like microkernels with medium-assurance techniques for
development. Basically done like this without formal proofs:

[http://flint.cs.yale.edu/certikos/certikos.html](http://flint.cs.yale.edu/certikos/certikos.html)

Might be a better model as CPU's with more-efficient, isolation mechanisms
come online. I'm recommending micro and separation kernels with mediated
middleware in interim since they're proven to be better than traditional
monoliths. The newer style of development might make new monoliths way better
than before, though.

~~~
anonymousDan
You should take a look at some of the rumpkernel/anykernel work in netbsd, or
projects like the Linux kernel library (LKL). They rearchitect the kernel to
make it more modular.

~~~
nickpsecurity
From what I recall, the Rumpkernels in NetBSD specifically avoided modifying
the kernel to instead come up with an easy way to get to (or test) the
drivers. I still have Anti's thesis & links saved for when I have time to dig
into the concept more. LKL is interesting. A truly modular OS that's
monolithic would let you do something like eCos does below under
"Configurability:"

[http://www.ecoscentric.com/ecos/](http://www.ecoscentric.com/ecos/)

Each unnecessary module can be automatically stripped from the system to make
the OS specific to your needs. The "Just Enough OS" projects for
virtualization were aiming to do similar things with Linux but they kept the
kernel that I'm aware. Ideally, you'd be able to select just the API's,
drivers, etc you need with the rest being stripped out of the generated source
before compile. Similarly for user-land.

------
josteink
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
(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 :)

------
Cyph0n
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 ;)

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

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

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

~~~
andrewstuart2
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-
compu...](https://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-858-computer-systems-security-fall-2014/video-lectures/)

------
cheiVia0
Scary :(

