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: <fa66e2f1-4770-45f5-aa4d-1a0ebec8a912@citrix.com>
Date: Tue, 25 Feb 2025 18:10:44 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Rudolf Marek <r.marek@...embler.cz>, Jann Horn <jannh@...gle.com>
Cc: jmill@....edu, joao@...rdrivepizza.com, luto@...nel.org,
 samitolvanen@...gle.com, "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 linux-hardening@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
 x86 maintainers <x86@...nel.org>
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints

On 22/02/2025 8:43 pm, Rudolf Marek wrote:
> Hi,
>
> Dne 13. 02. 25 v 3:42 Andrew Cooper napsal(a):
>> The SYSCALL behaviour TLDR is:
>>
>>      %rcx = %rip
>>      %r11 = %eflags
>>      %cs = fixed attr
>>      %ss = fixed attr
>>      %rip = MSR_LSTAR
>>
>> which means that %rcx (old rip) is the only piece of state which
>> userspace can't feasibly forge (and therefore could distinguish a
>> SYSCALL from user vs kernel mode), yet if we're talking about a JOP
>> chain to get here, then %rcx is under attacker control too.
>
> The SYSCALL instruction also provides means to create "incoherent"
> state of the processor selectors
> where the value of selector do not match pre-loaded values in the
> descriptor caches.

Very cunning.  Yes it does, but the state needs to be safe to IRET back
to, and ...

> Would it work to have KERNEL_CS as last entry in the GDT table?
> Therefore executing SYSCALL would set the CS as usual,
> but the numeric value of SS selector would be larger than GDT limit?

... this isn't safe.  Any exception/interrupt will yield #SS when trying
to load an out-of-limit %ss.

i.e. a wrongly-timed NMI will take out the system with a very bizarre
looking oops.

You can do this in a less fatal way by e.g. having in-GDT form have a
segment limit, but any exception/interrupt will resync the out-of-sync
state, and break detection.  Also it would make the segment unusable for
compatibility userspace, where the limit would take effect.

Finally, while this potentially gives us an option for SYSCALL and maybe
SYSENTER, it doesn't help with any of the main IDT entrypoints which can
also be attacked.

~Andrew