Hacker News new | past | comments | ask | show | jobs | submit login

Why is mere information disclosure about kernel layout severe enough to warrant a slowdown and patch like this? I suppose it's gated behind a feature flag? I'm wondering because I thought just knowing the layout isn't enough to attack the kernel. Don't you need other vulnerabilities too, that let you actually access the memory?

Address randomization is nice, but if an attacker can write to arbitrary pages, potentially including the kernel, isn't it game over no matter what? I'm not an expert on this and would be interested to know more.

Also, do these activities imply that there may be significant known but embargoed vulnerabilities? In particular, Linux accepting a patch like this so late into the release cycle.




> I'm wondering because I thought just knowing the layout isn't enough to attack the kernel. Don't you need other vulnerabilities too, that let you actually access the memory?

NB: My understanding of this is purely arm's-length. I've never actually done exploit development.

Short version: you need to know the layout of the code in order to actually exploit those other vulnerabilities.

Longer version:

Attackers: We can inject machine code into the stack and execute it [1].

Developers: Not anymore; stack pages aren't executable [2].

Attackers: We can turn your own code against you by manipulating the stack to "return" to an arbitrary sequence of pre-existing functions with arguments of our choosing [3].

Developers: Not anymore; we randomize the address space every time we load the code, so now you don't know where those functions are. You could guess, but you're going to be wrong and just crash the system almost all of the time [4].

Attackers: For the kernel on x86/amd64 systems, we have a way of reading the page table from an exploited user process, which we can then parse to discover where you located those functions. <---- you are here

[1] https://en.wikipedia.org/wiki/Stack_buffer_overflow#Exploiti...

[2] https://en.wikipedia.org/wiki/NX_bit

[3] https://en.wikipedia.org/wiki/Return-oriented_programming

[4] https://en.wikipedia.org/wiki/Address_space_layout_randomiza...


Thanks. That was a very helpful explanation!


I’d suppose there’s at least rowhammer to worry about.


The patch itself is only going into 4.16, these are just preconditions. But yes it is all rather odd.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: