|
|
|
|
|
|
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-h2250v4$RCSfile: index.html,v $ $Revision: 1.38 $ $Date: 2004/11/10 10:02:50 $ 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. ABSTRACTH.323 is a collection of protocols and other standards which together enable conferencing over packet-based networks. H.323 is embraced by major vendors and implementations range from desktop applications to heavy-duty and industrial-grade gateways. A subset of H.323, H.225.0, was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. The scope was further narrowed down to the initial call setup message. 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 H.323 products this test-material should be adopted for their evaluation and development. Table of Contents
IntroductionThis test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. [1] This test-suite covers a limited set of information security and robustness related implementation errors within the chosen focus area. 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.
"H.323 is the international standard and the market leader for IP Telephony. H.323 networks in production today carrying hundreds of millions (perhaps billions) of minutes per month. H.323 has proven to be an extremely scalable solution that meets the needs of both service providers and enterprises, with H.323 products ranging from stacks and chips to wireless phones and video conferencing hardware." - H.323 Information Site [2] The purpose of this test-suite is to evaluate implementation level security and robustness of H.225.0 implementations. H.225.0 is a protocol responsible for signalling and setting up H.323 calls. The factors behind choosing H.225.0 included:
The scope of the test-suite was narrowed to H.225.0 version 4 Setup-PDU. Rationale behind this selection was:
Test-Suite DesignStandard SurveyRecommendation H.323 defines a collection of protocols and standards which together enable conferencing over packet-based networks (such as IP networks). [3] Of these standards, the following ones must be supported by H.323 endpoint implementations:
H.225.0 stands for Call signalling protocols and media stream packetisation for packet-based multimedia communication systems. [4]
"Call signaling is a basic requirement needed to set up and tear down a call between two endpoints. H.225.0 uses a subset of Q.931 signaling protocol for this purpose. Q.931 was initially developed for signaling in integrated services digital networks (ISDN). H.225.0 adopts Q.931 signaling by incorporating it in its message format. H.225.0 call signaling is sent directly between the endpoints when no gatekeeper exist. When a gatekeeper exists then it may be routed through the gatekeeper." - H.323 and Associated Protocols by Asim Karim [5] The available standards specifying H.225.0 were studied and analysed. The relevant specifications are listed below.
Subject SurveyA survey of available implementations is 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 on the impact of potential vulnerabilities. A subset of the implementations is chosen to be tested during the test-suite creation and prerelease phases. Typically, not all implementations are available for testing. The H.323 recommendation describes the components of an H.323 system. [3] The relations of H.323 entities are illustrated in the figure below. The components within the scope of this test-suite, ones that have to parse H.225.0 Setup-PDUs, are marked with asterisks (*). A single implementation may encompass several entity types. ![[ER Diagram of H.323 Entities]](h323-entities.erd.gif)
Figure: ER Diagram of H.323 Entities
No sample list of implementations is presented herein. H.323 is embraced by major vendors and implementations range from desktop applications to heavy-duty and industrial-grade gateways. A list of vendors with H.323 enabled products may include at least: ASUS, Avaya, Checkpoint, Cisco Systems, CUSeeMe, Ericsson, Hitachi, Hughes Software Systems, IBM, Intel, LG Electronics Inc., Lotus, Lucent, Microsoft, Motorola, Netergy Networks, Nortel, OpenH323, RADVISION, Siemens, SONY, VCON, VTEL and Zydacron. 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.
Although H.225.0 call signalling channel may be implemented on top of UDP, all relevant entities must support signalling over TCP port 1720 [4]. Moreover, use of TCP simplifies call tear-down and thus was a logical choice of transport for this test-suite. 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. The H.225.0 Setup-PDU can be divided in three logical parts:
Although this separation is somewhat artificial, it makes the test-suite documentation easier to follow. In reality, all three parts are sent in single H.225.0 Setup packet. The following table describes the choices made and default values defined for the TPKT part of the Setup-PDU in this test-material.
Legend for the second column:
The following table describes the choices made and default values defined for the Q.931 part of the Setup-PDU in this test-material.
Legend: [see first elements table above] The following table describes the choices made and default values defined for the User-information element part of the Setup-PDU in this test-material. Due to vast amount of ASN.1 definitions and their possible combinations only the elements always present are listed.
Legend: [see first elements table above] Erratum: Choice of the default value of "12345678" for telephone numbers may not turn out to be the wisest one. For future iterations of this test-material E.164 numbering scheme should be studied for numbers reserved for test purposes. 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 few 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 4497 test messages are presented in the three tables below. Test-groups have been arranged in three collections based on the protocol abstraction that they focus on.
Legend:
Legend: [see first test-group table above]
Legend: [see first test-group table above] 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. H.225.0-Setup PDUs can be injected using a simple TCP injector. A TCP-session will be established for each test-case. Session tear-down assumes that implementations terminate the call (test-case) when the associated TCP-session is closed. 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. The valid-case was designed as a conforming Setup message. In normal call initiation process this message should result in Call Proceeding, Alerting and eventually Connect replies from the communication peers. Only reception of any single reply is instrumented and required for successful continuation of a test-run. 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. The verdict failed is granted if any of the following criteria is met and a single test-case can be identified to be responsible:
If no single test-case can be identified but similar effects are observed, the verdict 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 verdict is passed.
Legend:
Legend: [see first result table above]
Legend: [see first result table above] Please note that if a subject fails in a format string (fmtstring) test-group, the failure may be triggered by a very long format string causing an overflow condition. Should implementation have failed format string category, but not previous overflow category, then implementation is more or very likely to contain real format string type of vulnerability. 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. Test-Material PackagePackage InformationTest-material is distributed as a JAR-package. The package comprises of the following elements:
Licence and CopyrightThe test-material is licenced 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 gateways 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 without Java]. 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. [13] Usage examples for the injection code bundled in the JAR packages:
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. DownloadUse of latest release (highest number) is recommended. Older releases are provided for completeness and reproduction. Release 2Release 2 fixes the test material release 1 errata.
Release 1Erratum: See see Appendix A for description of missing ASN.1 extension marker bug in the Release 1.
NotesInstrumenting via --validcase command line argument may not work with all subject implementations due to conflicting interpretation of the specifications. However, instrumenting via ability to establish subsequent sessions should provide comparable results. We observed an injector deadlock condition when using J2SE (build 1.4.0-b92) JVM on a multiprocessor machine, with minimal delays and when the injection target was on a loop-back device. However, this condition was not observed on any other platform nor with default delay values. If a test-run is aborted and resumed without resetting the subject software, call identifier information hard-coded within the test-cases may appear recycled and may cause cases being rejected as existing sessions. However, it should be safe to assume that sane implementations do not associate calls beyond lifetime of the TCP session. ConclusionsAlthough this test-suite only scratches the surface of the complex H.323 family of protocols, the failure rate was alarming. 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 H.323 products this test-material should be adopted for their evaluation and development. AcknowledgementsWe wish to express our gratitude to individual vendors who worked with us to protect their customers. We are in debt to Sonera Corporation for providing us facilities and support in determing the impact of the test-suite. We thank OSS Nokalva for pointing out a PER encoding bug which led to the discovery of a missing extension marker in the pr1 and subsequent r1 versions of the test-material. Last, but not least, we are grateful to NISCC 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. Following prior vulnerabilities were identified as H.323 related:
These vulnerabilities were considered during the test-suite design, but reproducibility with this test-material was not verified. During the pre-release phase, additional vulnerabilities were identified:
The Vulnerability ProcessDuring the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports were tracked by the NISCC in role of an independent coordinator and advisor. [17] 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 approximately 12 months was kept between the initial vendor notification and public release. After the announcement of NISCC vulnerability advisory, an additional two-week delay was held before releasing this test-suite. 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: Release ErrataErratum: In pr1 version of test-material the TCP socket was not drained of incoming data before closing. This might have caused the test program to terminate the TCP connection prematurely by sending an RST packet (instead of FIN). A workaround was implemented in r1 version. The workaround may cause following error messages, which in most cases can be ignored: #0: Connect success. #0: Injecting test case, 226 bytes. #0: Waiting 100 ms for reply...42 bytes received #0: Waiting 50 ms before closing connection. #0: ERROR: Stream closed. #1: Connect success. #1: Injecting test case, 0 bytes. #1: Waiting 100 ms for reply...0 bytes received #1: Waiting 50 ms before closing connection. #1: ERROR: Stream closed. Using --oldtcp switch will get rid of those ERRORs, but you might miss some data sent by the subject. Erratum: In pr1 version of test-material an ASN.1 extension marker was missing in ClearToken specification causing one byte to be left out in certain test-cases. In test-case data, this resulted to zero length (empty) tokenOIDs instead of intended ones (0.0). This bug was fixed in test-material version r2. Original pre-release version 1 has been released as release version 1 for reproduction of the presented results. For description of the error, see below.
Here is the test case 1742 decoded by Ethereal 0.9.3 with H.323 plugin
in which I made some markings ("****************"). In the
hexdump, TPKT starts at offset 0x36, Q.931 at 0x3a and User-to-user at
0x55.
[snip]
TPKT
Version: 3
Reserved: 0
Length: 223
Q.931
Protocol discriminator: Q.931
Call reference value length: 2
Call reference value: 06CE
Message type: SETUP (0x05)
Bearer capability
Information element: Bearer capability
Length: 3
Coding standard: ITU-T standardized coding
Information transfer capability: Speech
Transfer mode: Circuit mode
Information transfer rate: 64 kbit/s
User information layer 1 protocol: Recommendation G.711 A-law
Display
Information element: Display
Length: 15
Display information: test-case 1742\000
User-user
Information element: User-user
Length: 189
Protocol discriminator: X.208 and X.209 coded user information
ITU-T Recommendation H.225.0
h323_uu_pdu (H323-UU-PDU)
h323_message_body (setup)
setup
protocolIdentifier: 0.0 **************** (1)
sourceAddress (AliasAddress)
Item 0 (h323_ID)
h323_ID: c07-h2250v4
sourceInfo (EndpointType)
vendor (VendorIdentifier)
vendor (H221NonStandard)
t35CountryCode: 60
t35Extension: 0
manufacturerCode: 61
productId: c07-h2250v4 test-suite
versionId: 1.0
terminal (TerminalInfo)
mc: False
undefinedNode: False
destinationAddress (AliasAddress)
Item 0 (h323_ID)
h323_ID: c07-h2250v4
destCallSignalAddress (ipAddress)
ipAddress
ip: 127.0.0.1 (127.0.0.1)
port: 1720
activeMC: False
conferenceID: 676C6F62-616C-6C79-2D75-6E69712D06CE
conferenceGoal (create)
create: create
callType (pointToPoint)
pointToPoint: pointToPoint
sourceCallSignalAddress (ipAddress)
ipAddress
ip: 127.0.0.1 (127.0.0.1)
port: 1720
remoteExtensionAddress (h323_ID)
h323_ID: c07-h2250v4
callIdentifier (CallIdentifier)
guid: 676C6F62-616C-6C79-2D75-6E69712D06CE
tokens (ClearToken)
Item 0 (H235-ClearToken)
tokenOID: **************** (2)
mediaWaitForConnect: False
canOverlapSend: False
multipleCalls: False
maintainConnection: False
h245Tunneling: False
0030 fa f0 86 74 00 00 03 00 00 df 08 02 06 ce 05 04 ...t............
0040 03 80 90 a3 28 0f 74 65 73 74 2d 63 61 73 65 20 ....(.test-case
0050 31 37 34 32 00 7e 00 bd 05 20 b8 01 00 01 40 0a 1742.~... ....@.
0060 00 63 00 30 00 37 00 2d 00 68 00 32 00 32 00 35 .c.0.7.-.h.2.2.5
0070 00 30 00 76 00 34 22 c0 3c 00 00 3d 17 63 30 37 .0.v.4".<..=.c07
0080 2d 68 32 32 35 30 76 34 20 74 65 73 74 2d 73 75 -h2250v4 test-su
0090 69 74 65 00 00 04 31 2e 30 00 00 00 01 40 0a 00 ite...1.0....@..
00a0 63 00 30 00 37 00 2d 00 68 00 32 00 32 00 35 00 c.0.7.-.h.2.2.5.
00b0 30 00 76 00 34 00 7f 00 00 01 06 b8 00 67 6c 6f 0.v.4........glo
00c0 62 61 6c 6c 79 2d 75 6e 69 71 2d 06 ce 00 5f 4d bally-uniq-..._M
00d0 80 07 00 7f 00 00 01 06 b8 18 40 0a 00 63 00 30 ..........@..c.0
00e0 00 37 00 2d 00 68 00 32 00 32 00 35 00 30 00 76 .7.-.h.2.2.5.0.v
00f0 00 34 11 00 67 6c 6f 62 61 6c 6c 79 2d 75 6e 69 .4..globally-uni
0100 71 2d 06 ce 04 01 00 01 00 01 00 01 00 01 00 01 q-..............
0110 00 02 80 01 00 .....
[snap]
In this test-case the Protocol identifier OID is somewhat exceptional:
protocolIdentifier: 0.0 **************** (1)
This OID encodes as: 0x01 0x00 (length, {0.0} becomes 0x00) and can be
found at offsets 0x5b-0x5c
Then there is the tokenOID:
tokens (ClearToken)
Item 0 (H235-ClearToken)
tokenOID: **************** (2)
TokenOID should also be {0.0} (encoded as 0x01 0x00) similar to the
protocol identifier OID. The specs say the following.
- From H.225.0v4 ASN.1 specs:
[snip]
tokens SEQUENCE OF ClearToken OPTIONAL,
[snap]
In H.323v3 implementors' guide they included the tokenOID in
the ClearToken structure (which was defined in H.235):
[snip]
ClearToken ::= SEQUENCE -- a `token' may contain multiple value types.
{
tokenOID OBJECT IDENTIFIER,
timeStamp TimeStamp OPTIONAL,
password Password OPTIONAL,
dhkey DHset OPTIONAL,
challenge ChallengeString OPTIONAL,
random RandomVal OPTIONAL,
certificate TypedCertificate OPTIONAL,
generalID Identifier OPTIONAL,
nonStandard NonStandardParameter OPTIONAL,
. . .
}
-- An object identifier should be placed in the tokenOID field when a
-- ClearToken is included directly in a message (as opposed to being
-- encrypted). In all other cases, an application should use the
-- object identifier { 0 0 } to indicate that the tokenOID value is
-- not present.
[snap]
tokens (ClearToken)
Item 0 (H235-ClearToken)
tokenOID: **************** (2)
So this is encoded in offsets 0x104-0x108:
0x04 0x01 0x00 0x01 0x00
0x04: open type length
0x01: SEQUENCE-OF count, one ClearToken
0x00: SEQUENCE bitfield, zero optional elements present
0x01: length of tokenOID
0x00: tokenOID {0.0}
This is wrong. It took me a while but I found the problem. It was in
the encoding of the SEQUENCE. As you see above, ClearToken has 8
optional elements and an extension marker. In PER the basic encoding
for sequence is a preamble bitfield which has one bit for each
optional element PLUS one bit for extension marker... Well guess who
had left out the extension bit? :D
8 elements + extension bit = 9 bits. Then we need 7 bit padding before
OID encoding and it all becomes like this:
0x05 0x01 0x00 0x00 0x01 0x00
So it was not a zero length OID, it was a wrongly encoded SEQUENCE
bitfield... Will be corrected for the next (pre)release. I guess I had
just bypassed the missing OID in the Ethereal output because if you
clicked on it it highlighted "0x01 0x00" in the hexdump -- a correctly
encoded OID {0.0} :)
Can you believe it? All this hassle was caused by just one bit :)
[This page is CSS2 enabled. Your browser might not fully support it] |