5 ms·

Grsecurity – FAQ about RAP

dantiberian 10y ago
> “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 10y ago
  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.
AstralStorm 10y ago
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 10y ago
  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
  - blockoperation 10y ago
    > 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/scripts/gcc-plugins/rap_plugin https://github.com/minipli/linux-grsec/tree/v4.8.17-pax/scri...
  - gbuk2013 10y ago
    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 10y ago
      > 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.
- icebraining 10y ago
  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.
acqq 10y ago
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.pdf 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 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 10y ago
  >patent pending How is this a good thing? Any more info? Will it be under a copyleft-style patent license?
  - antocv 10y ago
    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 10y ago
      If true, this would be concerning. Do you have an example or other evidence?
      - aseipp 10y ago
        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.
petra 10y ago
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 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 10y ago
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.

AstralStorm 10y ago

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 10y ago
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
- blockoperation 10y ago
  > 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/scripts/gcc-plugins/rap_plugin https://github.com/minipli/linux-grsec/tree/v4.8.17-pax/scri...
- gbuk2013 10y ago
  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 10y ago
    > 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.
icebraining 10y ago
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.

acqq 10y ago

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.pdf 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 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 10y ago
>patent pending How is this a good thing? Any more info? Will it be under a copyleft-style patent license?
- antocv 10y ago
  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 10y ago
    If true, this would be concerning. Do you have an example or other evidence?
    - aseipp 10y ago
      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.

petra 10y ago

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 ?