Oulun yliopisto - Etusivulle University of Oulu in English

ee.oulu.fi

Electrical and Information Engineering

University of Oulu > Faculty of Technology > Electrical and Information Engineering


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

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.

standard-survey
Name Document Date Organization Status Link Description
rfc1945 May 96 IETF/NWG Obsolete RFC (link) HTTP/1.0 specs
rfc2068 Jan 97 IETF/NWG Obsolete RFC (link) HTTP/1.1 specs
rfc2616 Jun 99 IETF/NWG RFC (link) HTTP/1.1 specs
rfc2617 Jun 99 IETF/NWG RFC (link) Basic and Digest Access Authentication

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.

subject-survey
Subject name Type License Platform Link
Microsoft Internet Explorer 5.5 Browser commercial Win32 (link)
Netscape Communicator 4.75 Browser commercial Win32 (link)
wget HTTP-client GPL Unix (link)
Opera 4.02 Browser commercial Win32 (link)
Nokia Communicator Mobile Phone commercial HW (link)
Microsoft Mobile Explorer (emulator) Browser commercial Benefon Q/Win32(emulator) (link)
WebWasher 2.2.1 Filtering Proxy shareware Win32 (link)
Mozilla 0.8 Browser open source Win32 (link)
Lynx Browser open source Unix (link)
Emacs W3 Browser open source Win32 (link)
Squid Proxy open source Unix (link)
Microsoft Proxy 2.0 Proxy commercial Win32 (link)
Allegrosurf 4.1 Proxy shareware Win32 (link)
BrowseGate 2.80.22 Proxy shareware Win32 (link)
CProxy Server 3.4.3 Proxy shareware Win32 (link)
Netscape Proxy 3.5 Proxy commercial Unix (link)
StarOffice 5.2 Office Tool commercial Unix (link)
Gnome 1.2 Graphical Environment open source Unix (link)
KDE 2.0 Graphical Environment open source Unix (link)

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.

injection-vector-survey
Application protocol Transport protocol Packet
HTTP TCP HTTP reply from test-tool to subject

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:

anomaly-categories
Name Description
O Overflow anomaly: (too) many character 'a':s
O-1 Overflow with number one
O-0 Overflow with number zero
O-NUM Overflow with numbers 0 and 1
O-/ Overflow with character '/'
O-/a Overflow with slash and 'a': /aa/aaaa/aa...
O-: Overflow with colon, i.e. character ':'
O-:a Oveflow with colon and 'a': :a:aa:aaaa...
O-SC Overflow with semicolon
O-SCa Overflow with semicolon and 'a'
O-. Overflow with dot, i.e. character '.'
O-, Overflow with comma, i.e. character ','
O-- Ovefflow with dash, i.e. character '-'
O-= Overflow with character '='
O-DIR Directory overflow: ../../../../.....
NO overflow with preceding null character -> '\0aaa..'
QO F+NO+O with quote(s): "aa", "%s", "a\0" including unbalanced quoting
F Format string anomaly: surprises for C implementations
UPGRADE O+F+NO and overflow of "HTTP/1.1"
URI-1 'http' +O-:+F+O-NO+O-SC+O-/+O-/a
URI-2 'http','://' +F+O-NO
URI-3 'http','://' +O-DIR

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:

