Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 48204] New: extended patch CVE-2009-3555-2.2.patch
 handling request splicing in case of  server initiated  renegotiation
Message-ID: <bug-48204-7868@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Mon, 16 Nov 2009 03:56:49 -0800 (PST)

https://issues.apache.org/bugzilla/show_bug.cgi?id=48204

           Summary: extended patch CVE-2009-3555-2.2.patch handling
                    request splicing in case of  server initiated
                    renegotiation
           Product: Apache httpd-2
           Version: 2.2-HEAD
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: mod_ssl
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: Hartmut.Keil@adnovum.ch


With the patch
http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
client initiated renegotiation has been disabled,
as a consequence of CVE-2009-3555.

But in the case of a server initiated renegotiation a MITM attacker can still 
execute an arbitrary request within the victims context:

o the MITM is sending a complete HTTP request, lets say with URL /cert
  and an incomplete request with URL /cert/hacked. With incomplete
  is meant, that the last request header, lets say 'X-Ignore' is not 
  terminated.

o both request will be buffered in the function 'ssl_io_input_read(..)'
  in the cbuf of the struct bio_filter_in_ctx.

o the URL of the first request is triggering mod_ssl to initiate a SSL 
  renegotiation

o the MITM is forwarding the SSL handshakes messages and the payload from the 
  victim, in the way described in 
  http://extendedsubset.com/Renegotiating_TLS.pdf.

o in the end the server is executing the second request /cert/hacked of the
MITM
  with the headers of the victim request, especially the Cookie header 
  (These kind of attack has been executed by us against httpd/2.2.14 with the 
   CVE-2009-3555-2.2.patch.)


A simple countermeasure is to reset the buffer 'cbuf' of the decrypted data 
in case of a server initiated renegotiation. See the following patch of the
method 'bio_filter_in_read(..) in ssl_engine_io.c

--- ssl_engine_io.c.patched     2009-11-16 10:57:23.416525000 +0100
+++ ssl_engine_io.c     2009-11-16 11:46:51.090262000 +0100
@@ -478,6 +478,10 @@
         inctx->rc = APR_ECONNABORTED;
         return -1;
     }
+       /* Clear buffer with decrypted data if the server has initiated a
renegotiation. */
+       if (inctx->filter_ctx->config->reneg_state == RENEG_ALLOW) {
+        char_buffer_write(&inctx->cbuf, NULL, 0);
+    }

     /* XXX: flush here only required for SSLv2;
      * OpenSSL calls BIO_flush() at the appropriate times for

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org