[VOIPSEC] VoIP vulnerabilities summarization

[Hadriel Kaplan]

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of sukery
> Sent: Thursday, December 15, 2005 10:20 PM
> To: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] VoIP vulnerabilities summarization
>
>  in point 2, I talked about http authentication, which is defined by
> rfc3261, and I think this single-directional authentication is a
> vulnerability of SIP protocol,and this vulnerability has no relationship
> with implementation.

But it does depend on the implementation.  HTTP authentication is only one
of many implementation choices.  You said it's a flaw of SIP itself, but it
isn't.  It's an implementation choice.  For example, rfc3261 also covers
TLS, which provides for mutual-authentication (though at a different layer,
and its optional), as does S/MIME.  SIP also allows you to do no
authentication at all, but that doesn't mean SIP is vulnerable because of
that - just implementations choosing to do that option are. (and some would
still say it's not a vulnerability, but an exposure)

> >#3 - Again, you seem to be pointing a a DoS where the affects would vary
> >between implementation.  Not as close as your #2.
> the transaction mechanism is defined by IETF, all implementation should
> follow this
> standard. so what brings the dos attack is in fact the complexity of
> transaction mechanism but not the implementation. yes, the effects of DoS
> on diffent implementations are not the same, but the truth is that DoS is
> easy to bring down implementations for that they are all built on the same
> mechanism.

Nope, standards define how to logically behave for interoperability reasons,
but they don't define code.  One could, for example, theoretically implement
the transaction mechanism purely in hardware at linerate.  One could also
design a system which can defend itself from such attacks.  Ergo, it is
implementation specific and not a SIP-specific vulnerability.  I have
personally tested such an attack on different devices, and they have very
different susceptibility levels.
(BTW, H.323 is hardly any better when it comes to protocol processing load)

> >#5 -Any program has a code flow. Saying that a program has the potential
> >to be broken is not a vulnerability.
> I think this is a vulnerability. when we talk about CVE, the V means
> vulnerabilities, and many CVE IDs is assigned as a result of some attack
> against implementations.
> code flaw is not a vulnerability of protocol but of implementation.

I think Brian's point here is that saying "programs have bugs" is not a
vulnerability because it's not a specific issue from which an exploit can be
built.  From a CVE perspective it would be an exposure I think, and maybe
not even then. (and only in a trivial sense)  I've never seen a CVE for
"software can have bugs"; as you point out they're assigned to specific
implementation issues/bugs.  A code flaw vulnerability would be a specific
bug which compromises the service in some way - like "Vendors X and Y crash
if sent packets with field Z" - not just a general statement that VoIP code
can have flaws.  Virtually anything can have logic flaws.

I think what you meant to say is that due to the complexity of the protocol,
SIP implementations are more likely to have vulnerabilities than other
protocols?  Or maybe you meant due to the looseness of the message syntax,
SIP implementations are more likely to have exception packet exploits?  (not
that I share those views, just wondering what you meant)

-hadriel