
Grsecurity – FAQ about RAP - executesorder66
https://grsecurity.net/rap_faq.php
======
acqq
Missing there:

\- What the #@$% is RAP:

[https://grsecurity.net/rap_announce.php](https://grsecurity.net/rap_announce.php)

"a _patent pending defense mechanism against code reuse attacks_. RAP was
announced (...) in October 2015 (...). RAP is the result of our (..)
development (...) by PaX. (...) minimal performance impact."

"For a technical deep-dive into RAP, please read the PaX Team's (...) 2015
presentation:"

[https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-
ROP.p...](https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf)

\- What is PaX and who is PaX team:

[https://en.wikipedia.org/wiki/PaX](https://en.wikipedia.org/wiki/PaX)

"PaX is a _patch for the Linux kernel_ that implements least privilege
protections for memory pages."

"PaX is maintained by The PaX Team, whose _principal coder is anonymous._ "

~~~
vedranm
>patent pending

How is this a good thing? Any more info? Will it be under a copyleft-style
patent license?

~~~
antocv
It is an effort against Intel and other "big players" who stole/make-big money
on efforts of small PaX/grsecurity team, not only did Intel though make money
on grsecurity, they actively broke copyright of grsecurity patches.

~~~
amluto
If true, this would be concerning. Do you have an example or other evidence?

~~~
aseipp
I believe he's referring to a situation where Wind River Systems, an Intel
subsidiary, was found distributing the grsecurity patches with Wind River
Linux. On its own, that would be fine, but they _also_ stated their Linux
disto was "using grsecurity" throughout its brochures, etc.[1] This was taken
as a misuse of the grsecurity trademark, since they were not paying for it,
and I believe the grsec/Pax developers were at one point willing to go to
court with Intel over this. But it's currently up in the air.
Trademark/copyright claims in this area are a bit weird (it all depends on how
WR's use of the trademark is interpreted), and Intel also has more money than
God, so there you go.

The situation with Wind River is one of the reasons why the grsecurity stable
patch is no longer publicly available, though, TBF, Wind River wasn't the only
violator. They were more like the last straw, after they (grsecurity) had
dealt with a bunch of other people using their work in the same way. And
regardless of how the court claim would have gone -- honestly it's all a bit
sad to me, given the only thing they've asked is you just don't call it
grsecurity or whatever if you're not paying. Distros like Alpine and
CopperheadOS have been doing just fine for a long time this way, it doesn't
seem hard at all to play nice...

[1] I believe one of the Wind River employees was even ballsy enough to go
onto the grsecurity forums and ask for technical help with part of the
patches, and debugging them. As you can imagine, this did not go over very
well, at all.

------
dantiberian
> “The second defense is more complicated. On entry to a function, it
> essentially "encrypts" the address being returned to by the function, prior
> to any code that could possibly corrupt the return address. The key used to
> encrypt the return address is stored in a reserved CPU register, generally
> ensuring that the key itself should not leak. The resulting value of
> encrypting the return address gets saved in a register, but the actual
> return address in memory is not modified. On return from the function, the
> instrumented code will compare whatever return address exists at that point
> (either legitimate or attacker-modified) to that obtained from decrypting
> the encrypted return address saved in the other register. If the two do not
> match, execution is terminated.”

There's probably a very good reason I'm missing, but could the return address
be hashed and then on return hash the address that is being returned to and
compare it with the previously hashed address? This would prevent the issues
around the encryption key leaking, but probably raises its own issues.

~~~
Buge
The problem I think is that at some point the register containing the
encrypted address needs to be written to the stack, where it could be
overwritten. So if it was just hashed, an attacker could overwrite both the
hash and the plaintext return address, and return wherever they want. Although
hashing with a secret salt would solve that. I don't seen any benefit over
encrypting though.

One attack I can see is in their model of "the attacker can read all memory"
the attacker reads the memory at a time when system() is legitimately called,
then the attacker can know the encrypted version of the system() address, and
use that to overwrite some other return address with system() and the
encrypted version. But I think it would be very unlikely an attacker would be
able to do that.

------
petra
What does RAP mean for a regular Android user using the grsecurity ROM ? what
types of malware does it protects against ? what types it doesn't ?

------
AstralStorm
The abuse of GCC GPLv3 license here is great. (The eligible compilation
process is interpreted very tight. ) FSF getting hamstrung by themselves.

The profit motive is obvious due to a lack of yet easier implementation of the
idea for Clang and LLVM.

~~~
leni536
I wouldn't say it's that great (both technically and in spirit).

> As sole copyright holder on the RAP plugin itself, the PaX Team is only
> licensing the full version under a GPLv3 license to commercial customers to
> permit legal compilation of userland binaries.

So technically nothing stops commercial customers to redistribute the sources
in GPLv3. You can't just give out _exclusive_ GPLv3 licenses, it doesn't make
any sense.

Also where can I download the "public RAP demo"?

edit: IANAL

~~~
gbuk2013
My guess is that there could be some contractual agreement to forbid sharing
of the GPLv3 source?

It is an interesting "hack" though and I would also like to know the answer
(for no reason other than curiosity - I have no use for this software).

~~~
CrLf
> My guess is that there could be some contractual agreement to forbid sharing
> of the GPLv3 source?

That would negate the GPLv3 itself. What they (the PaX team) can do is provide
an exception (like GCC does) to let the client use it while not having their
(the client's) own code infected by the GPLv3.

The client would still be entitled to distribute the software they got from
the PaX team to another party, which would receive it under the same terms.

