Re: [RFC] Circumventing FineIBT Via Entrypoints

[Jann Horn]

On Thu, Feb 13, 2025 at 9:53 PM Kees Cook <kees@xxxxxxxxxx> wrote:
> 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.

To me, "CFI" is really just a fairly abstract concept; are you talking
specifically about the Clang scheme from
<https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html>, or
something else?