Grsecurity – FAQ about RAP | Hacker News Reader

Grsecurity – FAQ about RAP

grsecurity.net

Missing there:

- What the #@$% is RAP:

"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...

- What is PaX and who is PaX team:

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."

>patent pending

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

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.

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

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.

> “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.

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.

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 ?

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.

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

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

I assume that's the version that comes with the PaX/grsec kernel patches, in which case it's this:

https://github.com/minipli/linux-grsec/tree/v4.8.17-pax/scri...

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).

> 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.

FSF getting hamstrung by themselves.

How so? The users of the binaries are getting a GPLv3 licensed copy of the sources, so the FSF's mission is fulfilled.

You cannot publish binaries built with your version as it has not been built with an "eligible compilation process".

That's the gist. IANAL. Ask FSF what they think about it.

Yes, I realize what happened (though, nitpicking, only because they link those binaries to GNU libraries).

What I don't understand is why you're saying that FSF is hamstrung. Seems like the process is working as intended.

Why not? The "eligible compilation process" only covers the case where you wish to distribute your binaries under terms other than GPLv3. In other words, using a non-eligible compilation process forces you to redistribute binaries under the GPLv3.

If commercial clients get a GPLv3 license from the PaX team, they are entitled (in fact forced) to distribute binaries under that same license, and whoever gets them can ask for the source and then proceeed in doing the same.

GPLv3 working as planned.

(Also, remember that the main difference in the GPLv3 vs. GPLv2 is that the former considers SaaS as a form of distribution, so SaaS users can ask providers for the source of any GPLv3 software they might be using while providing the service.)

Reply on news.ycombinator.com