combinations
Name Categories used First index Test cases
zero-items None 0 1
http-version-overflow-a O 1 8
http-version-overflow-slash O-/ 9 8
http-version-overflow-num O-1 17 19
http-version-overflow-dot O-. 36 8
http-version-overflow-1 O-1 44 8
http-version-format-anomaly F 52 15
status-code-overflow-num O-NUM 67 19
status-code-format-anomaly F 86 15
reason-phrase-anomaly O+F+NO 101 31
cache-request-directive-anomaly O+F+NO 132 31
cache-request-directive22-anomaly F+NO+O-NUM 163 42
cache-request-directive32-anomaly F+NO+O-NUM 205 42
cache-request-directive42-anomaly F+NO+O-NUM 247 42
date-format-anomaly F 289 15
date1-anomaly F+O-:+O-:a 304 35
http-date-comma-anomaly O-, 339 8
http-date-gmt-anomaly F+NO 347 23
weekday-anomaly O+F+NO 370 31
date-anomaly F+NO+O-NUM 401 42
date3-anomaly O-- 443 8
month-anomaly O+F+NO 451 31
time0-anomaly F+NO+O-NUM 482 42
time3-anomaly F+O-:+O-:a 524 35
pragma-directive-anomaly O+F+NO 559 31
extension-pragma-equal-anomaly O-= 590 8
extension-pragma-quoted-anomaly QO 598 63
trailer-anomaly O+F+NO 661 31
transfer-encoding-anomaly O+F+NO 692 31
upgrade-anomaly UPGRADE 723 38
received-protocol-anomaly F+NO+O-NUM 761 42
received-by00-anomaly O+F+NO 803 31
received-by01-anomaly F+O-:+O-:a 834 35
received-by02-anomaly F+NO+O-NUM 869 42
comment-anomaly O+F+NO 911 62
warn-code-anomaly F+NO+O-NUM 973 42
warn-agent00-anomaly O+F+NO 1015 31
warn-agent01-anomaly F+O-:+O-:a 1046 35
warn-agent02-anomaly F+NO+O-NUM 1081 42
warn-text-anomaly QO 1123 63
warn-date-anomaly QO 1186 63
accept-ranges-anomaly FNA 1249 23
age-anomaly F+NO+O-NUM 1272 42
etag-anomaly ETAG 1314 141
location-anomaly URI-1+URI-2+URI-3 1455 63
proxy-auth-anomaly O+F+NO 1518 31
proxy-auth-basic-anomaly QO 1549 4
proxy-auth-basic-anomaly2 QO 1553 8
proxy-auth-basic-realm-anomaly QO 1561 63
www-auth-anomaly O+F+NO 1624 31
www-auth-basic-anomaly QO 1655 4
www-auth-basic-anomaly2 QO 1659 8
www-auth-basic-realm-anomaly QO 1667 63
realm-anomaly-proxy QO 1730 63
realm-anomaly-www QO 1793 63
qop-value-anomaly-proxy O+F+NO 1856 31
qop-value-anomaly-www O+F+NO 1887 31
algorithm-anomaly-proxy O+F+NO 1918 31
algorithm-anomaly-www O+F+NO 1949 31
stale-anomaly-proxy O+F+NO 1980 31
stale-anomaly-www O+F+NO 2011 31
opaque-value-anomaly-proxy QO 2042 63
opaque-value-anomaly-www QO 2105 63
nonce-value-anomaly-proxy QO 2168 63
nonce-value-anomaly-www QO 2231 63
URI-digest-domain-proxy URI-1+URI-2+URI-3 2294 63
URI-digest-domain-www URI-1+URI-2+URI-3 2357 63
digest-comma-proxy O-, 2420 8
digest-comma-www O-, 2428 8
retry-after-anomaly F+NO+O-NUM 2436 42
server-anomaly O+F+NO 2478 31
vary-anomaly O+F+NO 2509 31
allow-anomaly O+F+NO 2540 31
authinfo-nextnonce-anomaly QO 2571 63
authinfo-response-digest-anomaly QO 2634 63
authinfo-qop-anomaly O+F+NO 2697 31
authinfo-cnonce-anomaly QO 2728 63
authinfo-nonce-count-anomaly F+NO+O-NUM 2791 42
content-coding-anomaly O-, 2833 31
content-language-anomaly O+F+NO 2864 31
content-length-anomaly F+NO+O-NUM 2895 42
content-location-anomaly URI-1+URI-2+URI-3 2937 63
content-md5-anomaly O+F+NO 3000 31
content-range-spec0-anomaly O+F+NO 3031 31
first-byte-pos-anomaly F+NO+O-NUM 3062 42
content-range-spec201-anomaly O-- 3104 8
last-byte-pos-anomaly F+NO+O-NUM 3112 42
content-range-spec3-anomaly O-/ 3154 8
instance-length-anomaly F+NO+O-NUM 3162 42
content-type-anomaly O+F+NO+O-/a+O-SCa 3204 31
parameter1-anomaly O-= 3235 8
parameter2-anomaly O+F+NO 3243 31
header-anomaly O+F+NO 3274 31
keep-alive-colon-anomaly F+O-:+O-:a 3305 35
keep-alive-timeout0-anomaly O+F+NO 3340 31
keep-alive-timeout1-anomaly O-= 3371 8
keep-alive-timeout2-anomaly F+NO+O-NUM 3379 42
keep-alive-comma-anomaly O-, 3421 8
URI-extension-header URI-1+URI-2+URI-3 3429 63
extension-token-anomaly O+F+NO 3492 31
filename-parm-anomaly O+F+NO 3523 31
size-parm-anomaly F+NO+O-NUM 3554 42
disposition-parm5-anomaly O+F+NO 3596 31
creation-date-anomaly QO 3627 63
read-date-anomaly QO 3690 63
modification-date-anomaly QO 3753 63
cookie-parms0-anomaly O+F+NO: 3816 31
cookie-parms1-anomaly O-= 3847 8
cookie-parms4-anomaly O: 3855 8
cookie-parms5-anomaly O-: 3863 8
cookie-semicolon-anomaly O-SC 3871 8
cookie-path2-anomaly O-/+O-/a 3879 8
cookie-path1-anomaly O-= 3887 8
cookie-domain2-anomaly O-. 3895 8
cookie-domain3-anomaly URI-1+URI-2+URI-3 3903 63

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.

