5 ms·
Attacking hardened Linux systems with kernel JIT spraying (2012)
- saagarjha 7y ago> A bad guess will likely oops the kernel and kill the current process. Why doesn’t jumping to a random address panic the kernel instead of just killing the current process? Also, I wonder if you can protect against this by XORing constants with a key before writing the instruction stream and then undoing that with later (properly aligned) instructions so the BPF code doesn’t break.
- dang 7y agoDiscussed at the time: https://news.ycombinator.com/item?id=4802381 https://news.ycombinator.com/item?id=4802381.
- akkartik 7y agoI actually searched our history. But I forgot to search for http rather than https :/
- dang 7y agoIt's fine to repost after a year, let alone after seven. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html
- dmix 7y ago> Luckily pax anticipated that attack when releasing the KERNEXEC patch and fixed it a while ago. Naturally.
- justinjlynn 7y agoSo, I'm wondering why it's not upstream in mainline.
- yjftsjthsd-h 7y agoProbably the usual reasons; security-minded patchsets make the kernel more attack resistant, but do so by changing things in ways that trade off against performance or compatibility, and Linux is obsessive about compatibility and cares about performance. I'm not going to say that one approach is objectively better or worse; it's just tradeoffs, and upstream/vanilla Linux prefers a different set of tradeoffs than PAX/GRsecurity/etc.
- staticassertion 7y agoPolitics.
- justinjlynn 7y agoThat applies to everything - it's not a reason, it's an excuse. More specifically, I meant - what was the technical rationale for its exclusion?
- staticassertion 7y agoNone. It is all politics.
- staticassertion 7y agoMore context: https://forums.grsecurity.net/viewtopic.php?t=4463 https://forums.grsecurity.net/viewtopic.php?t=4463 They had a mitigation for this out in no time, as I recall.