OUSPG

[This page is CSS2 enabled. Your browser might not fully support it]

PROTOS Test-Suite: c05-http-reply

$RCSfile: index.html,v $ $Revision: 1.36 $ $Date: 2001/09/05 12:55:22 $

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.

ABSTRACT

HTTP is a commonly used, ascii-based protocol providing a communication mechanism for the world wide web. A subset of the HTTP, namely HTTP-reply, was chosen as the subject protocol and software vulnerability analysis through syntax testing was conducted. A survey of the related standards was made, existing implementations were identified and targets were chosen. Test-material was prepared and tests were carried out. Results were gathered and reported. Some of the selected implementations seemed to ignore certain HTTP-headers. But the crucial ones, namely authentication headers, caused many of the implementations to fail to perform in a robust manner. Some failures had information security implications, and should be considered as vulnerabilities. To promote and support HTTP-reply implementations this test-material should be adopted in the evaluation and development of these products.

Table of Contents

• ABSTRACT
• Table of Contents
• Introduction
• Analysis
• Design
  • Standard Survey
  • Subject Survey
  • Injection Vector Survey
  • Specifications Design
  • Anomaly Design
• Injection
• Instrumentation
• Implementation
  • Results from the Test-Runs
  • Verification via Exploits
• Test-Material Package
  • Package Information
  • Licence and Copyright
  • Usage
    • Using with Java
    • Using Single Test-Cases
  • Download
• Conclusions
  • Acknowledgments
• Vulnerability Management
  • Prior Public Vulnerabilities
  • The Vulnerability Process
  • Advisories and Vendor Statements

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. Important: Background, goals, limitations, terminology and licencing 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. The subject protocol and the chosen subset of it are illustrated in the "Analysis" section below.

Analysis

