3 ms·

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.

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.

viraptor 10y ago
> 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.
knorker 10y ago
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.
tptacek 10y ago
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.
- djcapelis 10y ago
  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.

viraptor 10y ago

> 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.

knorker 10y ago

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.

tptacek 10y ago

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.

djcapelis 10y ago
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.