[SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
Guys,
I just tried patching 6.0.20 with the tomcat6 fix mentioned at
http://www.mail-archive.com/users@tomcat.apache.org/msg70131.html
This gives me a concurrentmodificationexception:
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$EntryIterator.next(Unknown Source)
at java.util.HashMap$EntryIterator.next(Unknown Source)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl$NotifyHandshakeThread.run(Unknown
Source)
From http://java.sun.com/j2se/1.5.0/docs/api/java/util/HashMap.html, I see:
The iterators returned by all of this class's collection view methods are
fail-fast: if the map is structurally modified at any time after the
iterator is created, in any way except through the iterator's own remove or
add methods, the iterator will throw a ConcurrentModificationException. ...
Now, looks like The NotifyHandshakeThread iterates map of socket listeners,
performing callback on each. The new disableSslHandshake listener closes
containing socket, causing our failfast iterator to, well, fail.
Attempting to handle this error, I do a form of asynchronous close as
follows:
private static class DisableSslRenegotiation
implements HandshakeCompletedListener {
private volatile boolean completed = false;
/** commented out. This method is called from SSLSocketImpl
which iterates set of listeners. Closing the containing socket
can cause error in iterator execution **/
public void handshakeCompleted(HandshakeCompletedEvent event) {
if (completed) {
try {
log.warn(SSL renegotiation is disabled, closing
connection);
event.getSession().invalidate();
event.getSocket().close();
} catch (IOException e) {
// ignore
}
}
completed = true;
}
*/
public void handshakeCompleted(HandshakeCompletedEvent event) {
if (completed) {
final SSLSession session = event.getSession();
final SSLSocket socket = event.getSocket();
// spawn anon thread to close session
new Thread(){
public void run() {
synchronized(socket) {
try {
log.warn(SSL renegotiation is disabled, closing
connection);
session.invalidate();
socket.close();
} catch (IOException e) {
// ignore
}
}
}
}.start();
}
completed = true;
}
}
While this does seem to resolve concurrent modifications, I believe it is a
race-condition at best, which is working in my favour for now. Please
suggest me another fix, if there is one.
Thanks in advance,
Timir
Re: [SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
On 16/12/2009 14:29, Timir Hazarika wrote: Guys, I just tried patching 6.0.20 with the tomcat6 fix mentioned at http://www.mail-archive.com/users@tomcat.apache.org/msg70131.html This gives me a concurrentmodificationexception: snip/ While this does seem to resolve concurrent modifications, I believe it is a race-condition at best, which is working in my favour for now. Please suggest me another fix, if there is one. Use the newer patch that doesn't use a HandshakeCompletedListener Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
Mark, I can't seem to find the newer patch, could you share a link please ? Thanks, Timir On Wed, Dec 16, 2009 at 9:42 PM, Mark Thomas ma...@apache.org wrote: On 16/12/2009 14:29, Timir Hazarika wrote: Guys, I just tried patching 6.0.20 with the tomcat6 fix mentioned at http://www.mail-archive.com/users@tomcat.apache.org/msg70131.html This gives me a concurrentmodificationexception: snip/ While this does seem to resolve concurrent modifications, I believe it is a race-condition at best, which is working in my favour for now. Please suggest me another fix, if there is one. Use the newer patch that doesn't use a HandshakeCompletedListener Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
Never mind - I just figured out what text modifications went into that revision. Mark, any news on 6.0.21 timelines ? Up for release vote yet ? Thanks, Timir On Wed, Dec 16, 2009 at 11:45 PM, Timir Hazarika timir.hazar...@gmail.comwrote: Mark, I can't seem to find the newer patch, could you share a link please ? Thanks, Timir On Wed, Dec 16, 2009 at 9:42 PM, Mark Thomas ma...@apache.org wrote: On 16/12/2009 14:29, Timir Hazarika wrote: Guys, I just tried patching 6.0.20 with the tomcat6 fix mentioned at http://www.mail-archive.com/users@tomcat.apache.org/msg70131.html This gives me a concurrentmodificationexception: snip/ While this does seem to resolve concurrent modifications, I believe it is a race-condition at best, which is working in my favour for now. Please suggest me another fix, if there is one. Use the newer patch that doesn't use a HandshakeCompletedListener Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
On 16/12/2009 20:05, Timir Hazarika wrote: Never mind - I just figured out what text modifications went into that revision. Mark, any news on 6.0.21 timelines ? Up for release vote yet ? Nothing certain but should be soon. Keep an eye on the dev list for any news on tags, release votes etc. Mark Thanks, Timir On Wed, Dec 16, 2009 at 11:45 PM, Timir Hazarika timir.hazar...@gmail.comwrote: Mark, I can't seem to find the newer patch, could you share a link please ? Thanks, Timir On Wed, Dec 16, 2009 at 9:42 PM, Mark Thomas ma...@apache.org wrote: On 16/12/2009 14:29, Timir Hazarika wrote: Guys, I just tried patching 6.0.20 with the tomcat6 fix mentioned at http://www.mail-archive.com/users@tomcat.apache.org/msg70131.html This gives me a concurrentmodificationexception: snip/ While this does seem to resolve concurrent modifications, I believe it is a race-condition at best, which is working in my favour for now. Please suggest me another fix, if there is one. Use the newer patch that doesn't use a HandshakeCompletedListener Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack - Status update
Overview The purpose of this update is provide information on the current understanding so users are better informed when making decisions regarding risk mitigation for this issue in their environment. Work on the root cause is progressing but is still in a state of flux. Discussion is focussed on workarounds that could be applied that would allow server initiated renegotiation without exposing the participants to the vulnerability described in CVE-2009-3555. BIO Connector = The HTTP BIO connector that ships with 6.0.20 and 5.5.28 supports client and server initiated negotiation and is vulnerable to CVE-2009-3555. A patch [1],[2] has been applied to trunk, 6.0.x and 5.5.x that provides an option to disable renegotiation. This patch has an issue in that it uses an asynchronous callback to close the connection when a handshake is detected. It is theoretically possible for an attack to complete before the connection is closed. When negotiation is disabled, both server and client initiated attempts to renegotiate are logged. An updated patch [3] has been applied to trunk and proposed for 6.0.x and 5.5.x that resolves the asynchronous concerns but only logs server initiated renegotiation. Users of 6.0.20, 5.5.28 and earlier versions can apply either of the patches. It will be necessary to build Tomcat from source to use these patches. Testing with both these patches has shown that using the connector attributes clientAuth=want and allowUnsafeLegacyRenegotiation=false provides a similar user experience during negotiation to clientAuth=false and allowUnsafeLegacyRenegotiation=true although this may vary by application. It is anticipated that 6.0.21 and 5.5.29 releases will be made once the situation stabilises and the Tomcat development team is confident that further changes will not be required. [1]http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc6.patch [2]http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc5.patch [3]http://svn.apache.org/viewvc?rev=882320view=rev NIO Connector = The HTTP NIO connector that ships with 6.0.20 does not support client or server initiated renegotiation and is therefore not vulnerable to CVE-2009-3555. As and when negotiation support is added to the NIO connector, it will support the allowUnsafeLegacyRenegotiation connector attribute and behave in a similar manner to the HTTP BIO connector. APR / native Connector == Behaviour of the APR/native connector depends on the version of the APR/native connector and on the version of OpenSSL that the connector is build with. Versions prior to APR/native 1.1.16 are not discussed. The windows binaries available from the ASF have been built with the following OpenSSL versions: APR/native OpenSSL 1.1.16 0.9.8i 1.1.17 0.9.8l 1.1.18 TBD - not yet released Any version of the APR/native connector built with OpenSSl 0.9.8l will not support client or server initiated negotiation and will, therefore, not be vulnerable to CVE-2009-3555. Client initiated negotiation is supported in 1.1.16 and 1.1.17. These versions are, therefore, vulnerable to CVE-2009-3555 unless built with OpenSSL 0.9.8l. Client initiated negotiation has been disabled in 1.1.18. Therefore, this version is not vulnerable to CVE-2009-3555 via client initiated renegotiation although it may still be vulnerable via server initiated renegotiation. Server initiated renegotiation is supported in 1.1.17 onwards. Therefore, 1.1.17 onwards is vulnerable to CVE-2009-3555 via server initiated renegotiation unless the APR/native connector is built with OpenSSL 0.9.8l. Questions / comments Any questions or comments should be directed to the Tomcat users mailing list in the first instance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2009-3555 SSL Man-In-The-Middle attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A vulnerability in the TLS protocol has recently been made public [1] that allows an attacker to inject arbitrary requests into an TLS stream. The current understanding of the Tomcat developers is as follows: BIO NIO connectors using JSSE These connectors are vulnerable when renegotiation is triggered by the client or the server. Server initiated re-negotiation can be limited by configuration Server initiated re-negotiation could be prevented by a code change Client initiated re-negotiation can not currently be prevented APR/Native connector using OpenSSL Vulnerable when renegotiation is triggered by the client or the server. Server initiated re-negotiation is not supported prior to 1.1.17 Client initiated re-negotiation is supported but can not be prevented OpenSSL 0.9.8l disables all negotiation by default In terms of what this means for users: BIO/NIO - - We haven't yet (we are still looking) found a way to stop client initiated renegotiation. It may be necessary to wait for the JVM vendors to respond. APR/native - - Re-building any version of the APR/native connector with OpenSSL 0.9.8l will protect against this vulnerability but any configurations that require renegotiation will break. - - Version 1.1.17 of the APR/native connector will be released shortly. The binary versions will be built with OpenSSL 0.9.8l which will protect against this vulnerability but configurations that require renegotiation will break. Supporting renegotiation whilst avoiding the vulnerability requires a protocol fix. The Tomcat development team is examining possible work-arounds that may provide an interim solution. These options include porting r833582 from httpd to the APR/native connector which would disable client triggered renegotiation for OpenSSL 0.9.8l which may help some users who can't easily change their OpenSSL version. If you'd would like to join/follow the work-around discussions, please join the Tomcat dev mailing list. Any significant developments in this area will be posted to the Tomcat announce@ and users@ mailing lists. Mark [1] http://extendedsubset.com/?p=8 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJK+Ea6AAoJEBDAHFovYFnnjggP/RU6UpOmXDCzOG/neVmMI0RX XMKMZdpph8TCdjOzOd1UdCGPK5q3U1CDvB7P96eYZ5R745YTT6Ct1hXETC++SAh2 Q6jRD2qNPXX7hA9JFallC6+PUjq+IaHknJQYGAFaHCEdvwocp8NYWxUSqg5yTc6U toUclHntjEwXc6jpEeNwuU3An8WNf2rX5OV9IX17lS7mxtElfVVIM5o4PrkMV0Tn 5i3YpLXTzHIHZ3Wv6VOlsQy+X+JhM4GMWF+4wWgHzdUfQ3wCpUrmC/tOgsXp23j8 ITPqIcf5dsDsOEd9RAZRWoRPpgcJH3bypnmG65VpITRkjnvKq6GC1TcKXTdUBxER 0OwpAY2A/e6OzHpw68q0wn5deYKBEo+6DJ/rFmHCs4KYiw7WXpOQFsL5LXxuDfEr 7W79w1nEPAaXz6KGSGiEuPxyLtJafAP16ZtaITqzoI9Pn1bpl9iP/OK+2OTc/e+/ BF0vI0gh2ZD2AbktNZJLY8+i5FmF/jcJP6/SQLnFQl5AZQ6YhRNQl87bc4lEkZkm IHIdJW28EbD/4V0Yex8MnAFIFEq/jyWe2LgUep0/j9LEkMKlFGpoNNgEQsA9E8ml RR9adgTCESBN6cCCsn5CrYTlsTKyfxk/Db2inI7L/OM3zfQoCTQDFnxY1l13I+Dt FiHrC9dgiTCEZL0fR69F =xrMK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