Observed Failures
Combination name / Test-Run # 001 002 003 004 005 006 007 008 009 010 011 012
... . . . . . . . . . . . .
age-anomaly - - X - - - - - - - - -
... . . . . . . . . . . . .
location-anomaly - - - - - - - - - - - X
... . . . . . . . . . . . .
proxy-auth-basic-anomaly - P - - - - - - - - - -
... . . . . . . . . . . . .
proxy-auth-basic-realm-anomaly - - - - X - - - - - - -
... . . . . . . . . . . . .
www-auth-basic-realm-anomaly - - - X - - - - - - - -
realm-anomaly-proxy - P - - - - - - - - - -
realm-anomaly-www X - U - - - - - - - - -
qop-value-anomaly-proxy - P - - - - - - - - - -
qop-value-anomaly-www X - U - - - - - - - - -
algorithm-anomaly-proxy - - U - - - - - - - - -
algorithm-anomaly-www X - - - - - - - - - - -
... . . . . . . . . . . . .
stale-anomaly-www X - U - - - - - - - - -
opaque-value-anomaly-proxy - P - - - - - - - - - -
opaque-value-anomaly-www X - U - - - - - - - - -
... . . . . . . . . . . . .
nonce-value-anomaly-www X - U - - - - - - - - -
... . . . . . . . . . . . .
URI-digest-domain-www X - - - - - - - - - - -
... . . . . . . . . . . . .
digest-comma-www X - U - - - - - - - - -
... . . . . . . . . . . . .

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.

test-results
Test-run # Total test-cases Failed test-cases Total categories Failed categories
tr-001 3966 122 115 8
tr-002 3966 57 115 4
tr-003 3966 120 115 8
tr-004 3966 2 115 1
tr-005 3966 2 115 1
tr-006 3966 0 115 0
tr-007 3966 0 115 0
tr-008 3966 0 115 0
tr-009 3966 0 115 0
tr-010 3966 0 115 0
tr-011 3966 0 115 0
tr-012 3966 9 115 1

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

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]