"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers." [ http://www.ietf.org/rfc/rfc2616.txt]

In the initial analysis the HTTP was chosen as the focus area for this test-suite. The factors behind this selection included:

• HTTP is widely used as an underlying transport for various applications, WWW being the most notable one.
• Since HTTP is a relatively venerable protocol, we expect its implementations to behave robustly due to hardening over the years.
• The classic HTTP implementation include WWW-browsers, servers and proxies. Moreover, HTTP is penetrating mobile handsets, PDAs, appliances and is integrated in surprising places, such as multimedia tools.

The protocol suite was further narrowed down to one specific type of the protocol data units (PDUs), namely HTTP/1.1 replies. Rationale behind the selection:

• The test-cycle 05 was aimed against client side software.
• Since there is a vast number of browser installations out there, the patching may prove to be problematic. Thus systematic elimination of most trivial vulnerabilities may lessen the impact when compared to casual findings by manual testing.
• HTTP-replies arrive somewhat unaltered to browsers, only modified by proxy servers and content filters. Therefore, proxy servers should prove themselves interesting test subjects as well.
• Delivering exploits through web sites with fake meta-data indexed by search engines or through compromised servers (such Code Red victims) would propose a considerable threat to internet security.
• Earlier c04-wap-wsp-request test-suite was aimed against WAP servers. Since WAP servers must also handle HTTP-replies, they can be considered as test subjects as well.

Design

Standard Survey

The available standards specifying the selected protocol have to be studied, and analysed. The relevant protocol specifications are listed in the table below.

Subject Survey

A survey of the 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 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 pre-release phase.

A subset of the implementations was chosen to be tested during the test-suite creation and pre-release phases. After release no additional tests will be conducted.

Injection Vector Survey

The injection vector survey, or delivery vector survey, analyses the different methods of delivering the test-cases to the implementations under test (IUTs). Often, there are several methods of injection and the test-suite cannot cover them all, or might miss some vectors not available in all implementations.

The only delivery vector in this context turned out to be the replies from a TCP based server.

Specifications Design

Protocol 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 developed in this project uses a custom dialect of BNF (Backus-Naur Form). The BNF is capable of describing context-free syntax of a specification, but is not usually enough for the PDU generation. The specification is completed by some semantic extensions in BNF and embedded Java-coded functions.

The augmented BNF (ABNF) based protocol specification from the latest HTTP/1.1 RFC was adopted. This specification was then converted to our dialect of BNF.

NOTE: The expiration date in the Set-Cookie header was defined as "Monday, 03-Jan-02 12:12:12 GMT". This may cause a date dependency on the behaviour caused by the test-material.

Anomaly Design

Anomalies are the changes in the normal communication packets, which might cause undesired effects in the implementations. Some of the anomalous cases are not malformed but follow the specification, yet they might still be inputs that have not been considered when implementing the software. The design of anomalous test-cases is done with the test-tool configuration files. These anomalies aim to reveal the undesired behaviour and do not contain any vulnerability exploits running arbitrary code on the tested implementations, even where it would be possible.

The following anomaly types were integrated:

Here is a table summarising the combinations (selections of anomalies applied to specific portion of the PDU in question) and anomaly categories used in each of them:

Injection

The injectors implement the chosen delivery vector. Suitable injectors already integrated in the test-tool framework were reused. In this test-suite HTTP-replies were injected over TCP.

Several approaches were considered to reduce the manual labour in fetching all the test-material for processing in the browser software.

• HTTP layer directives such as redirections to the location of the next test-case, would have limited the test design.
• Content level refresh directives did not turn out to be a viable solution. This was due to intentionally corrupt HTTP replies preventing content based control of case retrieval.
• A HTML frame based approach was attempted, with a primary frame forcing the HTTP retrieval for the secondary frame. This worked better than the first option, but failed to carry out automatic retrieval of the entire material.
• At the end, for browser software, we applied custom test-automation to force restart of the subject after each test-case. Test-case retrieval was initiated either through default home-page setting or command line option for the start-up URL. Unfortunately, this prevented us from discovering failures caused by combinations of test-cases.
• Of course, those who are not afraid of a strain injury, may conduct the test-runs with persistent clicking of the refresh button or alike.

Instrumentation

With instrumentation on the target platform we are able to monitor for undesired behavior of the subject implementation. Typically this manifests as exceptions or signals such 'access violation' and 'segmentation fault'.

No instrumentation will be bundled with this test-suite release. Observing any undesired behavior relies solely on the tools and logging provided by the target platform. 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.

Implementation

Test-runs were conducted against the chosen subject implementations. Packet specifications, desired anomalies, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests.

Results from the Test-Runs

The results of the test-runs, derived from the test-logs, are presented in the table below. Product names of the actual subjects are omitted to protect the innocent. Observed failures are presented in a tabular form with test-cases divided into test-groups based on the anomaly types utilised and PDU fields under examination.

Legend:

• nnn: Each different test-run (tr-nnn) represents a different tested implementation.
• X: Verdict is failed - direct crash
• U: Verdict is failed - user interaction was required to expose the crash
• P: Verdict is failed - crash when configured to use a proxy server
• -: Verdict is pass - no abnormal behaviour observed

The test results are further summarised in the table below.

Each fail verdict is due to an exception, signal or unexpected exit. Each of them represents a minimum of a denial of service type vulnerability. In most cases they represent memory corruption, stack corruption or other fatal error condition. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.

The sampled proxies (5) and the command line tool (1) were found to be robust. However, apparently more complex GUI-based browsers (6) failed systematically. For the browsers, subject behaviour varied depending on whether they were configured to use a proxy server. Much to our surprise, after configuring the browsers to use a proxy server, we observed more anomalous behaviour.

Verification via Exploits

To 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. The simplest of them only executes some harmless commands in the target system, typically with the privileges of the vulnerable process although any arbitrary code could be executed. 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:

• Buffer overflow exploits allowing execution of arbitrary code were demonstrated for two graphical browsers. One of them being traditional main-stream browser and another one being a micro-browser.
• Denial of service exploits was demonstrated for the four remaining graphical browsers included in the subject sample. They all inhibited register corruption, heap corruption or referring illegal memory addresses. Further exploitability of these particular flaws was not demonstrated.

Test-Material Package

Package Information

Test-material is distributed as a JAR-package. This package comprises of the following elements:

• Total of 3966 test-cases (PDUs), located in testcases/ directory
• Java code (source and compiled) for feeding the test-cases against the system under test.
• LICENSE.TXT - GNU General Public License (GPL) version 2.
• README.TXT - Very short instructions.

Licence and Copyright

The 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.

Usage

A prerequisite for using the test-material is an implementation that handles HTTP-replies and preferably an isolated network. The test-material will act as a simple HTTP-server, injecting a test-case each time it is connected and a request of any kind is received.

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 Java

Java Runtime is a prerequisite for running the bundled Java code. [http://java.sun.com] This package has been tested on Java 2 Platform, Standard Edition (J2SE). [http://java.sun.com/j2se/1.3/].

Usage examples for the injection code bundled in the JAR-package:

java -jar c05-http-reply-r1 -help

This command displays the built-in help for the available command line options. Options such as selecting a specific range of test-cases or non-default port are high-lighted therein.

java -jar c05-http-reply-r1.jar -single <index>

Serve a single test-case (index) on the default port (8000).

java -jar c05-http-reply-r1.jar

Serve all test-cases, one by one, on the default port (8000).

Using Single Test-Cases

The 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.

Download

• c05-http-reply-r1.jar - Test-material pre-release v1,
• c05-http-reply-r1.jar.asc - Detached PGP signature

Conclusions

The initial results from the c05-http-reply tests indicate that implementation errors are present in several products handling HTTP-replies. Certain errors and vulnerabilities were discovered only after a careful inspection in a debugger because of the exception masking and fuzzy error modes.

The sampled proxies and the command line tool were found to be robust. However, apparently the more complex GUI based browsers failed systematically.

Some implementations seemed to ignore certain parts of HTTP-reply messages but failed when for example anomalous authentication headers were encountered. We find it rather ironic that the least robust (read most vulnerable) part, ie. the death zone, was to be related to the authentication. Authentication is a security related feature, and especially the digest authentication was supposed to be a security improvement brought to us by the HTTP/1.1 specification.

The impact of the discovered vulnerabilities is escalated by the fact that many email user agents are willing to automatically pursue embedded references via HTTP. On the other hand, if the observed failures are not exploitable beyond denial of service of client software then impact may remain at annoyance level. Nevertheless, any undesired behaviour exposed by this test-material are due to errors that should be weeded out.

Acknowledgments

We wish to express our gratitude to individual vendors who worked with us to protect their customers. We are grateful to AusCERT for their help and advice during the vulnerability process.

Vulnerability Management

Prior Public Vulnerabilities

The 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.

Search for already known and relevant vulnerabilities in HTTP reply handling provided no further insight for the test-design.

The Vulnerability Process

During the pre-release phase all verified vulnerabilities are reported to the respective vendors. The vulnerability reports are tracked by the AusCERT in role of an independent coordinator and advisor. A grace period of three months was kept between the vendor notification and public release.

Advisories and Vendor Statements

Vendor 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:

• None as of 2001-09-05

As of 5th of September we were aware of that one out of five vendors involved has addressed the demonstrated exploitable condition brought up by this test-suite with fixed build of the specific version of their product. Another vendor has indicated that issues brought up by this test-material will be fixed in the future build of their products, but denied the exploitability of the issues.

[This page is CSS2 enabled. Your browser might not fully support it]