[HN Gopher] New code for SIGILL faults to help identify misbranc...
___________________________________________________________________
New code for SIGILL faults to help identify misbranches on OpenBSD
Author : peter_hansteen
Score : 63 points
Date : 2024-02-22 18:37 UTC (4 hours ago)
(HTM) web link (www.undeadly.org)
(TXT) w3m dump (www.undeadly.org)
| actionfromafar wrote:
| Can someone explain how this works? What would trigger a
| misbranch and how can the OS tell the difference? I read the page
| and the link but I don't understand.
| schoen wrote:
| This is an instance of control-flow integrity.
|
| https://en.wikipedia.org/wiki/Control-flow_integrity
|
| I guess (although it doesn't specifically say) that this is
| making use of Intel's CET feature?
| mcarmichael wrote:
| As described, something more akin to
|
| https://en.wikipedia.org/wiki/Return-
| oriented_programming#Br...
|
| That page has a reasonable summary of the exploitation
| techniques and history motivating this work.
| schoen wrote:
| Interesting! I guess that particular mechanism is ARM-
| specific?
| seppel wrote:
| X86 has ENDBR32 and ENDBR64 (end branch) for this.
| Findecanor wrote:
| The article mentions both 64-bit ARM and x86. Intel's
| ENDBR64 (part of CET) and ARMv8.5A BTI work largely the
| same. The instructions are NOP on older processors or if
| not enabled by the OS.
|
| BTW. A similar extension is also about to be approved for
| RISC-V: "Zicfilp". It also repurposes an instruction that
| was previously a NOP.
| schoen wrote:
| Cool, thanks!
|
| So, ROP itself is a (frequently very effective)
| workaround for W^X memory protection features, where
| executable code itself should be unmodifiable at runtime.
| I wonder if there's a "next" CFI attack that calls
| existing functions that are actually defined as such, but
| in a weird order, or with weird arguments.
|
| The ability to do that effectively would depend on lots
| of stuff, including the calling convention (as the stack
| or heap are easier to corrupt than registers).
|
| Maybe someone is already writing an advanced ROP gadget-
| search that looks for "real functions that can be
| combined to make ROP gadgets by calling them in a bizarre
| way". (This is already much less likely to occur in a
| real program ... I think ...! But maybe the return-to-
| libc phenomenon is still a rich source of vulnerability?)
| wahern wrote:
| Interestingly, RISC-V's Zicfilp proposal includes an
| optional, 20-bit label operand so that call sites and
| targets can be paired more strictly.
|
| I'm not sure how or if it addresses trampolines and
| similar thunks that interpose callee and caller, but
| which don't necessarily touch arguments. Such thunks are
| quite common in dynamically linked code as ELF and Mach-O
| do lazy loading by default--dynamic function symbols are
| initially small thunks that load the dependency and then
| forward the call, restoring registers and the stack
| without having to know the call signature.
| wahern wrote:
| As a ROP mitigation measure some recent CPU models have a
| feature that can require code to branch to a special
| instruction signifying a valid target; jumps to an address that
| doesn't contain that instruction result in a CPU fault. On
| OpenBSD such a fault is translated to SIGILL, apparently, which
| can also occur when the CPU encounters other issues, like an
| invalidly encoded instruction. This patch differentiates the
| new type of fault so it's easier to identify within process
| signal handlers by adding a new reason code, ILL_BTCFI, to
| SIGILL info (siginfo_t).
|
| The full patch is at
| https://github.com/openbsd/src/commit/88580652a3669007813512...
|
| I'm not sure if this patch is noteworthy on its own, but
| perhaps it was posted because it implies this CPU feature is
| now supported or soon to be supported by OpenBSD.
| brynet wrote:
| > I'm not sure if this patch is noteworthy on its own, but
| perhaps it was posted because it implies this CPU feature is
| now supported or soon to be supported by OpenBSD.
|
| OpenBSD has supported mandatory BTI/IBT on Intel CPUs (11th
| Gen+) and arm64 (Apple M2) since 7.4 (Oct 16, 2023).
|
| https://www.openbsd.org/innovations.html
|
| "Mandatory enforcement of indirect branch targets (BTI on
| arm64, IBT on Intel amd64), unless a linker flag
| (-Wl,-z,nobtcfi) requests no enforcement."
|
| https://marc.info/?l=openbsd-ports&m=168899645126958&w=2
|
| OpenBSD recently disabled retpolines by default because they
| are incompatible with IBT, so there has been some work done
| recently that this patch could help with, e.g: adding missing
| indirect branch target instructions (endbr64), previously
| hidden by repoline. OpenBSD has done a lot of work to push
| these changes into the entire software ecosystem.
| saagarjha wrote:
| Neat. Is the expected consumer here meant to be debuggers, or a
| crash with security implication?
| anthk wrote:
| Similar on approach on the 'S' malloc.conf setting I guess.
___________________________________________________________________
(page generated 2024-02-22 23:00 UTC)