[VOIPSEC] Building a taxonomy: Vulnerabilities in VoIP specification, design and implementation

[Ari Takanen]

Hello all,

I have noted that people are complaining about the clarity or wording
in different security advisories released by both discoverers,
coordinators and vendors, and it is good to see that VOIPSA is
tackling this problem area with the taxonomy work. 

I have been involved or at least following the process with both VoIP
related major advisory processes by our research partner the
University of Oulu, and I do not think that the titles of these
advisories are at all misleading. I think they have carefully worded
the advisories to show that the problem is not in the protocol
specification but in the implementations or message parsing. I am sure
all CERT organizations will accept comments to the wording if you
think it could be improved. I think the biggest problem is that the
great audience does not understand the difference between various
software vulnerabilities. This promotes the need for defining the
terminology for the threats, attacks and vulnerabilities.

Looking for example at NIST/ICAT statistics:

http://icat.nist.gov/icat.cfm?function=statistics

... we can see that in the past almost all vulnerabilities are in the
implementations and not in the design or specifications. Design and
other flaws only amount to something between 28-31% of the
vulnerabilities discovered. All the other flaws are done purely by
programmers. We have been internally using a simple categorization
between flaws in 1) specification and design 2) implementation and 3)
configuration and use. ICAT statistics support this categorization and
give a good insight to this also. A more detailed division of
implementation mistakes is also in use by the ICAT, and hopefully we
can learn from that.

We still do not have any such database around VoIP, but I am sure if
someone starts collecting that data, that would be useful in showing
the validity and security of the VoIP specifications (if anyone wants
to do that as it will at the same time point out that vendors are to
blame for the flaws). Having a taxonomy and being to categorize the
found flaws in these 'boxes' not only helps the developers but also
the press in being more clear in their statements about the flaws.

There are different solutions for different flaws. PROTOS test-suite,
and also our commercial Codenomicon test-tools focus on implementation
flaws. Security scanners from other security companies focus on
configuration and maintenance flaws. And IETF torture tests touch the
topic of design flaws. Call generators focus on performance
issues. All these are needed for security assessment. But you have to
be careful again when you read and interpret the results from these
tools.

Even if our PROTOS test-suite does not find errors in the current and
latest implementation, it does not certify that the product is
flawless. Almost without exception, our customers have always found
new issues using our commercial tools. If vendors and enterprise users
only use PROTOS suite once, you will lose all the benefits that we
wanted you to have when releasing the test-suites and tools. They are
intended to provide a base-line for quality. It is also provided to
allow you to improve your quality and security assessment practices
and processes. It is not enough to do conformance testing only to test
that the product "works ok", you need robustness testing tools for
hardening the product for usage in hostile environments. Robustness
testing is one essential part in the testing process, although it also
fits well when integrated to regression testing.

I have been happy to notice that the free PROTOS test-suite has been
generally accepted by the SIP and H.323 developers, and that there is
interest in the commercial Codenomicon SIP Test Tool as well. Looking
at the Expo at VON for example, I noted that many vendors use the fact
that they have integrated our tools for marketing purposes, showing
to their customers that they have considered security also in their
product development. I think this is great! It also shows that VoIP
industry is in the position to avoid most security disclosures that
the other communication industries are still struggling with. You do
not see that many disclosures around VoIP vulnerabilities, do you? The
base-line is set, and we can focus our efforts on more complex issues.

Good links to the topics:

Test tools:
http://www.sipcenter.com/sip.nsf/html/Testing+and+Measurement
http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/
http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/h2250v4/
http://www.codenomicon.com/testtools/sip/
http://honor.icsalabs.com/pipermail/ssl-list/2003-July/000015.html

Disclosure process:
http://www.ee.oulu.fi/research/ouspg/protos/sota/FIRST1999-process/
http://www.ee.oulu.fi/research/ouspg/protos/sota/FIRST2001-disclosures/
http://www.ee.oulu.fi/research/ouspg/sage/disclosure-tracking/
http://www.ee.oulu.fi/research/ouspg/sage/liability-tracking/

I hope this was useful. Please feel free to contact me if you have any
questions or comments.

Please update your phones!

/Ari

Codenomicon is the leader in robustness testing tools for any network
protocols, founded in 2001, and with offices in Europe and USA. We
look forward to helping you in your security assessment practices.

-- 
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
Ari Takanen                       Codenomicon Ltd.
ari.takanen at codenomicon.com       Kaitovayla 1
tel: +358-40 50 67678             FIN-90570 Oulu
http://www.codenomicon.com        Finland
PGP: http://www.codenomicon.com/codenomicon-key.asc
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-