RET2DIR Mitigated by CFI -- Kernel Discussions on CONFIG_XPFO

wryMitts commented 4 months ago

After reading these conversations, per Torvalds and other devs it seems that XPFO's defense on ret2dir is less of a code execution threat, and more a data exposure threat. The term was coined "read2dir" instead.

Thoughts on the map, perhaps move ret2dir under CFI protections, but also split to have read2dir?

On Thu, Apr 18, 2019 at 7:35 AM Khalid Aziz khalid.aziz@oracle.com wrote:

On 4/17/19 11:41 PM, Kees Cook wrote:

On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski luto@kernel.org wrote:

I don't think this type of NX goof was ever the argument for XPFO. The main argument I've heard is that a malicious user program writes a ROP payload into user memory (regular anonymous user memory) and then gets the kernel to erroneously set RSP (not RIP) to point there.

Well, more than just ROP. Any of the various attack primitives. The NX stuff is about moving RIP: SMEP-bypassing. But there is still basic SMAP-bypassing for putting a malicious structure in userspace and having the kernel access it via the linear mapping, etc.

I find this argument fairly weak for a couple reasons. First, if we're worried about this, let's do in-kernel CFI, not XPFO, to

CFI is getting much closer. Getting the kernel happy under Clang, LTO, and CFI is under active development. (It's functional for arm64 already, and pieces have been getting upstreamed.)

CFI theoretically offers protection with fairly low overhead. I have not played much with CFI in clang. I agree with Linus that probability of bugs in XPFO implementation itself is a cause of concern. If CFI in Clang can provide us the same level of protection as XPFO does, I wouldn't want to push for an expensive change like XPFO.

If Clang/CFI can't get us there for extended period of time, does it make sense to continue to poke at XPFO?

Well, I think CFI will certainly vastly narrow the execution paths available to an attacker, but what I continue to see XPFO useful for is stopping attacks that need to locate something in memory. (i.e. not ret2dir but, like, read2dir.) It's arguable that such attacks would just use heap, stack, etc to hold such things, but the linear map remains relatively easy to find/target. But I agree: the protection is getting more and more narrow (especially with CFI coming down the pipe), and if it's still a 28% hit, that's not going to be tenable for anyone but the truly paranoid. :)

All that said, there isn't a very good backward-edge CFI protection (i.e. ROP defense) on x86 in Clang. The forward-edge looks decent, but requires LTO, etc. My point is there is still a long path to gaining CFI in upstream.

a13xp0p0v commented 4 months ago

Hi @wryMitts, Thanks for creating this issue!

As I understand the terminology in this LKML discussion, they use:

ret2dir for executing exploit payload using the direct mapping,
read2dir for getting data needed for exploit using the direct mapping. On the Linux Kernel Defence Map, we already have ret2dir + ROP/JOP/COP, but read2dir would be a more generic term.

Let's see whether read2dir become a popular term (for adding it in future).

Please see the commit https://github.com/a13xp0p0v/linux-kernel-defence-map/commit/02cd95c11eb33a76e607c05f8a218c856b12865a, where I fixed the link from cluster_cfi. Now CFI is connected to all control flow hijack techniques, which is more correct. Thank you!

a13xp0p0v commented 4 months ago

Hmmm...

Maybe we need to add something like Userspace Data Access via direct mapping (or linear mapping?) instead of read2dir to show that the XPFO approach provides additional security effects comparing to CFI.

But this concept looks very long.

a13xp0p0v / linux-kernel-defence-map

RET2DIR Mitigated by CFI -- Kernel Discussions on CONFIG_XPFO #11