Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4B01BD20.1060300@adnovum.ch>
Date: Mon, 16 Nov 2009 21:59:12 +0100
From: Hartmut Keil <Hartmut.Keil@adnovum.ch>
Reply-To: dev@httpd.apache.org
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: handling request splicing in case of server initiated renegotiation
 CVE-2009-3555
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi everybody


for clarification of https://issues.apache.org/bugzilla/show_bug.cgi?id=48204
a more detailed explanation of the described attack scenario is given here.

With the patch CVE-2009-3555-2.2.patch client initiated renegotiation has been disabled,
as a consequence of CVE-2009-3555. But a MITM attacker can also use the server initiated
renegotiation for exceting an arbitrary request with the Cookie of a victim.
(see http://extendedsubset.com/Renegotiating_TLS.pdf )

The following is the output of ssldump between a MITM attacker and the server. Remarks from my side
are starting with '###', longish message are replace by '....'.


New TCP connection #1: adnws121.zh.adnovum.ch(44889) <-> adnpool01.zh.adnovum.ch(44300)
1 1  0.4423 (0.4423)  C>S SSLv2 compatible client hello
  Version 3.1
  cipher suites
  ....
1 2  0.4447 (0.0024)  S>C  Handshake
      ServerHello
        Version 3.1
      ....
1 3  0.4448 (0.0000)  S>C  Handshake
      Certificate
1 4  0.4448 (0.0000)  S>C  Handshake
      ServerHelloDone
1 5  0.4546 (0.0098)  C>S  Handshake
      ClientKeyExchange
1 6  0.4595 (0.0049)  C>S  ChangeCipherSpec
1 7  0.5504 (0.0908)  C>S  Handshake
      Finished
1 8  0.5513 (0.0009)  S>C  ChangeCipherSpec
1 9  0.5513 (0.0000)  S>C  Handshake
      Finished

### up to here the MITM has established a normale handshake with the server

1 10 0.5521 (0.0008)  C>S  application_data
    ---------------------------------------------------------------
    GET /cert/hacked.html HTTP/1.1
    Host: adnpool01.zh.adnovum.ch

    GET /cert/injected.html HTTP/1.1
    Host: adnpool01.zh.adnovum.ch
    X-Ignore: ---------------------------------------------------------------

### the MITM is sending two request in one chunk application_data: First a complete
    request, that is causes the server to initiate a renegotiation. And second request, that
    is incomplete, since the last header 'X-Ignore:' is not terminated by CRLF.
    At this point the server has consumend and decrypted both requests, because the request line
    will be readed with buffer size of 2*8190 (the default of the configuration paramter LimitRequestLine)

     rv = ap_rgetline(&(r->the_request), (apr_size_t)(r->server->limit_req_line + 2),
                         &len, r, 0, bb);

     And in ssl_io_input_getline(..) all decrypted data will be written to a buffer:

     static apr_status_t ssl_io_input_getline(bio_filter_in_ctx_t *inctx,
                                         char *buf,
                                         apr_size_t *len)
   {
    ....
    ....
    if (pos) {
        char *value;
        int length;
        apr_size_t bytes = pos - buf;

        bytes += 1;
        value = buf + bytes;
        length = *len - bytes;

        char_buffer_write(&inctx->cbuf, value, length);

        *len = bytes;
    }

    return APR_SUCCESS;
   }

   And any subsequent call of ssl_io_input_read(..) will first consume the data in the buffer!!!!!

1 11 0.5584 (0.0062)  S>C  Handshake
      HelloRequest

### the server is initiating a renegation, due to 'SSLVerifyClient require' configuration
    for the location /cert/*
    From now on the MITM is just downstreaming the decrypted data to the victim. And upstreaming
    the encrypted data to the server, until he observes the change_cipher_spec messages.

1 12 0.6504 (0.0919)  C>S  Handshake
      ClientHello
        Version 3.1
        cipher suites
        ....
1 13 0.6530 (0.0025)  S>C  Handshake
      ServerHello
        Version 3.1
       ....
1 14 0.6530 (0.0000)  S>C  Handshake
      Certificate
1 15 0.6530 (0.0000)  S>C  Handshake
      CertificateRequest
      ....
      ServerHelloDone
1 16 4.5204 (3.8674)  C>S  Handshake
      Certificate
1 17 4.5204 (0.0000)  C>S  Handshake
      ClientKeyExchange
1 18 4.5204 (0.0000)  C>S  Handshake
      CertificateVerify
      ....
1 19 4.5204 (0.0000)  C>S  ChangeCipherSpec
1 20 4.5204 (0.0000)  C>S  Handshake
      Finished
1 21 4.5589 (0.0384)  S>C  ChangeCipherSpec
1 22 4.5589 (0.0000)  S>C  Handshake
      Finished
1 23 4.5619 (0.0030)  S>C  application_data
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Date: Mon, 16 Nov 2009 19:53:25 GMT
    Server: Apache
    ...

    ---------------------------------------------------------------
1 24 4.5619 (0.0000)  S>C  application_data
    ---------------------------------------------------------------
    ....
    ---------------------------------------------------------------
1 25 4.6604 (0.0984)  C>S  application_data
    ---------------------------------------------------------------
    GET /cert/index.html HTTP/1.1
    Cookie: JSESSIONID=bhe8r67be3wy943hf73
    ....

### After recieving the request of the victim the server can complete the incomplete second request of MITM.
    The server is reading the following request header:

    GET /cert/injected.html HTTP/1.1
    X-Ignore: GET /cert/index.html HTTP/1.1
    Cookie: JSESSIONID=bhe8r67be3wy943hf73
    ....

    I.e. the second request of the attacker will be executed with the
    Cookie of the victim, and so the attacker is puting its payload into
    the second request.


    ---------------------------------------------------------------
1 26 4.6666 (0.0062)  S>C  application_data
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Date: Mon, 16 Nov 2009 19:53:29 GMT
    Server: Apache
    ....

    ---------------------------------------------------------------
1 27 4.6666 (0.0000)  S>C  application_data
    ---------------------------------------------------------------
    ....
    ---------------------------------------------------------------
1 28 9.6708 (5.0042)  S>C  Alert
    level           warning
    value           close_notify
1    9.6713 (0.0004)  S>C  TCP FIN


With the change described in https://issues.apache.org/bugzilla/show_bug.cgi?id=48204
the buffer used in ssl_io_input_read(..) will be reset, and so the second request of
the MITM will be dropped.
The first request will be executed, but since there is no Cookie from the victim is the
less dangerous one.


There are no side effects for two reasons:
o any upload body is buffered in ssl_hook_Access(..)
  before the server is initiating a renegotiation
o normal clients are following the 'request/response' pattern
  of HTTP. They do not send a second request without awaiting the
  response of the first one. They use several connections.


Regards

Hartmut Keil


-- 
AdNovum Informatik AG
Hartmut Keil, Senior Software Engineer
Dipl. Physiker

Roentgenstrasse 22, CH-8005 Zurich
mailto:hartmut.keil@adnovum.ch
phone: +41 44 272 6111, fax: +41 44 272 6312
http://www.adnovum.ch

AdNovum Locations: Bern, Budapest, San Mateo, Zurich (HQ)