3 ms·
Not questioning the OP's intentions, but a remote vulnerability in most SCTP stacks was published last week: http://pastebin.com/m6863ef05 http://pastebin.com/m
by agnokapathetic 17y ago
Not questioning the OP's intentions, but a remote vulnerability in most SCTP stacks was published last week: http://pastebin.com/m6863ef05 http://pastebin.com/m6863ef05 CVE-2009-0065
- tptacek 17y agoThis is a vulnerability in one SCTP stack. Linux's. I'm not sure there's a single mainstream protocol that hasn't had a vulnerability.
- agnokapathetic 17y agoIts not every day you see remote code execution exploit of a Transport layer protocol, and what OS do you think people are going to be toying around with SCTP... Linux. This is serious. edit: needed to review the OSI model.
- duncanj 17y agoTransport layer
- tptacek 17y agoWTF do I care if the protocol you broke was transport layer or application layer? Code execution is code execution. What a strange argument.
- mmelin 17y agoSimply because a vulnerability in the transport layer results in every service relying on that protocol to be vulnerable? Are you saying that a remote code execution vulnerability in TCP would not be worse than one in for instance FTP? (I am aware of your credentials so I'm trying to figure out what I'm missing, not trying to be snippy)
- tptacek 17y agoOk. Fair point. TCP would be worse than FTP, because you could hit it from ports 21, 22, 80, and 443. FTP would be far worse than SCTP, because you're much more likely to be using it. I'll admit, my mind jumped immediately to "vulnerability in the kernel! much worse than vulnerability in a web server!", which is exactly the wrong way to think about the problem --- once you've conceded code execution to an attacker, you've conceded the box. Maybe that wasn't his argument. Thanks for calling me out on that. Either way, the Linux advisory he cited should have absolutely no impact on your consideration of SCTP.