Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Bugs

[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation

 

 

Apache bugs RSS feed   Index | Next | Previous | View Threaded


bugzilla at apache

Nov 16, 2009, 4:33 AM

Post #1 of 6 (595 views)
Permalink
[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation

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

--- Comment #1 from Eric Covener <covener [at] gmail> 2009-11-16 04:33:39 UTC ---
> 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

How does this not discard a legitimate clients request line?

--
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 [at] httpd
For additional commands, e-mail: bugs-help [at] httpd


bugzilla at apache

Nov 16, 2009, 4:39 AM

Post #2 of 6 (567 views)
Permalink
[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation [In reply to]

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

--- Comment #2 from keilh <Hartmut.Keil [at] adnovum> 2009-11-16 04:39:52 UTC ---
(In reply to comment #1)
> > 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
>
> How does this not discard a legitimate clients request line?

No. If mod_ssl is initiated a SSL renegotiation, the request header is already
parsed/consumed.

--
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 [at] httpd
For additional commands, e-mail: bugs-help [at] httpd


bugzilla at apache

Nov 16, 2009, 4:46 AM

Post #3 of 6 (568 views)
Permalink
[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation [In reply to]

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

--- Comment #3 from Eric Covener <covener [at] gmail> 2009-11-16 04:46:12 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > > 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
> >
> > How does this not discard a legitimate clients request line?
>
> No. If mod_ssl is initiated a SSL renegotiation, the request header is already
> parsed/consumed.

Sorry to be obtuse, but then how does this help in the attack scenario?

--
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 [at] httpd
For additional commands, e-mail: bugs-help [at] httpd


bugzilla at apache

Nov 16, 2009, 4:56 AM

Post #4 of 6 (568 views)
Permalink
[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation [In reply to]

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

--- Comment #4 from keilh <Hartmut.Keil [at] adnovum> 2009-11-16 04:56:12 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > > 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
> > >
> > > How does this not discard a legitimate clients request line?
> >
> > No. If mod_ssl is initiated a SSL renegotiation, the request header is already
> > parsed/consumed.
>
> Sorry to be obtuse, but then how does this help in the attack scenario?

The second, incomplete request in cbuff will be discarded, and request splicing
is no longer working

--
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 [at] httpd
For additional commands, e-mail: bugs-help [at] httpd


bugzilla at apache

Nov 16, 2009, 5:07 AM

Post #5 of 6 (567 views)
Permalink
[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation [In reply to]

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

--- Comment #5 from Eric Covener <covener [at] gmail> 2009-11-16 05:07:03 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > > 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
> > > >
> > > > How does this not discard a legitimate clients request line?
> > >
> > > No. If mod_ssl is initiated a SSL renegotiation, the request header is already
> > > parsed/consumed.
> >
> > Sorry to be obtuse, but then how does this help in the attack scenario?
>
> The second, incomplete request in cbuff will be discarded, and request splicing
> is no longer working

Sorry, I see now -- this is not a measure to allow the non-attack scenario,
it's just the other half of the nuclear option for admins who haven't removed
their per-dir renegotiation stuff.

--
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 [at] httpd
For additional commands, e-mail: bugs-help [at] httpd


bugzilla at apache

Nov 16, 2009, 5:49 AM

Post #6 of 6 (567 views)
Permalink
[Bug 48204] extended patch CVE-2009-3555-2.2.patch handling request splicing in case of server initiated renegotiation [In reply to]

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

Joe Orton <jorton [at] redhat> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX

--- Comment #6 from Joe Orton <jorton [at] redhat> 2009-11-16 05:49:33 UTC ---
1) I'm surprised that patch has any effect; if it does, surely it is due to
timing of the receipt of the app-data packets comprising the victim's request
by the server, which is under the control of the attacker?

2) I can't see how discarding data at this point is a good idea - if you
presume the connection is under active attack in that code path, the only sane
course of action is to log that and close the connection, right? If you don't
presume the connection is under active attack then discarding bytes is going to
cause
some weird and wonderful failure modes.

I think it'd be better to discuss this on dev [at] http to get a wider audience.
Could you start a thread there, maybe with some packet traces or similar to
outline how this would work?

--
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 [at] httpd
For additional commands, e-mail: bugs-help [at] httpd

Apache bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.