Those bugs come from syscall fuzzing. Local privilege escalation is the worst thing you can get from it, so the results are as bad as they can be (apart from finding multiple privilege escalations that is).

I see your point, but it doesn't happen to be true, a bug in recv, send or other networking syscalls certainly could be much worse than a local priv escalation.

And seriously, only one local priv escalation and some crashers is still a pretty light haul for a good fuzzing session from a competent team. The sky is not falling for OpenBSD today.

I'm not sure I follow. Certainly, bugs in the TCP/IP subsystem can be worse than syscall bugs. But what's the bug in recv(2) that is going to be worse than that?

I don't think anyone thinks the sky is falling. To me what's interesting about this is the approach Jesse and Tim took, and how quickly it generated very straightforward panics.

If there was a systematic bug in receive or send where a certain string of data corrupted a buffer allowing for code execution, exploiting it remotely would be simple if there's any code on the machine using that syscall.

I'm not saying this is a likely bug, or even something vaguely reasonable, but it could totally be found with local syscall fuzzing, so local priv escalation isn't the worst bug you can uncover.

I'm mostly being pedantic here.

send/recv is the syscall side of the kernel, so no that's still local attackers.

"I'm going to try to find bugs by calling 'recv' with strange parameters" will not find bugs that are triggered by any type of data coming off of the wire.

Yes, it's not impossible, but seems about as likely to me as fuzzing syscalls locally would be at finding security holes in www.facebook.com by connecting to it and fuzzing up an SSL connection.

> a bug in recv, send or other networking syscalls certainly could be much worse than a local priv escalation

I think that's very unlikely. Since most of the socket API ignores the payload (it's just opaque data), I don't see how recv/send issue could be triggered from outside. Syscall vulnerabilities are usually based on bad flags, bad addresses, or type confusions. Normally you have to have local access to control those.

It looks like most of them cause panics; which are still pretty bad. An unprivileged user shouldn't be able to crash your system.

OpenBSD entire underlying theme and goals are based around security, and their record is actually really good in that regard.

The fact that it's taken this long and a powerful fuzzer to find all these shows their commitment to security while also showing what we can accomplish with fuzzers today.

I've got an old X1 I plan on installing/trying out OpenBSD.

Right? As much as anything this seems like they've found places where OpenBSD perhaps drifted from their best practices. How many panics are in their kernel today and how many should be there? Knowing the OpenBSD guys this has already triggered at review at that level of their entire source code.

Ya I was quite impressed.