Re: [RFC] Circumventing FineIBT Via Entrypoints

[Kees Cook <kees@kernel.org>]

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