The grsecurity "RAP" patch set

[Posted February 7, 2017 by corbet]

The grsecurity developers have announced the first release of the "Reuse Attack Protector" (RAP) patch set, aimed at preventing return-oriented programming and other attacks. "RAP is our patent-pending and best-in-breed defense mechanism against code reuse attacks. It is the result of years of research and development into Control Flow Integrity (CFI) technologies by PaX. The version of RAP present in the test patch released to the public today under the GPLv2 is now feature-complete."

The grsecurity "RAP" patch set

Posted Feb 7, 2017 1:19 UTC (Tue) by roc (subscriber, #30627) [Link] (2 responses)

I'm looking at the 2015 slides, which say:
> XOR canary method is vulnerable to arbitrary reads
> ASLR helps a bit: two leaks are needed
> encrypted return address
> plaintext code address (not necessarily the return address)
> Combine with return place (code pointer target) verification

So just to clarify: if an attacker obtains an unlimited-read primitive in a multi-threaded user-space protected by RAP, they can bypass RAP? (It seems to me they could, since they could determine a thread's RAP cookie and also the hashes needed to construct valid return address targets.)

Seems like RAP would benefit from user-space per-thread stack protection, which you could implement using Intel's Memory Protection Keys (modulo compatibility issues). MPKs also let you make executable code completely non-readable which would be helpful.

The grsecurity "RAP" patch set

Posted Feb 7, 2017 2:12 UTC (Tue) by PaXTeam (guest, #24616) [Link] (1 responses)

determining the xor cookie isn't enough to return to an arbitrary address since the target still must be marked with the proper return type hash, i.e., it must be a valid (intended) return location for the given type. note also that the primary use case for the xor cookie method is the kernel where we have much better control over cookie leaks (and where PKU doesn't exist, unfortunately). that said, i don't see how PKU would help with infoleaks as a thread can leak its own cookie (or derived data) into shared (=visible to other threads) regions as well or just send it through a file descriptor as data. as for unreadable code, that can help at most when the attacker doesn't have access to the code offline already (think distro binaries, etc) which i think is a rare case in real life, not to mention that it's also incompatible with RAP's type hash based checks as the hashes are embedded in the code for performance.

The grsecurity "RAP" patch set

Posted Feb 7, 2017 4:51 UTC (Tue) by roc (subscriber, #30627) [Link]

Interesting.

Have you collected data on whether common software contains adequate ROP chains to launch attacks, with the return type hash checking?

CrOS uses ssp-strong, not ssp-all

Posted Feb 7, 2017 3:55 UTC (Tue) by vapier (guest, #15768) [Link] (1 responses)

> SSP-All was chosen as a comparison since it was used [for a long time by Chrome OS](https://outflux.net/blog/archives/2014/01/27/fstack-prote...)

the text says "CrOS uses ssp-all", but then links to a page that explicitly says CrOS does not -- it uses ssp-strong. seems like an unnecessarily obvious typo.

CrOS uses ssp-strong, not ssp-all

Posted Feb 7, 2017 11:14 UTC (Tue) by FLHerne (guest, #105373) [Link]

No contradiction:

"SSP-All was chosen as a comparison since it was used for a long time by Chrome OS."
--<link>--
"fstack-protector-all was defined to add the canary to all functions. This results in substantial use of stack space for saving the canary on deep stack users, and measurable (though surprisingly still relatively low) performance hit due to all the saving/checking. For a long time, Chrome OS used this, since we’re paranoid."

The grsecurity "RAP" patch set

Posted Feb 7, 2017 4:24 UTC (Tue) by imgx64 (guest, #78590) [Link] (3 responses)

> patent-pending

This is sarcasm, right? What would they do with a patent if they got one?

The grsecurity "RAP" patch set

Posted Feb 7, 2017 8:08 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (1 responses)

Block the reimplementation of RAP by proprietary OS vendors?
And perhaps, if they want to do this, sell to these proprietary OS vendors the right to use the patent?

The grsecurity "RAP" patch set

Posted Feb 7, 2017 19:27 UTC (Tue) by HIGHGuY (subscriber, #62277) [Link]

Or prevent the use in any OS, including Linux, without a license. Given the animosity between them and the current porting of their features to the mainline kernel I wouldn't be surprised. But unless they come forward with their objective, we can't know.
Either way, I (some Joe Nobody in this story) am sure prepared to give them the benefit of the doubt for now.

The grsecurity "RAP" patch set

Posted Feb 7, 2017 8:24 UTC (Tue) by pabs (subscriber, #43278) [Link]

The could do something like these:

http://www.levien.com/patents.html
http://www.advogato.org/article/31.html
http://www.advogato.org/article/89.html

The grsecurity "RAP" patch set

Posted Feb 7, 2017 12:25 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (2 responses)

Cool!

Also interesting is the fact that the patched kernels have fewer branch misses. Is this just a chance occurrence on this one benchmark (running `du -s`) or is there a systematic reason why the patched kernels have fewer branch misses?

The grsecurity "RAP" patch set

Posted Feb 7, 2017 12:35 UTC (Tue) by Sesse (subscriber, #53779) [Link] (1 responses)

There are not fewer branch misses. There's a bunch of additional branches, all of which are easily predictable—thus, the relative branch miss share goes down, but the absolute number of missed branches is roughly the same (probably slightly higher).

The grsecurity "RAP" patch set

Posted Feb 7, 2017 12:38 UTC (Tue) by karkhaz (subscriber, #99844) [Link]

Oh right, I missed that it was given in % rather than an absolute number like the other figures. Thanks!

The grsecurity "RAP" patch set

Posted Feb 7, 2017 12:47 UTC (Tue) by mjw (subscriber, #16740) [Link] (2 responses)

Is there a direct link to the GCC plugin source to read and try out? It looks like the announcement doesn't actually link to the patch released to the public (or I am a bad reader, sorry). Where was it posted?

The grsecurity "RAP" patch set

Posted Feb 8, 2017 2:18 UTC (Wed) by PaXTeam (guest, #24616) [Link] (1 responses)

our plugins are under scripts/gcc-plugins in our kernel patches which are linked from the homepage. note that using RAP outside of the supported kernel versions or userland requires fixing any function pointer abuse first (lest they trigger the defense mechanism at runtime).

The grsecurity "RAP" patch set

Posted Feb 8, 2017 21:31 UTC (Wed) by Lionel_Debroux (subscriber, #30014) [Link]

To build on PaXTeam's comment: there is _much_ function pointer abuse in mainline Linux...
The corresponding fixes throughout the tree (drivers, fs, net, sound, etc.) make up a significant proportion of the size increase between the grsec 4.4.x (last version without RAP, 4.4.8 is just above 8e6 bytes) and 4.5.x patches (4.5.2 is just above 9e6 bytes, +~12%). The diff between copies of these patches confirms.

The grsecurity "RAP" patch set

Posted Feb 7, 2017 13:59 UTC (Tue) by welinder (guest, #4699) [Link] (1 responses)

I hope they write clearer code than they write press releases. This one is nothing but fluff
and three-letter acronyms.

The grsecurity "RAP" patch set

Posted Feb 23, 2017 8:58 UTC (Thu) by stephenm (guest, #114284) [Link]

The technical aspect has been well discussed in a formal presentation which is linked on the site. This is a normal business orientated announcement designed to reach the widest audience so that the full significance of what it is about is more well known.