Saagar Jha (@saagar@saagarjha.com)

Saagar Jha

12/12/2023 (replying to Saagar Jha)

To be clear I want OpenBSD to be secure and the bug isn’t *stupid*, it’s just trivial. The funny part is that you go through all these gymnastics to target a bogeyman-like exploit class and you really get owned by the fact that you are a fallible human who writes C

2 replies →

2 replies

iximeow

12/12/2023 (replying to Saagar Jha)

@saagar the thing that's really funny to me is that there are two different ways you get heap writes *and* because the mallocs are not M_CANFAIL if your crafted elf is large enough the kernel can't alloc a pin list you can get a kernel panic...

Saagar Jha

12/12/2023 (replying to iximeow)

@iximeow To be fair I consider the panic to be more of a sloppy coding thing than a significant security issue

Dark Sage Torunka :verified:

12/12/2023 (replying to Saagar Jha)

@saagar What does the OpenBSD patch try to do, anyway? I'm curious.

Saagar Jha

12/14/2023 (replying to Dark Sage Torunka :verified:)

@kmeisthax My understanding is that they’re trying to annoy people who can influence control flow such that they can create a controlled state for an arbitrary syscall by making it so that the legitimate syscall instructions in the address space are tied to their number

Saagar Jha

12/14/2023 (replying to Saagar Jha)

@kmeisthax Personally I don’t think this is particularly worth the trouble but I get the impression that their threat model is that the last time they tried to remove syscall instructions from outside of libc people told them it was easy enough to ROP there

Saagar Jha

12/14/2023 (replying to Saagar Jha)

@kmeisthax (I am still not entirely clear what this is trying to protect against because presumably all the syscall wrappers that libc has still exist in the address space? The “number” field that this is trying to protect does not look very valuable)

Saagar Jha

12/14/2023 (replying to Saagar Jha)

@kmeisthax (Like, the goal seems to be “oh the attacker cannot put an arbitrary thing in rax and jump to a syscall instruction”. But like libc *by design* has to have gadgets that load it up with basically any valid syscall number…)

Dark Sage Torunka :verified:

12/14/2023 (replying to Saagar Jha)

@saagar I suspect OpenBSD plans to change its libc to not have that kind of gadget and instead have a separate wrapper per syscall. They can do that because OpenBSD does NOT make any KABI promises whatsoever (unlike Linux).

This is also why Go keeps breaking on OpenBSD. I suspect that might also be part of their threat model...

Saagar Jha

12/14/2023 (replying to Dark Sage Torunka :verified:)

@kmeisthax This is going to break applications that use dlsym to look up symbols in libc though

Saagar Jha

12/14/2023 (replying to Saagar Jha)

@kmeisthax Like if you take this to its logical conclusion it’s just “applications should specify which system calls they use” which is literally just what pledge does and it’s enforced by the kernel and not in some weird ad-hoc IP to syscall number lookup scheme

Dark Sage Torunka :verified:

12/14/2023 (replying to Saagar Jha)

@saagar 2033: OpenBSD now requires all applications provide a control flow graph of the entire binary and validates it against the stack trace at every libc call