Hacker News Reader

Comment by MichaelGG | Hacker News Reader

I've seen PBX people find religion once they wake up Monday morning to a weekend of hacked calls to Africa. Though sometimes that religion is in the form of yelling at upstream providers to please give them refunds.

And because of these insecure systems, the more serious issues (all this SIP software is tons of C, and I've found exploits in just 1000 line utilities, let alone protocol level hackery and other fun) get ignored. I found a simple redirect bug in a VoIP platform. Ignored. Later some guy used it to the tune of $90K.

I don't want to become a criminal outright but I've gone from a "friendly disclosure offline and let you lie about fixing issues" to "Sit on 'em and sell 'em one day" model because everyone's so obtuse.

View on HN

SIP... doesn't seem like the greatest protocol. Maybe I'm tainted because I've only really dealt with it in the context of the Microsoft IM/telephony platforms (renamed constantly, but always essentially the same), but it appears to be incredibly brittle complicated. On anything less than a local LAN, messages get dropped or mangled or timed out all the time, and that trashes connections, or puts sessions into unrecoverable states.

I guess you can argue about whether it's the greatest protocol, but the problems you describe most certainly are not procotol problems, but rather broken implementations.

The protocol problems are due to the text-based format and a bizarre desire to make said text format "human friendly". It inherits the stupidity from HTTP (line folding, comments in headers) and adds its own fun. The authors actually suggest that the "intent" of the message be followed in case of errors. It's terrible. The packet issues are due to the strange use of UDP with mandatory TCP switching. Needless complexity.

Oh and these aren't theoretical. Two big, widely deployed implementations cannot even agree on how headers end, and will read the same message differently. This can be exploited when a network does header processing. Imagine adding a "x-accountid" header, and removing any existing ones - if interpretation differ on what constitutes a header, an attacker can slip fake headers in. Not entirely dissimilar to browser exploits that let script include a header with a newline in the value, letting scripts maliciously set headers they shouldn't be allowed to.

Well, yeah, I certainly didn't mean to say that SIP is a great protocol, it is indeed quite terrible--but still in practice if things don't work, that's usually a result of at least one party not following the spec (which is not really surprising , given all the pointless complexity ... but then that's still not really an excuse to not implement SIP when you are claiming that you do).

Practically, it is not possible to implement the spec in an interoperable way. Existing implementations are mutually incompatible. Hence the need for config flags per "trunk". What one system requires, another will reject. Sad but true.

Well, yes. But still, more often than not, when I encounter interoperability problems, if both sides actually did what the spec says, there wouldn't be a problem. SIP itself is quite sad, but in my experience many implementations are even worse than the spec.

NAT punching with SIP has gotten worlds better in the past few years. The protocol itself is sufficient, its just actual implementations that are piss poor at this point, missing even basic stuff like IPv6.

Yeah, "security" people in the VOIP industry can't get their head out of their own ass. Seen it too many times myself!

Reply on news.ycombinator.com