Replying to @uid1000
this is a sad joke for a 'thesis' i'm afraid. you should have kept true to your word and kept us in the loop about your findings to avoid all these errors.
1
You should also keep true to your word and assume defeat as I've found ways to bypass RAP on the public test patch?
6
3
section 3.3 is even worse. it shows an 'exploit' by changing memory directly from gdb. it only shows you couldn't even find a real bug or create one yourself to do it for real. second, you missed the fact that the xor cookie defense applies to all return addresses, iret included.
1
1
So what does assuming arbitrary r/w mean? gdb does just that, and it's easier for people to understand (not that you have experience with that). If you say so... I can't really verify that.
1
it's described in my H2HC15 presentation that you even linked to (reference ) but clearly never read or understood.
1
I understood it perfectly.
1
you did not otherwise you wouldn't equate debugger access to arbitrary read/write access.
1
So you're telling me with debugger access one can't read from and write to anywhere in memory an arbitrary number of times?
1
i said they weren't equivalent in power, not how their powers are related.
1
1
Cool, and where did I say they were equivalent exactly?
1
Replying to @uid1000
you presented a gdb based 'exploit' as one equivalent to exploiting an 'arbitrary read-write bug'.

Sep 29, 2019 · 8:46 PM UTC

1
Replying to @paxteam
I didn't present a 'gdb based exploit', I simply demonstrated how the kernel's control-flow could be hijacked into kernel space via iret.