A reminder regarding CET news making the rounds today: the forward edge of its CFI is the most coarse-grained possible, already well-studied in academic literature and deemed ineffective. We covered CET 4 years ago: grsecurity.net/effectiveness…
3
19
32
Fact is: There is no deployed in-browser JIT that implements anything like RAP, so my above statement holds :-).
Do I believe that you could possibly implement it? Yes. Do I think you will? No.
So I think my sweeping statement will hold true for the next couple years at least.
4
1
3
also there's natural protection for the return hash by virtue of the replacement code likely not having a matching hash value at the right places for your c++ method to return to ;).
1
1
i "won't" implement it 'cos i have already implemented parts of it (transitions between the c++/JIT world). the rest depends on my time i can spend on it, but it's not that a big deal in terms of engineering hours.
1
1
you tell me, you made the sweeping comment about CFI being useless in the presence of JIT :). as for RAP and, say, chromium, it's existed since 2014 or something, with some, but certainly not complete support for its JIT engines :).
1
1
RELRO pages start out as normal writable file maps that then go through COW so after that they're treated as anonymous pages and would be backed by swap if they were to be swapped out.
1
In your analysis against CET you assume arbitrary Read writes. But for RAP you propose prevention against read primitives rather than assuming read primitives are available (like CET does). Why so?
/4
3
RAP has not 1 *but* 2 features that deal with the return address. one's type hash based (less precise but impervious to read/write bugs) and the other is the xor cookie (precise but vulnerable to read bugs). combined, they're the strongest defense we know of.
@grsecurity
In your analysis you mentioned that attacker can use RELRO pages and perform writes to manufacture RO but dirty (thus shadow stack) pages.
CET prevents that by faulting ;
CR0.WP can't be cleared if CR4.CET = 1. Setting CR4.CET while CR0.WP=0 will fault.
/2
3
RELRO pages have nothing whatsoever to do with CR0.WP. it's a pure sw construct that through syscalls ends up creating the exact pte rights that also mark shadow stacks (unless said sw construct takes care of preventing that, hw can't do anything about it).
1
I think you misunderstand: The call from C++FuncA can do all the validating it wants, it's the return from C++FuncC that returns into different code than it left.
3
2
and how will you make sure that the replacement has a matching return type hash (and the rest of it is useful enough to do your bidding)?
1
1
For those who want to get their feet wet in exploit mitigation development, writing unit tests to verify current mitigations is a great first step.
This tweet is unavailable
1
4
9
It would be even better to write new tests if you want to include them into base system, because paxtest is GPL.
Or get an exception or relicensing from the authors.
CC: @paxteam
2
PaX Team retweeted
Had some time to update the research page this morning: grsecurity.net/research Currently at 560 citations that I've found. Probably a lot still missing. Moved some of the more interesting ones (like the recent SpecFuzz paper) closer to the top. Enjoy!
1
2
22
PaX Team retweeted
Our team is growing! Very happy to welcome @_minipli as our newest full-time kernel developer, accelerating our development of the next generation of @grsecurity features
3
16
today's quiz: what's wrong with the seemingly trivial (and even reviewed) commit 492c88720d36eb662f9f10c1633f7726fbb07fc4? (it was just backported to stable kernels, hence the belated notice)
1
4
ICYMI RAP bypass for root -> kernel exploits on grsec. I did find the angry grsec/PaX replies entertaining too. Remember when grsec had to pay out a quarter mil because he couldn't handle critique?
H/T @silviocesare
nitter.vloup.ch/uid1000/status/1…
theregister.co.uk/2018/06/11…
"Control-Flow Integrity for the Linux kernel: A Security Evaluation" is the work I've done for my Masters thesis where I analyze how the PaX Team's (public) RAP holds up to stop ROP when applied to the Linux kernel. You may want to check out chapter 3.
alunos.dcc.fc.up.pt/~up20140…
1
6
nitter.vloup.ch/uid1000/status/1… says otherwise? It has to do with KERNEXEC, what makes it possible to write to such data? ;)
Where was that? Pretty sure not on this version... Btw, how's that holding up with .rodata as executable? :P
1
and how would you know who we have asked to look at our code? :) hint: there're people (much) smarter than you who have.
1
"I've found two methods actually, it may require some
CONFIG_* but it's enabled pretty much everywhere."
1
But hey, if the security of your system is based on people not having access to it to inspect it, suit yourself
1
based on your incompetence and outright childish behaviour you're not on the list of people i'd ever trust or even ask to evaluate anything remotely related to security.
1
core_pattern isn't read-only under PaX, nor does RAP have anything to do with data-only attacks. on the other hand you yourself admit that following the very explicit advice on grsec_lock prevents your 'attack'.
2
its the reliance on KERNEXEC is because that's what deals with page protections, so it's a prerequisitive. much like how other defenses in PaX build on others.
Isn't KERNEXEC was a PaX feature? ;) You know all too well that RAP is useless if code-injection is possible (it completely eliminates its purpose). Guess what? I also clearly mention this if you've missed it (which turned out to be true of course):
2
what does KERNEXEC have to do with core_pattern not being protected in PaX? and __read_only has nothing to do with KERNEXEC's purpose as it applies to data, not code (be that static or runtime generated), it's only a very small step towards defending against data-only attacks.
1