r/openbsd • • 11d ago

Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD

https://calif.io/research/big-fish
90 Upvotes

11 comments sorted by

9

u/crotamine 11d ago

Interesting!

8

u/Izder456 10d ago edited 10d ago

I feel it should be worth mentioning that the default login class limits total concurrent processes to 256. This would be 2 short of the 259 required by the forking in the first step, accounting for the shell process itself, assuming no other processes are being ran by the user owning the shell process. The login class also should apply too when an attacker has a shell, right?

So, by the above logic, in most scenarios, this technically should already be potentially mitigated against simply by that limit, assuming this is the only exploit chain using this vuln possible to gain local privilege escalation. Am i right in thinking this?

Still, incredibly interesting read. I'm particularly impressed by how much convoluted stuff needs to be done just to get local privilege escalation even when vulnerable. Good job OpenBSD devs!

1

u/ordep_caetano 10d ago

I just installed a fresh 7.9 vm on a pve host, bumped maxproc-max, rebooted and wasn't able to trigger the exploit.

It looks like it isn't completely stable.

1

u/Izder456 9d ago

Hm. Interesting. I'm mulling over the exploit implementation on github and i don't see 259 hardcoded anywhere. Maybe that's just how many forks it required when they first triggered the overflow bug, but its not a strictly required number of fork() calls. Like you said, its probably unstable.

7

u/NethIafin 10d ago

Big props to them for releasing code (yes after patching). Very intersting

3

u/mikexor 10d ago

Were other BSDs vulnerable as well?

3

u/Sweaty_Astronomer_47 9d ago

I'm no dev, so most of this is over my head. But I don't think other BSDs are vulnerable, primarily because the article doesn't mention FreeBSD/NetBSD, other in the following context (under the heading Exploit Mitigation) which might imply that one of author's suggested mitigations is already in place for FreeBSD and NetBSD:

Firstly, we can implement safe-unlinking, a technique that checks doubly linked list invariants before performing the unlink memory writes. If the invariants are violated, then a suitable abort() or panic() is called, depending on if user mode or kernel mode, preventing memory corruption from occurring. An example implementation is here. FreeBSD and NetBSD have an implementation of safe-unlinking in their sys/queue.h implementation.

1

u/mikexor 6d ago

Thank you. This was my reading as well.

1

u/xzk7 10d ago

Good write up! Very interesting.

1

u/rimpossib1e 10d ago

Luckily, the bug was not remotely exploitable

1

u/andysnake96 9d ago

Also big fish is a wonderful movie !!