Is there a patch planned for Openssl Security Asvisory?
A flaw in OBJ_obj2txt may cause pretty printing functions such as
X509_name_oneline, X509_name_print_ex et al. to leak some information from the
stack. Applications may be affected if they echo pretty printing output to the
attacker. OpenSSL SSL/TLS clients and servers themselves are not affected.
OpenSSL 0.9.8 users should upgrade to 0.9.8zb
OpenSSL 1.0.0 users should upgrade to 1.0.0n.
OpenSSL 1.0.1 users should upgrade to 1.0.1i.
Thanks to Ivan Fratric (Google) for discovering this issue. This issue
was reported to OpenSSL on 19th June 2014.
The fix was developed by Emilia Käsper and Stephen Henson of the OpenSSL
development team.
The issue affects OpenSSL clients and allows a malicious server to crash
the client with a null pointer dereference (read) by specifying an SRP
ciphersuite even though it was not properly negotiated with the client. This can
be exploited through a Denial of Service attack.
OpenSSL 1.0.1 SSL/TLS client users should upgrade to 1.0.1i.
Thanks to Joonas Kuorilehto and Riku Hietamäki (Codenomicon) for discovering and
researching this issue. This issue was reported to OpenSSL on 2nd July 2014.
The fix was developed by Stephen Henson of the OpenSSL core team.
If a multithreaded client connects to a malicious server using a resumed session
and the server sends an ec point format extension it could write up to 255 bytes
to freed memory.
OpenSSL 1.0.0 SSL/TLS client users should upgrade to 1.0.0n.
OpenSSL 1.0.1 SSL/TLS client users should upgrade to 1.0.1i.
Thanks to Gabor Tyukasz (LogMeIn Inc) for discovering and researching this
issue. This issue was reported to OpenSSL on 8th July 2014.
The fix was developed by Gabor Tyukasz.
An attacker can force an error condition which causes openssl to crash whilst
processing DTLS packets due to memory being freed twice. This can be exploited
through a Denial of Service attack.
OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zb
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0n.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1i.
Thanks to Adam Langley and Wan-Teh Chang (Google) for discovering and
researching this issue. This issue was reported to OpenSSL on 6th June
2014.
The fix was developed by Adam Langley.
An attacker can force openssl to consume large amounts of memory whilst
processing DTLS handshake messages. This can be exploited through a Denial of
Service attack.
OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zb
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0n.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1i.
Thanks to Adam Langley (Google) for discovering and researching this
issue. This issue was reported to OpenSSL on 6th June 2014.
The fix was developed by Adam Langley.
By sending carefully crafted DTLS packets an attacker could cause openssl to
leak memory. This can be exploited through a Denial of Service attack.
OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zb
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0n.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1i.
Thanks to Adam Langley (Google) for discovering and researching this
issue. This issue was reported to OpenSSL on 6th June 2014.
The fix was developed by Adam Langley.
OpenSSL DTLS clients enabling anonymous (EC)DH ciphersuites are subject to a
denial of service attack. A malicious server can crash the client with a null
pointer dereference (read) by specifying an anonymous (EC)DH ciphersuite and
sending carefully crafted handshake messages.
OpenSSL 0.9.8 DTLS client users should upgrade to 0.9.8zb
OpenSSL 1.0.0 DTLS client users should upgrade to 1.0.0n.
OpenSSL 1.0.1 DTLS client users should upgrade to 1.0.1i.
Thanks to Felix Gröbert (Google) for discovering and researching this issue.
This issue was reported to OpenSSL on 18th July 2014.
The fix was developed by Emilia Käsper of the OpenSSL development team.
A flaw in the OpenSSL SSL/TLS server code causes the server to negotiate
TLS 1.0 instead of higher protocol versions when the ClientHello message is
badly fragmented. This allows a man-in-the-middle attacker to force a
downgrade to TLS 1.0 even if both the server and the client support a higher
protocol version, by modifying the client's TLS records.
OpenSSL 1.0.1 SSL/TLS server users should upgrade to 1.0.1i.
Thanks to David Benjamin and Adam Langley (Google) for discovering and
researching this issue. This issue was reported to OpenSSL on 21st July 2014.
The fix was developed by David Benjamin.
A malicious client or server can send invalid SRP parameters and overrun
an internal buffer. Only applications which are explicitly set up for SRP
use are affected.
OpenSSL 1.0.1 SSL/TLS users should upgrade to 1.0.1i.
Thanks to Sean Devlin and Watson Ladd (Cryptography Services, NCC
Group) for discovering this issue. This issue was reported to OpenSSL
on 31st July 2014.
The fix was developed by Stephen Henson of the OpenSSL core team.
Great question! These OpenSSL updates will be part of our next maintenance release. Based on known usages of OpenSSL within Splunk, OpenSSL TLS protocol downgrade attack (CVE-2014-3511) is the main risk. We are working on the next maintenance releases and will issue updated security advisories. In the meantime, keep an eye on Splunk Product Security Portal for additional updates and announcements.
Great question! These OpenSSL updates will be part of our next maintenance release. Based on known usages of OpenSSL within Splunk, OpenSSL TLS protocol downgrade attack (CVE-2014-3511) is the main risk. We are working on the next maintenance releases and will issue updated security advisories. In the meantime, keep an eye on Splunk Product Security Portal for additional updates and announcements.