3 ms·

What is the attack vector on KASLR that KARL prevents? My best guess: A leaked kernel pointer could be used to find an offset for the KASLR kernel, and that of

What is the attack vector on KASLR that KARL prevents? My best guess: A leaked kernel pointer could be used to find an offset for the KASLR kernel, and that offset could produce a working payload for some other unrelated kernel shell code exploit. If that's correct, KARL seems like a pretty fringe improvement over KASLR. Can anyone educate me?

dobin 9y ago
KASLR just requires ONE leaked pointer to calculate base offset of the kernel, and from there is the standard ROPchain technique. The kernel is still one big identical blog, just mapped at a different starting address. If i understand KARL correctly, they reorder the internal code (and data?) in the kernel. Therefore a single pointer-leak does not expose all the ROP gadgets anymore. More information leak is necessary, or a smaller amount of gadgets. Therefore imho this is a much better protection than KASLR.
module0000 9y ago
I don't think it's meant to be a massive improvement - just another one of the many barriers you want to put in front of an attacker. Assume they will get through, but make it as difficult as possible in the hopes that reduces the people who attempt it.
- brian_herman 9y ago
  Or make it as difficult as possible so it will eat up the attacker's time.
lawnchair_larry 9y ago
That's exactly it, more or less. KASLR is almost always useless in practice because there are so many ways to leak kernel pointers that most seasoned researchers are convinced that this will never be plugged. Even if they are, it's often the case that the same bug you are exploiting can also be used to leak enough information. Here is a long anti-ASLR rant by the folks who invented the ASLR mitigation in the first place, explaining why attempts to repurpose the idea for kernel attacks are misguided: https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 I agree that it is probably not a meaningful improvement.
trelliscoded 9y ago
There's this thing called return oriented programming that this is a hard counter to. Return oriented programming replaced shell code a while back when stacks became non executable across the board.

dobin 9y ago

KASLR just requires ONE leaked pointer to calculate base offset of the kernel, and from there is the standard ROPchain technique. The kernel is still one big identical blog, just mapped at a different starting address. If i understand KARL correctly, they reorder the internal code (and data?) in the kernel. Therefore a single pointer-leak does not expose all the ROP gadgets anymore. More information leak is necessary, or a smaller amount of gadgets. Therefore imho this is a much better protection than KASLR.

module0000 9y ago

I don't think it's meant to be a massive improvement - just another one of the many barriers you want to put in front of an attacker. Assume they will get through, but make it as difficult as possible in the hopes that reduces the people who attempt it.

brian_herman 9y ago
Or make it as difficult as possible so it will eat up the attacker's time.

lawnchair_larry 9y ago

That's exactly it, more or less. KASLR is almost always useless in practice because there are so many ways to leak kernel pointers that most seasoned researchers are convinced that this will never be plugged. Even if they are, it's often the case that the same bug you are exploiting can also be used to leak enough information. Here is a long anti-ASLR rant by the folks who invented the ASLR mitigation in the first place, explaining why attempts to repurpose the idea for kernel attacks are misguided: https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 https://forums.grsecurity.net/viewtopic.php?f=7&t=3367 I agree that it is probably not a meaningful improvement.

trelliscoded 9y ago

There's this thing called return oriented programming that this is a hard counter to. Return oriented programming replaced shell code a while back when stacks became non executable across the board.