4 ms·

New code for SIGILL faults to help identify misbranches on OpenBSD

112 points by peter_hansteen 3y ago

actionfromafar 3y ago
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 3y ago
  This is an instance of control-flow integrity. https://en.wikipedia.org/wiki/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 3y ago
    As described, something more akin to https://en.wikipedia.org/wiki/Return-oriented_programming#Branch_Target_Identification_(BTI) 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 3y ago
      Interesting! I guess that particular mechanism is ARM-specific?
      - seppel 3y ago
        X86 has ENDBR32 and ENDBR64 (end branch) for this.
      - Findecanor 3y ago
        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 3y ago
        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 3y ago
        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 3y ago
  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/88580652a3669007813512ab28f5ee7ceeae4a78 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 3y ago
    > 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 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 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 retpoline. OpenBSD has done a lot of work to push these changes into the entire software ecosystem.
    - guenthert 3y ago
      Did I get that right? The company which brought us SPECTRE now brings us a feature requiring us to disable SPECTRE mitigation? I haven't followed this and surely misrepresent the facts above. This is just a plea for someone in the know to clarify the situation.
  - MuffinFlavored 3y ago
saagarjha 3y ago
Neat. Is the expected consumer here meant to be debuggers, or a crash with security implication?
anthk 3y ago
Similar on approach on the 'S' malloc.conf setting I guess.

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 3y ago
This is an instance of control-flow integrity. https://en.wikipedia.org/wiki/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 3y ago
  As described, something more akin to https://en.wikipedia.org/wiki/Return-oriented_programming#Branch_Target_Identification_(BTI) 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 3y ago
    Interesting! I guess that particular mechanism is ARM-specific?
    - seppel 3y ago
      X86 has ENDBR32 and ENDBR64 (end branch) for this.
    - Findecanor 3y ago
      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 3y ago
        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 3y ago
        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 3y ago
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/88580652a3669007813512ab28f5ee7ceeae4a78 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 3y ago
  > 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 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 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 retpoline. OpenBSD has done a lot of work to push these changes into the entire software ecosystem.
  - guenthert 3y ago
    Did I get that right? The company which brought us SPECTRE now brings us a feature requiring us to disable SPECTRE mitigation? I haven't followed this and surely misrepresent the facts above. This is just a plea for someone in the know to clarify the situation.
- MuffinFlavored 3y ago

saagarjha 3y ago

Neat. Is the expected consumer here meant to be debuggers, or a crash with security implication?

anthk 3y ago

Similar on approach on the 'S' malloc.conf setting I guess.