|
|
|
|
|
|
Faculty of Technology > Electrical and Information Engineering > Computer Engineering Laboratory
|
|
OUSPG[This page is CSS2 enabled. Your browser might not fully support it] PROTOS Test-Suite: c07-sip$RCSfile: index.html,v $ $Revision: 1.77 $ $Date: 2006/11/14 15:55:13 $ Permission is hereby granted for quoting, reprinting and redistributing this document, provided that a link to this document is given, and all changes made are clearly separated from the original text. ABSTRACTThe Session Initiation Protocol (SIP) is a signalling protocol for Internet telephony, instant messaging and alike. Although SIP implementations have not yet been widely deployed, the product portfolio is expanding rapidly. A subset of SIP, namely INVITE messages, was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. A survey of the related standards was made. Test-material was prepared and tests were carried out against a sample set of existing implementations. Results were gathered and reported. Many of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. In order to achieve a robustness baseline for SIP products this test-material should be adopted for their evaluation and development. A more comprehensive test-suite should be developed as the SIP scene matures. Table of Contents
PresentationThe presentation at the "VOICE OVER IP SECURITY WORKSHOP" is available. 2005-06-02VoIPSecWs.pdf IntroductionThis test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project and has been funded and supported by "Red Skins" project. [1] [2] Important: Background, goals, limitations, terminology and licensing for this test-suite release are explained in the "Test-suite releases in Theory and Practice" document. This test-suite covers a limited set of information security and robustness related implementation errors for a subset of the chosen protocol.
"SIP, the Session Initiation Protocol, is a signaling protocol for Internet conferencing, telephony, presence, events notification and instant messaging. SIP was developed within the IETF MMUSIC (Multiparty Multimedia Session Control) working group, with work proceeding since September 1999 in the IETF SIP working group." - Columbia University SIP site [3] The purpose of this test-suite is to evaluate implementation level security and robustness of Session Initiation Protocol (SIP) implementations. The factors behind choosing SIP included:
In this test-suite, the focus was set on a specific protocol data unit (PDU), namely INVITE message. Rationale behind this selection was:
The SIP Center list of pre-existing test-suites was reviewed. [5] One test-suite, TTsuite-SIP, missing from the SIP Center list was noted. [6] The test-suites identified above focused on conformance and performance, with no or only some syntax testing material. However, an Internet Draft by SIPPING Working Group contains examples of test messages designed to torture a SIP parser. [7] This test-suite aims to complement the torture material presented in the draft. Test-Suite DesignStandard Survey
"SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. ... SIP is a text-based protocol and uses the UTF-8 charset ... A SIP message is either a request from a client to a server, or a response from a server to a client. ... Session Description Protocol (SDP) ... for describing multimedia sessions." - RFC3261 [8] The available standards specifying the selected protocol were studied and analysed. The relevant protocol specifications are listed below:
Subject SurveyA survey of available implementations was conducted. This should include a diverse selection of implementations in order to gain a better insight into the applications implementing the protocol, and to give a hint of the impact of the potential vulnerabilities. Typically, not all implementations are available for testing, and thus cannot be tested by the project personnel within this test-suite prerelease phase. RFC3261 identifies several types of SIP entities: [8]
From perspective of this test-suite and keeping in mind the initial focus on INVITE messages, focus will be on products implementing User Agent Server or Proxy functionality. No sample list of implementations is presented herein. A growing number of vendors include SIP support in their products. A list of vendors with SIP enabled products may include at least: 3Com, Alcatel, Avaz, Cisco, Columbia University, dissipate, dynamicsoft, eStara, GMD Fokus, Hewlett Packard, Hotsip, Hughes Software Systems, Icecom, Indigo, Interactive Intelligence, iptel.org, KPhone, Komodo, Mediatrix, Meetinghouse Data Communications, MicroAppliances, Microsoft, Mistral, Motorola, Netscreen, Nortel, Nuera, ObjectSoftware, partysip, Pingtel, SIPHON, Siemens, Sonus Networks, T&S Software, Terminal Technologies, UCL, Ubiquity, Vegastream and Vovida.org. Additional lists of vendors, specific implementations and related information may be found from the following resources: A subset of the implementations was chosen as a sample set to be tested during the test-suite creation and pre-release phases. Most likely reasons for omission of a specific product from the sample set include:
Injection Vector SurveyIn injection vector survey, different methods of delivering the test cases to the implementations under test are identified and analysed. Often, there are several injection methods and one test-suite cannot cover them all, or might miss some vectors not available in all implementations.
All SIP elements must implement UDP and TCP transports, and in case of UDP the processing of multi-cast (including broadcast) requests is supported. [8] This test-suite was developed for SIP over UDP, although delivery over TCP would simplify the session tear-down after each test-case. Preference was given to the UDP due to earlier versions of the SIP specifications requiring UDP support and leaving TCP support optional. Consequently not all implementations available to us supported SIP over TCP. Specifications DesignProtocol data unit specifications are used as a basis for generating the test-cases. Starting point for the design of the test-suite is to acquire or create a machine-readable representation of the protocol specification. The test-tool in use utilises a custom dialect of BNF (Backus-Naur Form). BNF is capable of describing the context-free syntax of a specification, but is often insufficient for automated test-case generation. The specification is completed by rules which maintain semantic validity and provide communication channels necessary to simulate the protocol. An example of a valid and typical SIP/SDP message that the protocol grammar should be able to generate is given below: [11]
INVITE sip:UserB@biloxi.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: BigGuy <sip:UserA@atlanta.com>;tag=9fxced76sl
To: LittleGuy <sip:UserB@biloxi.com>
Call-ID: 3848276298220188511@atlanta.com
CSeq: 1 INVITE
Contact: <sip:UserA@client.atlanta.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 143
v=0
o=UserA 2890844526 2890844526 IN IP4 client.atlanta.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Design of Exceptional ElementsAn exceptional element is a piece of data designed to provoke undesired behaviour of the test subject. A single test-case contains one or more exceptional elements. An exceptional element can violate the protocol specification, but often it is legal or in the hazy region between legal and illegal constructs. In a nutshell, an exceptional element is an input that might not have been considered properly when implementing the software. The following table lists the categories of the exceptional elements designed for the test-material:
Design of Test-MaterialThe test-material consists of test-cases simulating hostile input to the implementation under test. A test-case contains one or more exceptional elements, other elements being in their default state. Cases are arranged into test-groups, each covering a certain part of the PDU or similar anomalies. Details for the package of 4527 SIP INVITE test messages are presented below.
Legend:
Test-material was designed to exercise the SIP headers, their fields and their delimiters in isolation (one-by-one). Neither structural anomalies nor combinations of anomalous entries within a single test-case were included. Erratum: The test-group SDP-Time-Stop is a misnomer. Although the group is named to reflect SDP stop time within the time field, the empty exceptional element is applied to whole time field, including start time. ImplementationTest-runs were conducted against the chosen sample of implementations. Specifications, exceptional elements, semantic rules, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests. InjectionThe test-tool provides communication rules for test-case injection. SIP PDUs were chosen to be injected using a simple UDP injector. Further requirements for the injection code were raised by combination of having to adopt UDP for injection and including SIP terminals (user agents) as test subjects. Connection teardown, ie. cancelling previous INVITE requests, had to be implemented for test automation. Otherwise test execution against terminals would have required manual intervention to terminate incoming calls from each test-case. The connection teardown was implemented by embedding a teardown template with identifiers within each test-case, and by applying that template to generate a sequence of CANCEL and ACK messages (see Appendix A). At least one significant implementation failed to conform to the specification in delivering responses to SIP requests. The implementation in question delivered replies to default port for the transport instead of correct behaviour of replying to Via sent-by declared port. Thus, injector code was designed to expect replies on the default port unless otherwise configured. Erratum: The test-case design does not account for maximum payload limitations of used transport (64 KBytes minus headers on UDP). Thus, almost each group contains a test-case that is silently truncated to a configurable limit. This behaviour may distort the interpretation of test-results, ie. some of observed failures may result from inability to handle truncated packets rather than what is indicated by applied exceptional element or by exercised field. InstrumentationThe implementation under test is monitored for undesired behaviour that could have security implications. Instrumentation methods can roughly be divided to two categories. Out-of-Band Instrumentation on the target platform includes debuggers, resource monitoring or custom made tools used to extract information from the implementation under test. Unfortunately, the modern trend of abusing the try-catch -type of constructs easily masks the exceptions generated by stack and memory corruption. Catching these hidden exceptions relies on the debugging skills of the developers themselves. This is often the preferred form of instrumentation. In In-Band Instrumentation the implementation is monitored via the injection vector, ie. the same interface used to deliver the test-cases. While not checked for protocol conformance, absent or malformed responses can often reveal anomalous conditions such as denial of service. Also, ability to accept subsequent test-cases is a straightforward indicator of the performance on the previous test-case. Especially with embedded devices, this form of instrumentation may be the only option easily available. Valid-case instrumentation will be bundled with this test-material. In this rather crude method for in-band instrumentation, a valid PDU (valid-case) that should result in a valid reply is sent to the subject between real test-cases until a response is received. Hence, if no response from the subject is detected, it has failed. This method is especially convenient when testing black-box hardware implementations. ResultsResults from the test-runs are summarised herein. Tables below represent the observations from feeding the test-material against the chosen subject software. Product names of the actual subjects are omitted to protect the innocent. Results are presented in a tabular form with test-cases divided into test-groups based on the exceptional element types utilised and PDU fields under examination. Each failed test-case represents at minimum a denial of service type chance of exploiting the found vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error conditions. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system. In this test-suite, the failed status is granted if any of the following criteria are met and a single test-case or linear sequence of cases can be identified to be responsible for it:
If no single test-case can be identified but similar effects are observed, the status is inconclusive. Sometimes, a subject gets corrupted so badly or is fundamentally so unstable that there is no way to collect accurate test-results for the whole test-run. Untested regions are marked as unknown. Otherwise, the status is passed.
Legend:
Subjects failing in majority of test-groups are likely to have a higher level problem in input parsing instead of separate bugs for handling each header and field. Test-runs from tr-001 to tr-006 represent user agent implementations and from tr-007 to tr-009 represent proxy implementations. The results are further summarised in the table below.
Legend:
Verification via ExploitsTo support the vulnerability reporting process, typically one exploit per implementation is refined and included in the respective vulnerability report. The exploit is only intended for demonstration purposes and is harmless as it is. Simplest of them only executes some harmless commands in the target system, typically with the privileges of the vulnerable process. Some only provide a demonstration by causing a Denial of Service (DoS) against the software. To support the vulnerability reports to the respective vendors, following exploits were developed:
Test-Material PackagePackage InformationThe test-material is distributed as a JAR-package. The package comprises of the following elements:
Licence and CopyrightThe test-material is licensed under GNU General Public License (GPL) version 2, at no charge. This is done in order to ensure that vendors and their customers may freely utilise the test-material. Standard GPL terms for no warranty and no liability apply. We recommend some additional guidelines, although these do not restrict the test-material licence. These guidelines can be found from the "test-suite releases in Theory and Practice" document. UsageA prerequisite for using the test-material is a properly configured and started application, preferably not in an open network. Please heed that if PSTN connected SIP proxies are tested, the test-cases may cross network boundaries. The test-material can be used either with the bundled injection code [Using with Java] or with an external injector [Using single test-cases]. Using with JavaJava Runtime is a prerequisite for running the bundled Java code. This package has been tested on Java 2 Platform, Standard Edition (J2SE) version 1.4. [14] Usage examples for the injection code bundled in the JAR package:
Note: Users reported injector failures, typically in a *nix operating system. This condition could be resolved by stetting the environment variable to: LANG=C. Using without JavaThe test-cases (PDUs) are in raw binary format and can be used by any suitable delivery software, such as nc (netcat). The individual test-cases can be extracted from the JAR-package with tools such as unzip, winzip or jar. Refer to the manual pages and product documentation of the respective tools for additional information. In order to support orderly session teardown, a single test-case file consists of two PDUs, namely an INVITE and a teardown template for CANCEL and corresponding ACK. In order to support configurable identifiers such as from and to addresses and resulting variations in content length, the test-cases have tags in form of '<tag-name>'. Thus, before raw injection outside the bundled Java code the test-case file has to be preprocessed to substitute tags with desired values and to split the different PDU types apart. These PDUs are stored in the test-case file in the following format:
DownloadUse of latest release (highest number) is recommended. Older releases are provided for completeness and reproduction. Release 2Release 2 fixes the test material to provide unique branch identifier during the test case injection from the JAR-package.
Release 1Erratum: Release 1 does not vary branch identifier when repeating valid cases, this may cause implementations not to respond to valid cases repeated for instrumentation purposes.
NotesSome implementations may fail to response promptly when default or more aggressive delays are used, resulting in a denial of service type situation. In these cases more meaningful result collection requires increased delays (configurable via command line options). If a test-run is aborted and resumed without resetting the subject software, it may be necessary to use -callid argument of the injector with an unique number greater than the highest one used in the previous runs. This is necessary to prevent new test-cases from being rejected as existing sessions. On some systems the injector is aborting with the following message: java.lang.RuntimeException: Internal error, invalid test case file 'testcases/xxx' setting the environment variable LANG to C is correcting the issue. ConclusionsAlthough the test-material was designed as simple exercise of headers and fields in isolation, the failure rate was alarming. Only one from the sample of nine implementations survived the test-material as it is. This calls for a more comprehensive test-suite to be developed as the SIP scene matures. AcknowledgementsWe wish to express our gratitude to individual vendors who worked with us to protect their customers. Last, but not least, we are grateful to CERT/CC for their patient help, advice and active role during the vulnerability process. Vulnerability ManagementPrior Public VulnerabilitiesThe most common sources for vulnerability information and exploits were covered and cross checked for potential and already known vulnerabilities in the implementations of the chosen protocol. Typical sources for finding out about existing vulnerabilities are databases and mailing-lists. Search-engines may also reveal information on past vulnerabilities. By searching through above sources, some SIP implementation related vulnerabilities were found. However, none of them were directly related to the SIP protocol itself. The Vulnerability ProcessDuring the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports were tracked by the CERT/CC in role of an independent coordinator and advisor. [15] An attempt was made to seek a channel to distribute the test material to vendors whose products we were not able to obtain for testing. A grace period of over 90 days was kept between the vendor notification and public release. At the end of the test-suite development phase, one of our researchers was kindly received at the SIPit11 inter-operability event in Atlanta (USA) and had an opportunity to refine the test-material and discuss the vulnerability process with the other participants. Advisories and Vendor StatementsVendor statements or security advisories issued in order to address the vulnerabilities uncovered by this test-suite are collected. Advisories that we are aware of are listed here-in:
References
Appendix A: Injection with Connection Teardown
[This page is CSS2 enabled. Your browser might not fully support it] |