About 20y ago, as an evolution from the userland defenses, PaX started on the kernel self-protection journey with KERNEXEC. NX kernel pages on i386 (using segmentation, no actual NX bit then), some read-only kernel data, etc. Still riding high :).
3
13
43
PaX Team retweeted
Nice day when that page table corruption you observe only twice in 3 months ends up being (ironically) an off-by-one in a bad off-by-one testcase in LKDTM
1
8
Recently, I started to research kernel CFI and found that RAP of the PAX team became commercial. Does anyone know where the last public version of RAP is? If you have any clues, please help me! @paxteam @grsecurity
2
1
I have a new, but not serious, question about the commercial version of RAP. Did you adopt the hardware-based shadow stack like Intel CET? Or are you still using function type-based signatures for the backward-edge protection? :)
4
3. there's a non-RAP feature that isolates kernel stacks from each other (only one's mapped at a time on a given CPU).
2
2. RAP's two independent ways to protect returns, one's type hash based (deterministic), the other's the XOR cookie based (probabilistic)
2
Me after watching Theo de Raadt’s #CanSecWest presentation on the next generation of exploit mitigations
2
3
24
PaX Team retweeted
I thought this looked familiar: git.kernel.org/pub/scm/linux… I found/fixed it ages ago by virtue of RANDSTRUCT, let me see when
1
2
12
I appreciate your help. It seems the repo has more later one, 4.9.24. May I use it for my research, or should I use the 4.9.9 version you mentioned?
1
ah yeah, i just looked at the bottom of the list, go ahead with the latest version there (it's just as far from what we have these days :).
1
1
well, well, yet another incredible linux security improvement, some 15y after your first public description of the technique. its completeness is ensured by the total elimination of 5f/c3 from vmlinux. oh wait...
Can I coin the phrase "shell-game defense"? Where it looks like something's happening, but in the end you're just getting scammed: lists.openwall.net/linux-har…
1
1
6
PaX Team retweeted
Today we follow up with @_minipli's investigation into same-type/same-address UAF vulnerabilities in the Linux kernel, including 2 PoC exploits and a discussion of a defense involving a compiler plugin that he developed. Enjoy!
grsecurity.net/exploiting_an…
4
64
2
116
Remembering some 19 year old mailing list flames littered with how PAX_MPROTECT is terrible and wrong as it now gets same supposedly terrible/wrong properties reimplemented by same said person 21 years later under the name 'immutable mappings' 😂
1
4
30
today's puzzle is e10cd4b00904db127b178859d81f6b5d05d16c67 (not really a 0-day if you consider how long it's been out in the open). now the interesting question is whether LBT can spin the fix without mentioning security :).
2
1
14
About 20y ago, as part of a contract job, I documented my ideas on pax.grsecurity.net/docs/ explaining the PaX threat model, the exploit technique based defenses, data-only attacks, CFI, etc. Little did I know that this would set a path that many others would follow year later.
5
32
1
151
PaX Team retweeted
We've just released GCC plugin-powered (and SLS-aware) Retbleed fixes for #grsecurity kernel versions 5.4, 5.15, and 5.17. An in-depth customer knowledge base article from @wipawel has also been published. Please reach out if you have any questions.
9
2
18
PaX Team retweeted
Finally came around to pick up some compiler plugin work I started earlier this year to complete the bug class handling.
Expect new goodies in @grsecurity and a writeup behind the feature’s reasoning soon.
The feature will be improved even further in the near future with yet another plugin-based component developed by @_minipli as well.
4
1
15
PaX Team retweeted
Tetragone: A Lesson in Security Fundamentals
grsecurity.net/tetragone_a_l…
91
9
254
