linux-kernel - Re: [RFC] Circumventing FineIBT Via Entrypoints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202502131248.B6CC333@keescook>
Date: Thu, 13 Feb 2025 12:53:28 -0800
From: Kees Cook <kees@...nel.org>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: jannh@...gle.com, jmill@....edu, joao@...rdrivepizza.com,
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
	luto@...nel.org, samitolvanen@...gle.com,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints

On Thu, Feb 13, 2025 at 08:41:16PM +0000, Andrew Cooper wrote:
> On 13/02/2025 8:28 pm, Kees Cook wrote:
> > On Thu, Feb 13, 2025 at 01:31:30AM +0000, Andrew Cooper wrote:
> >>>> Assuming this is an issue you all feel is worth addressing, I will
> >>>> continue working on providing a patch. I'm concerned though that the
> >>>> overhead from adding a wrmsr on both syscall entry and exit to
> >>>> overwrite and restore the KERNEL_GS_BASE MSR may be quite high, so
> >>>> any feedback in regards to the approach or suggestions of alternate
> >>>> approaches to patching are welcome :) 
> >>> Since the kernel, as far as I understand, uses FineIBT without
> >>> backwards control flow protection (in other words, I think we assume
> >>> that the kernel stack is trusted?),
> >> This is fun indeed.  Linux cannot use supervisor shadow stacks because
> >> the mess around NMI re-entrancy (and IST more generally) requires ROP
> >> gadgets in order to function safely.  Implementing this with shadow
> >> stacks active, while not impossible, is deemed to be prohibitively
> >> complicated.
> > And just validate my understanding here, this attack is fundamentally
> > about FineIBT, not regular CFI (IBT or not), as the validation of target
> > addresses is done at indirect call time, yes?
> 
> I'm not sure I'd classify it like that.  As a pivot primitive, it works
> very widely.
> 
> FineIBT (more specifically any hybrid CFI scheme which includes CET-IBT)
> relies on hardware to do the course grain violation detection, and some
> software hash for fine grain violation detection.
> 
> In this case, the requirement for the SYSCALL entrypoint to have an
> ENDBR64 instruction means it passes the CET-IBT check (does not yield
> #CP), and then lacks the software hash check as well.
> 
> i.e. this renders FineIBT (and other hybrid CFI schemes) rather moot,
> because one hole is all the attacker needs to win, if they can control a
> function pointer / return address.  At which point it's a large overhead
> for no security benefit over simple CET-IBT.

Right, the "if they can control a function pointer" is the part I'm
focusing on. This attack depends on making an indirect call with a
controlled pointer. Non-FineIBT CFI will protect against that step,
so I think this is only an issue for IBT-only and FineIBT, but not CFI
nor CFI+IBT.

> The problem is that SYSCALL entry/exit is a toxic operating mode,
> because you only have to think about sneezing and another user->kernel
> priv-esc appears.

Yeah, once an attacker can make an indirect call to a controlled
address, everything falls apart. And using the entry just makes the
pivot all that much easier to find/use.

-Kees

-- 
Kees Cook