[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [07 Dec 2017]


Read/write after SSL object in error state (CVE-2017-3737)
==

Severity: Moderate

OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake then
OpenSSL would move into the error state and would immediately fail if you
attempted to continue the handshake. This works as designed for the explicit
handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()),
however due to a bug it does not work correctly if SSL_read() or SSL_write() is
called directly. In that scenario, if the handshake fails then a fatal error
will be returned in the initial function call. If SSL_read()/SSL_write() is
subsequently called by the application for the same SSL object then it will
succeed and the data is passed without being decrypted/encrypted directly from
the SSL/TLS record layer.

In order to exploit this issue an application bug would have to be present that
resulted in a call to SSL_read()/SSL_write() being issued after having already
received a fatal error.

This issue does not affect OpenSSL 1.1.0.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 10th November 2017 by David Benjamin
(Google). The fix was proposed by David Benjamin and implemented by Matt Caswell
of the OpenSSL development team.

rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=

Severity: Low

There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this defect
would be very difficult to perform and are not believed likely. Attacks
against DH1024 are considered just feasible, because most of the work
necessary to deduce information about a private key may be performed offline.
The amount of resources required for such an attack would be significant.
However, for an attack on TLS to be meaningful, the server would have to share
the DH1024 private key among multiple clients, which is no longer an option
since CVE-2016-0701.

This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).

Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732
and CVE-2015-3193.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it
becomes available. The fix is also available in commit e502cc86d in the OpenSSL
git repository.

OpenSSL 1.0.2 users should upgrade to 1.0.2n

This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin
(Google). The issue was originally found via the OSS-Fuzz project. The fix was
developed by Andy Polyakov of the OpenSSL development team.

Note


Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171207.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJaKUFJAAoJENnE0m0OYESRp1UH/1Z8hBb1dM82Lnn3b0pQ1LjF
xBqs0cBFax6z8gelZzUI3CEJe78n3YB6jJiyCDOvrsrb9dx4kGvt97R9x9Np6glh
/cL98I1mVwLdLciE1WeBPBFDijp5Bii4pz3q4StFGmh9g9cQ70onz8OO0RB9GSS5
dpbRcbOZLcyt3Lnqmnx86SLAdGgF635SO0EE10txDXjgEUK3Zo+gT+/jelwoNLXT
mtYfqgXp6+Eqa08Qq3Nmrgqz4azhFLD5szixmnXQwbP+OpiT+zpNXsV5qqemWFn9
aV2qzDJJtrpObaPXSqKCBUA7C1qYmj9OmeaDUVJ29vS1mm09hs18if954ib6nbw=
=MmWs
-END PGP SIGNATURE-
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [02 Nov 2017]


bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
==

Severity: Moderate

There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients.

This only affects processors that support the BMI1, BMI2 and ADX extensions like
Intel Broadwell (5th generation) and later or AMD Ryzen.

Note: This issue is very similar to CVE-2017-3732 and CVE-2015-3193 but must be
treated as a separate problem.

OpenSSL 1.1.0 users should upgrade to 1.1.0g
OpenSSL 1.0.2 users should upgrade to 1.0.2m

This issue was reported to OpenSSL on 10th August 2017 by the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.

Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)


Severity: Low

This issue was previously announced in security advisory
https://www.openssl.org/news/secadv/20170828.txt, but the fix has not previously
been included in a release due to its low severity.

OpenSSL 1.1.0 users should upgrade to 1.1.0g
OpenSSL 1.0.2 users should upgrade to 1.0.2m


Note


Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171102.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZ+y3yAAoJENnE0m0OYESRWooH/2cS+HkzBCCdnJ/CWuhKomTe
hshdBbYw/eYeZgrUYZX6CYosvhLX1Hkwef3vVMxHDXsnBnnZfGfwCS2EfXJ96xXK
KiXVchBwlpmovrOuAvrGtPqLkiVOZZpGMfopP30WCKc6tkdqjw/NvruMbg7Iz+Sy
ki5AM7Vw7kAEa18KAGjSN4jSrCHMIKkOeGkmay5hHlYLwQRQDAAo5EmWmVOJpUXF
ddvQ6h+NKqlWAMF+2/U3PhUFa4V7xqlKR3GMdRawVSaoKQUsPXvRGAhLnvqfOonx
y0yl7y9a7EJrcRl8HWf7qqZf0B/m3YapCHNNcBYWry+qk7LJgGjIHDF8VFkEABg=
=k+bJ
-END PGP SIGNATURE-
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [16 Feb 2017]


Encrypt-Then-Mac renegotiation crash (CVE-2017-3733)


Severity: High

During a renegotiation handshake if the Encrypt-Then-Mac extension is
negotiated where it was not in the original handshake (or vice-versa) then this
can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers
are affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0e

This issue does not affect OpenSSL version 1.0.2.

This issue was reported to OpenSSL on 31st January 2017 by Joe Orton (Red Hat).
The fix was developed by Matt Caswell of the OpenSSL development team.

Note


Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20170216.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYpZMiAAoJENnE0m0OYESRMUgH/0UN9sxxgyDewSCMeTOYPauK
cSPqyw1pndQI6Lu+d3OCdWd01rdLcm+HxlbW5FOUjGZ4G9YefE0+JcvKkIuLGIpQ
1EE0g/ZuBzWDh7/MkFWcmjHceYVXi5sKewtWcQvO9uePzlPhlSZoNIL1G66n1HAo
of3ZlSL5BmibaTiz1WmpDG//0W1pgYP5OdvQ8/AVrJJf8pUnU9Oyubm1yCyK2RHi
jfJWLbMx0ENgW4G1sW4s8bPaj4GwLjIrZl8ocqoyAHhghkBv/UXUhv6i62bKHmxW
vfYwwiU0GlRVwPXzFKbbE3qqCRyDsq+XLAe/09NZZWA+BtscWuUhUpyEODBqzeY=
=zqNG
-END PGP SIGNATURE-
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [26 Jan 2017]


Truncated packet could crash via OOB read (CVE-2017-3731)
=

Severity: Moderate

If an SSL/TLS server or client is running on a 32-bit host, and a specific
cipher is being used, then a truncated packet can cause that server or client
to perform an out-of-bounds read, usually resulting in a crash.

For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305;
users should upgrade to 1.1.0d

For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have
not disabled that algorithm should update to 1.0.2k

This issue was reported to OpenSSL on 13th November 2016 by Robert Święcki of
Google. The fix was developed by Andy Polyakov of the OpenSSL development team.

Bad (EC)DHE parameters cause a client crash (CVE-2017-3730)
===

Severity: Moderate

If a malicious server supplies bad parameters for a DHE or ECDHE key exchange
then this can result in the client attempting to dereference a NULL pointer
leading to a client crash. This could be exploited in a Denial of Service
attack.

OpenSSL 1.1.0 users should upgrade to 1.1.0d

This issue does not affect OpenSSL version 1.0.2.

Note that this issue was fixed prior to it being recognised as a security
concern. This means the git commit with the fix does not contain the CVE
identifier. The relevant fix commit can be identified by commit hash efbe126e3.

This issue was reported to OpenSSL on 14th January 2017 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

BN_mod_exp may produce incorrect results on x86_64 (CVE-2017-3732)
==

Severity: Moderate

There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
similar to CVE-2015-3193 but must be treated as a separate problem.

OpenSSL 1.1.0 users should upgrade to 1.1.0d
OpenSSL 1.0.2 users should upgrade to 1.0.2k

This issue was reported to OpenSSL on 15th January 2017 by the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.

Montgomery multiplication may produce incorrect results (CVE-2016-7055)
===

Severity: Low

This issue was previously fixed in 1.1.0c and covered in security advisory
https://www.openssl.org/news/secadv/20161110.txt

OpenSSL 1.0.2k users should upgrade to 1.0.2k


Note


Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20170126.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYifonAAoJENnE0m0OYESRnhYH/1ldFYDEZ894DleZfjRrZulX
OQkEH7w6v+D6YFp8i2v6rJaDq8caOPEhzupQCxPcqYitBUnww9UzUvYJ77aBV0CG
DQ3UvE9XeEn5D7MGAGq/ut5Z5WpvlYL7n7PaciX751vpTsWTBKfGecQ8YV0aT6y+
7V7vHz6NVFnuTQDMUYs9C9aTsCDTNy3Bl84d7gYyoDWXUXds5k008g9LFRI4YQ8l
+4z+GXRVcvAFr6fKH94Yq1RMAp6cJi0RDkyuwcGhSOUwVfSLTN8+i2v4xqzKgsx1
q2qPo3+7uederE5ZaNZScl0xAzEilotxLQyy9XSVx/DDXHz0in1500qxgxNFELU=
=12E/
-END PGP SIGNATURE-
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [10 Nov 2016]


ChaCha20/Poly1305 heap-buffer-overflow (CVE-2016-7054)
==

Severity: High

TLS connections using *-CHACHA20-POLY1305 ciphersuites are susceptible to a DoS
attack by corrupting larger payloads. This can result in an OpenSSL crash. This
issue is not considered to be exploitable beyond a DoS.

OpenSSL 1.1.0 users should upgrade to 1.1.0c

This issue does not affect OpenSSL versions prior to 1.1.0

This issue was reported to OpenSSL on 25th September 2016 by Robert
Święcki (Google Security Team), and was found using honggfuzz. The fix
was developed by Richard Levitte of the OpenSSL development team.

CMS Null dereference (CVE-2016-7053)


Severity: Moderate

Applications parsing invalid CMS structures can crash with a NULL pointer
dereference. This is caused by a bug in the handling of the ASN.1 CHOICE type
in OpenSSL 1.1.0 which can result in a NULL value being passed to the structure
callback if an attempt is made to free certain invalid encodings. Only CHOICE
structures using a callback which do not handle NULL value are affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0c

This issue does not affect OpenSSL versions prior to 1.1.0

This issue was reported to OpenSSL on 12th October 2016 by Tyler Nighswander of
ForAllSecure. The fix was developed by Stephen Henson of the OpenSSL
development team.

Montgomery multiplication may produce incorrect results (CVE-2016-7055)
===

Severity: Low

There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits. Analysis suggests that attacks against RSA, DSA
and DH private keys are impossible. This is because the subroutine in
question is not used in operations with the private key itself and an input
of the attacker's direct choice. Otherwise the bug can manifest itself as
transient authentication and key negotiation failures or reproducible
erroneous outcome of public-key operations with specially crafted input.
Among EC algorithms only Brainpool P-512 curves are affected and one
presumably can attack ECDH key negotiation. Impact was not analyzed in
detail, because pre-requisites for attack are considered unlikely. Namely
multiple clients have to choose the curve in question and the server has to
share the private key among them, neither of which is default behaviour.
Even then only clients that chose the curve will be affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0c

This issue does not affect OpenSSL versions prior to 1.0.2. Due to the low
severity of this defect we are not issuing a new 1.0.2 release at this time.
We recommend that 1.0.2 users wait for the next 1.0.2 release for the fix to
become available. The fix is also available in the OpenSSL git repository in
commit 57c4b9f6a2.

This issue was publicly reported as transient failures and was not
initially recognized as a security issue. Thanks to Richard Morgan for
providing reproducible case. The fix was developed by Andy Polyakov of
the OpenSSL development team.

Note


As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
version 1.0.1 will cease on 31st December 2016. No security updates for that
version will be provided after that date. Users of 1.0.1 are advised to
upgrade.

Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions are no longer receiving security updates.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20161110.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYJH8JAAoJENnE0m0OYESRaZwH/1S6sjqemFtHXVk77xMMbUmY
kKGJoo5/7wJQWdw9LMPoxjXDyW0fWTKI+Ly2qfP8ZwVizONndN1HCDdWPSbT9EvN
1OG6gr0BQBmlcENCBrSuGwojAtQuMd47q3IAR3ZSx5yvYby4Lg9tXk1FjvnQ600O
Z19r1lvc6efeO1fXPBqIUUPJ4y2XN7P1DDlE5UWxacN5Xn+a6cqrieuj0g1aoZ0h
rw4fEI7o3EEufYTtodos61xLqZWq8quaMuerWEq0HfEOyMGGyDkmnQkXdU0X7o4g
U17vgzM7CvN7+weBz8hVHd0RARAl21vBjYV/G1kruBxD+cYjdavzGGAf/Z1o15w=
=MmoX
-END PGP SIGNATURE-
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[David Woodhouse]

On Mon, 2016-09-26 at 10:35 +, OpenSSL wrote:

> Content-Type: text/plain; charset="iso-8859-1"

> This issue was reported to OpenSSL on 23rd September 2016 by Robert Święcki

Found by whom? Welcome to the 21st century...  :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


OpenSSL Security Advisory [26 Sep 2016]


This security update addresses issues that were caused by patches
included in our previous security update, released on 22nd September
2016.  Given the Critical severity of one of these flaws we have
chosen to release this advisory immediately to prevent upgrades to the
affected version, rather than delaying in order to provide our usual
public pre-notification.


Fix Use After Free for large message sizes (CVE-2016-6309)
==

Severity: Critical

This issue only affects OpenSSL 1.1.0a, released on 22nd September 2016.

The patch applied to address CVE-2016-6307 resulted in an issue where if a
message larger than approx 16k is received then the underlying buffer to store
the incoming message is reallocated and moved. Unfortunately a dangling pointer
to the old location is left which results in an attempt to write to the
previously freed location. This is likely to result in a crash, however it
could potentially lead to execution of arbitrary code.

OpenSSL 1.1.0 users should upgrade to 1.1.0b

This issue was reported to OpenSSL on 23rd September 2016 by Robert
Święcki (Google Security Team), and was found using honggfuzz. The fix
was developed by Matt Caswell of the OpenSSL development team.

Missing CRL sanity check (CVE-2016-7052)


Severity: Moderate

This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016.

A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0
but was omitted from OpenSSL 1.0.2i. As a result any attempt to use
CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.

OpenSSL 1.0.2i users should upgrade to 1.0.2j

The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and
Thomas Jakobi. The fix was developed by Matt Caswell of the OpenSSL development
team.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20160926.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJX6PBJAAoJENnE0m0OYESRGacIALa7/Vg0SQzqjhD/KphCdKos
BjkDcEO00y3JDyYqqQxfcrM9jSwBbrNzmHdEzBcPlvvDq9qhGwsODKbGylI2St5r
zVHw1qA60/+Hu9PjaGT24a8MX+fPjA4RObB/BGZ7ViucZzCxqqtJob73InKwM8+9
OyjTmrphbyFa/Hk/OUWVzjatzQjEN+a5QplRTR2Sd4fBZDWowrtOdPGmbBQfRRgm
AbEO5ZPaVKBoRuMk6JsR3LFymZ2FpHjLs9HNBtSmLLdzfIXxVE+uOb9b5wdAMP/3
4cTMkhfeS3RF0GuMT3EyH/EuZS6KkjuE8y/aVTq5s3yhK3ah5kT85IO1ps0yDx0=
=WJwY
-END PGP SIGNATURE-
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


OpenSSL Security Advisory [22 Sep 2016]


OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
=

Severity: High

A malicious client can send an excessively large OCSP Status Request extension.
If that client continually requests renegotiation, sending a large OCSP Status
Request extension each time, then there will be unbounded memory growth on the
server. This will eventually lead to a Denial Of Service attack through memory
exhaustion. Servers with a default configuration are vulnerable even if they do
not support OCSP. Builds using the "no-ocsp" build time option are not affected.

Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default
configuration, instead only if an application explicitly enables OCSP stapling
support.

OpenSSL 1.1.0 users should upgrade to 1.1.0a
OpenSSL 1.0.2 users should upgrade to 1.0.2i
OpenSSL 1.0.1 users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 29th August 2016 by Shi Lei (Gear Team,
Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL
development team.

SSL_peek() hang on empty record (CVE-2016-6305)
===

Severity: Moderate

OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an
empty record. This could be exploited by a malicious peer in a Denial Of Service
attack.

OpenSSL 1.1.0 users should upgrade to 1.1.0a

This issue was reported to OpenSSL on 10th September 2016 by Alex Gaynor. The
fix was developed by Matt Caswell of the OpenSSL development team.

SWEET32 Mitigation (CVE-2016-2183)
==

Severity: Low

SWEET32 (https://sweet32.info) is an attack on older block cipher algorithms
that use a block size of 64 bits. In mitigation for the SWEET32 attack DES based
ciphersuites have been moved from the HIGH cipherstring group to MEDIUM in
OpenSSL 1.0.1 and OpenSSL 1.0.2.  OpenSSL 1.1.0 since release has had these
ciphersuites disabled by default.

OpenSSL 1.0.2 users should upgrade to 1.0.2i
OpenSSL 1.0.1 users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 16th August 2016 by Karthikeyan
Bhargavan and Gaetan Leurent (INRIA). The fix was developed by Rich Salz of the
OpenSSL development team.

OOB write in MDC2_Update() (CVE-2016-6303)
==

Severity: Low

An overflow can occur in MDC2_Update() either if called directly or
through the EVP_DigestUpdate() function using MDC2. If an attacker
is able to supply very large amounts of input data after a previous
call to EVP_EncryptUpdate() with a partial block then a length check
can overflow resulting in a heap corruption.

The amount of data needed is comparable to SIZE_MAX which is impractical
on most platforms.

OpenSSL 1.0.2 users should upgrade to 1.0.2i
OpenSSL 1.0.1 users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 11th August 2016 by Shi Lei (Gear Team,
Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
development team.

Malformed SHA512 ticket DoS (CVE-2016-6302)
===

Severity: Low

If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a
DoS attack where a malformed ticket will result in an OOB read which will
ultimately crash.

The use of SHA512 in TLS session tickets is comparatively rare as it requires
a custom server callback and ticket lookup mechanism.

OpenSSL 1.0.2 users should upgrade to 1.0.2i
OpenSSL 1.0.1 users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 19th August 2016 by Shi Lei (Gear Team,
Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
development team.

OOB write in BN_bn2dec() (CVE-2016-2182)


Severity: Low

The function BN_bn2dec() does not check the return value of BN_div_word().
This can cause an OOB write if an application uses this function with an
overly large BIGNUM. This could be a problem if an overly large certificate
or CRL is printed out from an untrusted source. TLS is not affected because
record limits will reject an oversized certificate before it is parsed.

OpenSSL 1.0.2 users should upgrade to 1.0.2i
OpenSSL 1.0.1 users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 2nd August 2016 by Shi Lei (Gear Team,
Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL
development team.

OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
==

Severity: Low

The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is
the total length the OID text representation would use and not the amount
of data written. This will result in OOB reads when large OIDs are presented.

OpenSSL 1.0.2 users should upgrade to 1.0.2i
OpenSSL 1.0.1 us

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [3rd May 2016]


Memory corruption in the ASN.1 encoder (CVE-2016-2108)
==

Severity: High

This issue affected versions of OpenSSL prior to April 2015. The bug
causing the vulnerability was fixed on April 18th 2015, and released
as part of the June 11th 2015 security releases. The security impact
of the bug was not known at the time.

In previous versions of OpenSSL, ASN.1 encoding the value zero
represented as a negative integer can cause a buffer underflow
with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does
not normally create "negative zeroes" when parsing ASN.1 input, and
therefore, an attacker cannot trigger this bug.

However, a second, independent bug revealed that the ASN.1 parser
(specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag
as a negative zero value. Large universal tags are not present in any
common ASN.1 structures (such as X509) but are accepted as part of ANY
structures.

Therefore, if an application deserializes untrusted ASN.1 structures
containing an ANY field, and later reserializes them, an attacker may
be able to trigger an out-of-bounds write. This has been shown to
cause memory corruption that is potentially exploitable with some
malloc implementations.

Applications that parse and re-encode X509 certificates are known to
be vulnerable. Applications that verify RSA signatures on X509
certificates may also be vulnerable; however, only certificates with
valid signatures trigger ASN.1 re-encoding and hence the
bug. Specifically, since OpenSSL's default TLS X509 chain verification
code verifies the certificate chain from root to leaf, TLS handshakes
could only be targeted with valid certificates issued by trusted
Certification Authorities.

OpenSSL 1.0.2 users should upgrade to 1.0.2c
OpenSSL 1.0.1 users should upgrade to 1.0.1o

This vulnerability is a combination of two bugs, neither of which
individually has security impact. The first bug (mishandling of
negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala
(Red Hat) and independently by Hanno Böck in April 2015. The second
issue (mishandling of large universal tags) was found using libFuzzer,
and reported on the public issue tracker on March 1st 2016. The fact
that these two issues combined present a security vulnerability was
reported by David Benjamin (Google) on March 31st 2016. The fixes were
developed by Steve Henson of the OpenSSL development team, and David
Benjamin.  The OpenSSL team would also like to thank Mark Brand and
Ian Beer from the Google Project Zero team for their careful analysis
of the impact.

The fix for the "negative zero" memory corruption bug can be
identified by commits

3661bb4e7934668bd99ca777ea8b30eedfafa871 (1.0.2)
and
32d3b0f52f77ce86d53f38685336668d47c5bdfe (1.0.1)

Padding oracle in AES-NI CBC MAC check (CVE-2016-2107)
==

Severity: High

A MITM attacker can use a padding oracle attack to decrypt traffic
when the connection uses an AES CBC cipher and the server support
AES-NI.

This issue was introduced as part of the fix for Lucky 13 padding
attack (CVE-2013-0169). The padding check was rewritten to be in
constant time by making sure that always the same bytes are read and
compared against either the MAC or padding bytes. But it no longer
checked that there was enough data to have both the MAC and padding
bytes.

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 13th of April 2016 by Juraj
Somorovsky using TLS-Attacker. The fix was developed by Kurt Roeckx
of the OpenSSL development team.

EVP_EncodeUpdate overflow (CVE-2016-2105)
=

Severity: Low

An overflow can occur in the EVP_EncodeUpdate() function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption.

Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by the
PEM_write_bio* family of functions. These are mainly used within the OpenSSL
command line applications. These internal uses are not considered vulnerable
because all calls are bounded with length checks so no overflow is possible.
User applications that call these APIs directly with large amounts of untrusted
data may be vulnerable. (Note: Initial analysis suggested that the
PEM_write_bio* were vulnerable, and this is reflected in the patch commit
message. This is no longer believed to be the case).

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

This issue was reported to OpenSSL on 3rd March 2016 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

EVP_En

Re: [openssl-dev] OpenSSL Security Advisory

[Hubert Kario]

On Tuesday 01 March 2016 19:50:51 Nounou Dadoun wrote:
> I'm interested in your tlsfuzzer tool (of which this appears to be a
> part), is there a larger test suite available?  Is there any
> documentation out there?
> Thanks again .. N

No, for now there isn't one. The plan is to have a full featured 
"engine" for running reproducers like this one before working on writing 
more detailed and comprehensive test cases, and later still, automated 
generation of test cases (so that it really is a fuzzer for a TLS 
protocol).

All documentation is on github, if you have questions feel free to mail 
me or open tickets.

If you are interested in helping the project, I can for now only point 
you to a project that implements the crypto itself, for later use in 
tlsfuzzer, here:
https://github.com/tomato42/tlslite-ng/issues

As I'm not sure that the tlsfuzzer architecture is correct for task at 
hand, for now I'm not asking for help on it directly, I'd prefer not to 
have to throw away somebody else's months of work because the whole 
approach of tlsfuzzer was incorrect...
That being said, I'm open for test ideas.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] OpenSSL Security Advisory

[Salz, Rich]

> I am a bit surprised with the following assertion concerning CVE-2016-0798 :
> (Memory leak in SRP database lookups)
> "This issue was discovered on February 23rd 2016..."

Yes, Michel, sorry.  You did create a ticket:
https://rt.openssl.org/Ticket/Display.html?id=4172

Thanks for being so good-natured about the oversight.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] OpenSSL Security Advisory

[Michel]

Hi,

I am a bit surprised with the following assertion concerning CVE-2016-0798 :
(Memory leak in SRP database lookups)
"This issue was discovered on February 23rd 2016..."

My opinion is that this issue is known at least since I reported it to you
(first in march 2015 !) :
https://mta.openssl.org/pipermail/openssl-dev/2015-March/001015.html
https://mta.openssl.org/pipermail/openssl-bugs-mod/2015-December/000279.html

This is s a further demonstration that I still have to improve my english !
;-)

Regards,

Michel.



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Nounou Dadoun]

Thanks for the test tool and making it available so quickly, we were able to 
close our DROWN bug ticket less than an hour after opening it!

I'm interested in your tlsfuzzer tool (of which this appears to be a part), is 
there a larger test suite available?  Is there any documentation out there?
Thanks again .. N

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Hubert 
Kario
Sent: Tuesday, March 01, 2016 7:22 AM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] OpenSSL Security Advisory

Scripts to verify that a server is not vulnerable to DROWN.


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Hubert Kario]

Scripts to verify that a server is not vulnerable to DROWN.

Two scripts are provided to verify that SSLv2 and all of its ciphers are 
disabled and that export grade SSLv2 are disabled and can't be forced by 
client.

Reproducer requires Python 2.6 or 3.2 or later, you will also need git 
to download the sources

# Download the reproducer:
git clone https://github.com/tomato42/tlsfuzzer
cd tlsfuzzer
git checkout ssl2

# Download the reproducer dependencies
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
pushd .tlslite-ng
# likely won't be necessary in near future, code will be merged soon
git checkout sslv2
popd
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa


To verify that an https server at example.com does not support SSLv2 at 
all, use the following command:

PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py \
-h example.com -p 443

To only verify that the server does not support export grade SSLv2 
ciphers, use the following command:

PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h example.com \
-p 443

(note, the first script is a superset of the second one)

In both cases all the individual tests in the scripts should print "OK" 
status if the specific cipher is not supported and report "failed: 0" 
together with exit status of 0 if you want to automate it.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [1st March 2016]
=

NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by default, as
well as removing SSLv2 EXPORT ciphers.  We strongly advise against the use of
SSLv2 due not only to the issues described below, but to the other known
deficiencies in the protocol as described at
https://tools.ietf.org/html/rfc6176


Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800)


Severity: High

A cross-protocol attack was discovered that could lead to decryption of TLS
sessions by using a server supporting SSLv2 and EXPORT cipher suites as a
Bleichenbacher RSA padding oracle.  Note that traffic between clients and
non-vulnerable servers can be decrypted provided another server supporting
SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or
POP) shares the RSA keys of the non-vulnerable server. This vulnerability is
known as DROWN (CVE-2016-0800).

Recovering one session key requires the attacker to perform approximately 2^50
computation, as well as thousands of connections to the affected server. A more
efficient variant of the DROWN attack exists against unpatched OpenSSL servers
using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on
19/Mar/2015 (see CVE-2016-0703 below).

Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS
servers, if they've not done so already. Disabling all SSLv2 ciphers is also
sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and
1.0.2f) have been deployed.  Servers that have not disabled the SSLv2 protocol,
and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2
ciphers are nominally disabled, because malicious clients can force the use of
SSLv2 with EXPORT ciphers.

OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN:

SSLv2 is now by default disabled at build-time.  Builds that are not configured
with "enable-ssl2" will not support SSLv2.  Even if "enable-ssl2" is used,
users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will
need to explicitly call either of:

   SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
   or
   SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

as appropriate.  Even if either of those is used, or the application explicitly
uses the version-specific SSLv2_method() or its client or server variants,
SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed.
Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no
longer available.

In addition, weak ciphers in SSLv3 and up are now disabled in default builds of
OpenSSL.  Builds that are not configured with "enable-weak-ssl-ciphers" will
not provide any "EXPORT" or "LOW" strength ciphers.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on December 29th 2015 by Nimrod Aviram and
Sebastian Schinzel. The fix was developed by Viktor Dukhovni and Matt Caswell
of OpenSSL.


Double-free in DSA code (CVE-2016-0705)
===

Severity: Low

A double free bug was discovered when OpenSSL parses malformed DSA private keys
and could lead to a DoS attack or memory corruption for applications that
receive DSA private keys from untrusted sources.  This scenario is considered
rare.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 7th 2016 by Adam Langley
(Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen Henson
of OpenSSL.


Memory leak in SRP database lookups (CVE-2016-0798)
===

Severity: Low

The SRP user database lookup method SRP_VBASE_get_by_user had
confusing memory management semantics; the returned pointer was sometimes newly
allocated, and sometimes owned by the callee. The calling code has no way of
distinguishing these two cases.

Specifically, SRP servers that configure a secret seed to hide valid
login information are vulnerable to a memory leak: an attacker
connecting with an invalid username can cause a memory leak of around
300 bytes per connection.  Servers that do not configure SRP, or
configure SRP but do not configure a seed are not vulnerable.

In Apache, the seed directive is known as SSLSRPUnknownUserSeed.

To mitigate the memory leak, the seed handling in
SRP_VBASE_get_by_user is now disabled even if the user has configured
a seed.  Applications are advised to migrate to
SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong
guarantees about the indistinguishability of valid and invalid
logins. In particular, computations are currently not

Re: [openssl-dev] OpenSSL Security Advisory

[Rainer Jung]

Hi there,

reading the last advisory again, I noticed, that there's one logical 
inconsistency.


First:

OpenSSL before 1.0.2f will reuse the key if:
...
- Static DH ciphersuites are used. The key is part of the certificate 
and so it will always reuse it. This is only supported in 1.0.2.



and then:

It will not reuse the key for DHE ciphers suites if:
- SSL_OP_SINGLE_DH_USE is set
...

So what's the situation if both situations apply, static DH ciphersuites 
are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is 
stronger? Will the key be reused? Or is that combination impossible? It 
doesn't seem to be clear to me from the wording in the advisory.


Thanks for any clarification.

Regards,

Rainer
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Kurt Roeckx]

On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote:
> Hi there,
> 
> reading the last advisory again, I noticed, that there's one logical
> inconsistency.
> 
> First:
> 
> OpenSSL before 1.0.2f will reuse the key if:
> ...
> - Static DH ciphersuites are used. The key is part of the certificate and so
> it will always reuse it. This is only supported in 1.0.2.
> 
> 
> and then:
> 
> It will not reuse the key for DHE ciphers suites if:
> - SSL_OP_SINGLE_DH_USE is set
> ...
> 
> So what's the situation if both situations apply, static DH ciphersuites are
> used and SSL_OP_SINGLE_DH_USE is set is set.

Note that it says DHE ciphers, excluding the DH ciphers.


Kurt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Matt Caswell]

On 02/02/16 21:34, Rainer Jung wrote:
> Hi there,
> 
> reading the last advisory again, I noticed, that there's one logical
> inconsistency.
> 
> First:
> 
> OpenSSL before 1.0.2f will reuse the key if:
> ...
> - Static DH ciphersuites are used. The key is part of the certificate
> and so it will always reuse it. This is only supported in 1.0.2.
> 
> 
> and then:
> 
> It will not reuse the key for DHE ciphers suites if:
> - SSL_OP_SINGLE_DH_USE is set
> ...
> 
> So what's the situation if both situations apply, static DH ciphersuites
> are used and SSL_OP_SINGLE_DH_USE is set is set. Which of these is
> stronger? Will the key be reused? Or is that combination impossible? It
> doesn't seem to be clear to me from the wording in the advisory.

DH ciphersuites come in two forms: static DH and ephemeral DH (aka DHE).
You can't have both at the same time. SSL_OP_SINGLE_DH_USE does not
apply to static DH ciphersuites.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Rainer Jung]

Am 03.02.2016 um 00:30 schrieb Kurt Roeckx:

On Tue, Feb 02, 2016 at 10:34:32PM +0100, Rainer Jung wrote:

Hi there,

reading the last advisory again, I noticed, that there's one logical
inconsistency.

First:

OpenSSL before 1.0.2f will reuse the key if:
...
- Static DH ciphersuites are used. The key is part of the certificate and so
it will always reuse it. This is only supported in 1.0.2.


and then:

It will not reuse the key for DHE ciphers suites if:
- SSL_OP_SINGLE_DH_USE is set
...

So what's the situation if both situations apply, static DH ciphersuites are
used and SSL_OP_SINGLE_DH_USE is set is set.


Note that it says DHE ciphers, excluding the DH ciphers.


Thanks Matt and Kurt for enlightening me.

Regards,

Rainer

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Blumenthal, Uri - 0553 - MITLL]

+1

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Hanno Böck
Sent: Friday, January 29, 2016 06:18
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Cc: open...@openssl.org
Subject: Re: [openssl-dev] OpenSSL Security Advisory

On Thu, 28 Jan 2016 15:05:47 +
OpenSSL <open...@openssl.org> wrote:

> Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by
> default and cannot be disabled. This could have some performance
> impact.

I think it's good that this has been changed now.
I found this ephemeral key reuse always problematic.

However as far as I'm aware there's still the same situation with
elliptic curve diffie hellman. It reuses the ephemeral key for several
connections unless one sets SSL_OP_SINGLE_ECDH_USE.
As with the DH one most server apps already set this.

This is unrelated to the current vuln, but I find this risky. It
creates an additional server secret that can leak and bugs in the
elliptic curve key exchange that would be harmless without this feature
could become very severe.

I would therefore propose to do the same change also for ECDH and make
SSL_OP_SINGLE_ECDH_USE the default.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [28th Jan 2016]
=

NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO
SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME SECURITY FIXES
ONLY ARE BEING APPLIED.

DH small subgroups (CVE-2016-0701)
==

Severity: High

Historically OpenSSL usually only ever generated DH parameters based on "safe"
primes. More recently (in version 1.0.2) support was provided for generating
X9.42 style parameter files such as those required for RFC 5114 support. The
primes used in such files may not be "safe". Where an application is using DH
configured with parameters based on primes that are not "safe" then an attacker
could use this fact to find a peer's private DH exponent. This attack requires
that the attacker complete multiple handshakes in which the peer uses the same
private DH exponent. For example this could be used to discover a TLS server's
private DH exponent if it's reusing the private DH exponent or it's using a
static DH ciphersuite.

OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS.
It is not on by default. If the option is not set then the server reuses the
same private DH exponent for the life of the server process and would be
vulnerable to this attack. It is believed that many popular applications do set
this option and would therefore not be at risk.

OpenSSL before 1.0.2f will reuse the key if:
- - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is 
not
  set.
- - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both 
the
  parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is
  an undocumted feature and parameter files don't contain the key.
- - Static DH ciphersuites are used. The key is part of the certificate and
  so it will always reuse it. This is only supported in 1.0.2.

It will not reuse the key for DHE ciphers suites if:
- - SSL_OP_SINGLE_DH_USE is set
- - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the
  callback does not provide the key, only the parameters. The callback is
  almost always used like this.

Non-safe primes are generated by OpenSSL when using:
- - genpkey with the dh_rfc5114 option. This will write an X9.42 style file
  including the prime-order subgroup size "q". This is supported since the 1.0.2
  version. Older versions can't read files generated in this way.
- - dhparam with the -dsaparam option. This has always been documented as
  requiring the single use.

The fix for this issue adds an additional check where a "q" parameter is
available (as is the case in X9.42 based parameters). This detects the
only known attack, and is the only possible defense for static DH ciphersuites.
This could have some performance impact.

Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default
and cannot be disabled. This could have some performance impact.

This issue affects OpenSSL version 1.0.2.

OpenSSL 1.0.2 users should upgrade to 1.0.2f

OpenSSL 1.0.1 is not affected by this CVE because it does not support X9.42
based parameters. It is possible to generate parameters using non "safe" primes,
but this option has always been documented as requiring single use and is not
the default or believed to be common. However, as a precaution, the
SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r.

This issue was reported to OpenSSL on 12 January 2016 by Antonio Sanso (Adobe).
The fix was developed by Matt Caswell of the OpenSSL development team
(incorporating some work originally written by Stephen Henson of the OpenSSL
core team).

SSLv2 doesn't block disabled ciphers (CVE-2015-3197)


Severity: Low

A malicious client can negotiate SSLv2 ciphers that have been disabled on the
server and complete SSLv2 handshakes even if all SSLv2 ciphers have been
disabled, provided that the SSLv2 protocol was not also disabled via
SSL_OP_NO_SSLv2.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2f
OpenSSL 1.0.1 users should upgrade to 1.0.1r

This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram and
Sebastian Schinzel. The fix was developed by Nimrod Aviram with further
development by Viktor Dukhovni of the OpenSSL development team.


An update on DHE man-in-the-middle protection (Logjam)


A previously published vulnerability in the TLS protocol allows a
man-in-the-middle attacker to downgrade vulnerable TLS connections
using ephemeral Diffie-Hellman key exchange to 512-bit export-grade
cryptography. This vulnerability is known as Logjam
(CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by
rejecting handshakes

[openssl-dev] Updated OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [3 Dec 2015] - Updated [4 Dec 2015]
=

[Updated 4 Dec 2015]: This advisory has been updated to include the details of
CVE-2015-1794, a Low severity issue affecting OpenSSL 1.0.2 which had a fix
included in the released packages but was missed from the advisory text.

NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE
0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS
PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS.

BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193)
==

Severity: Moderate

There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites.

This issue affects OpenSSL version 1.0.2.

OpenSSL 1.0.2 users should upgrade to 1.0.2e

This issue was reported to OpenSSL on August 13 2015 by Hanno
Böck. The fix was developed by Andy Polyakov of the OpenSSL
development team.

Certificate verify crash with missing PSS parameter (CVE-2015-3194)
===

Severity: Moderate

The signature verification routines will crash with a NULL pointer dereference
if presented with an ASN.1 signature using the RSA PSS algorithm and absent
mask generation function parameter. Since these routines are used to verify
certificate signature algorithms this can be used to crash any certificate
verification operation and exploited in a DoS attack. Any application which
performs certificate verification is vulnerable including OpenSSL clients and
servers which enable client authentication.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2e
OpenSSL 1.0.1 users should upgrade to 1.0.1q

This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne
(Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL
development team.

X509_ATTRIBUTE memory leak (CVE-2015-3195)
==

Severity: Moderate

When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak
memory. This structure is used by the PKCS#7 and CMS routines so any
application which reads PKCS#7 or CMS data from untrusted sources is affected.
SSL/TLS is not affected.

This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2e
OpenSSL 1.0.1 users should upgrade to 1.0.1q
OpenSSL 1.0.0 users should upgrade to 1.0.0t
OpenSSL 0.9.8 users should upgrade to 0.9.8zh

This issue was reported to OpenSSL on November 9 2015 by Adam Langley
(Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen
Henson of the OpenSSL development team.

Race condition handling PSK identify hint (CVE-2015-3196)
=

Severity: Low

If PSK identity hints are received by a multi-threaded client then
the values are wrongly updated in the parent SSL_CTX structure. This can
result in a race condition potentially leading to a double free of the
identify hint data.

This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously
listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0
and has not been previously fixed in an OpenSSL 1.0.0 release.

OpenSSL 1.0.2 users should upgrade to 1.0.2d
OpenSSL 1.0.1 users should upgrade to 1.0.1p
OpenSSL 1.0.0 users should upgrade to 1.0.0t

The fix for this issue can be identified in the OpenSSL git repository by commit
ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0).

The fix was developed by Dr. Stephen Henson of the OpenSSL development team.

Anon DH ServerKeyExchange with 0 p parameter (CVE-2015-1794)


Severity: Low

If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with
the value of p set to 0 then a seg fault can occur leading to a possible denial
of service attack.

This issue affects OpenSSL version 1.0.2.

OpenSSL 1.0.2 users should upgrade

Re: [openssl-dev] [openssl-users] OpenSSL Security Advisory

[Viktor Dukhovni]

On Thu, Jul 09, 2015 at 01:13:30PM +, Salz, Rich wrote:

  This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.
 
 In other words, if you are not using those specific releases -- i.e., the
 ones that came out less than 30 days ago -- you do not need to upgrade.

More accurately, you should upgrade anyway, to address the issues
resolved by those earlier releases, even though the specific issue
in the most recent release applies only to its immediate predecessors.

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [9 Jul 2015]
===

Alternative chains certificate forgery (CVE-2015-1793)
==

Severity: High

During certificate verification, OpenSSL (starting from version 1.0.1n and
1.0.2b) will attempt to find an alternative certificate chain if the first
attempt to build such a chain fails. An error in the implementation of this
logic can mean that an attacker could cause certain checks on untrusted
certificates to be bypassed, such as the CA flag, enabling them to use a valid
leaf certificate to act as a CA and issue an invalid certificate.

This issue will impact any application that verifies certificates including
SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d
OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p

This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David
Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project.

Note


As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
releases will be provided after that date. Users of these releases are advised
to upgrade.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20150709.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVnml8AAoJENnE0m0OYESRlcYH/iUe62/m2oZiuBHkKQvLBUbH
VrLDp7xEXEg6ozByLyxughAFwY9XD2r9WkXehxw66af2pmNHphXH3Gbfpcebki0r
HuZJ3CbGD/RSomWdAqkzRfV8MjNxmN4Pyi+sTsf7F+nKv80Ts51iUN1pPjkddAR8
ooKw0VMIENeMboWQ9SyQ3r7TYYywK+lXUG71Ekva9ByzABBwC/1CzZeSLJmuewnJ
+9TjwQ4otH/mUJ/klvw+G2eTSn64AnA6UEFR+sBL4aNpIgdrtjonJRt2ko05Z92N
HN/ibu5okd3iUbtkM0dTMGAr2NCrNYPr2dYLMPemwkAq1cRlhjGouRDDeb6TUYk=
=oUAa
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Salz, Rich]

 
 This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

In other words, if you are not using those specific releases -- i.e., the ones 
that came out less than 30 days ago -- you do not need to upgrade.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL Security Advisory

[Steffen Nurpmeso]

Huhu!!

 |Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx

I just want to mention these «UTF-8 re-encoded as UTF-8» issues,
which may be acceptable for names of males, but, but
*particularly* with respect to the natural beauty of the affected
person…  On the other hand i always knew engineers have the
etiquettes of construction workers.
The good news: it seems to be a long way to Boko Haram.  Still.


Also it is a real pity that it seems to be too hard to copy and
paste the NEWS.  And now it didn't even help to point one of those
HTML monsters to the cesspool.
Wait.  I haven't said there is a coincidence.


(^_^)/

--steffen
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [11 Jun 2015]
===

DHE man-in-the-middle protection (Logjam)


A vulnerability in the TLS protocol allows a man-in-the-middle
attacker to downgrade vulnerable TLS connections using ephemeral
Diffie-Hellman key exchange to 512-bit export-grade cryptography. This
vulnerability is known as Logjam (CVE-2015-4000).

OpenSSL has added protection for TLS clients by rejecting handshakes
with DH parameters shorter than 768 bits. This limit will be increased
to 1024 bits in a future release.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n

Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx
of the OpenSSL development team.

Malformed ECParameters causes infinite loop (CVE-2015-1788)
===

Severity: Moderate

When processing an ECParameters structure OpenSSL enters an infinite loop if
the curve specified is over a specially malformed binary polynomial field.

This can be used to perform denial of service against any
system which processes public keys, certificate requests or
certificates.  This includes TLS clients and TLS servers with
client authentication enabled.

This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent
1.0.0 and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are
affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0d (and below) users should upgrade to 1.0.0s
OpenSSL 0.9.8r (and below) users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 6th April 2015 by Joseph Birr-Pixton. The
fix was developed by Andy Polyakov of the OpenSSL development team.

Exploitable out-of-bounds read in X509_cmp_time (CVE-2015-1789)
===

Severity: Moderate

X509_cmp_time does not properly check the length of the ASN1_TIME
string and can read a few bytes out of bounds. In addition,
X509_cmp_time accepts an arbitrary number of fractional seconds in the
time string.

An attacker can use this to craft malformed certificates and CRLs of
various sizes and potentially cause a segmentation fault, resulting in
a DoS on applications that verify certificates or CRLs. TLS clients
that verify CRLs are affected. TLS clients and servers with client
authentication enabled may be affected if they use custom verification
callbacks.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 8th April 2015 by Robert Swiecki
(Google), and independently on 11th April 2015 by Hanno Böck. The fix
was developed by Emilia Käsper of the OpenSSL development team.

PKCS7 crash with missing EnvelopedContent (CVE-2015-1790)
=

Severity: Moderate

The PKCS#7 parsing code does not handle missing inner EncryptedContent
correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs
with missing content and trigger a NULL pointer dereference on parsing.

Applications that decrypt PKCS#7 data or otherwise parse PKCS#7
structures from untrusted sources are affected. OpenSSL clients and
servers are not affected.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 18th April 2015 by  Michal
Zalewski (Google). The fix was developed by Emilia Käsper of the
OpenSSL development team.

CMS verify infinite loop with unknown hash function (CVE-2015-1792)
===

Severity: Moderate

When verifying a signedData message the CMS code can enter an infinite loop
if presented with an unknown hash function OID.

This can be used to perform denial of service against any system which
verifies signedData messages using the CMS code.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2b
OpenSSL 1.0.1 users should upgrade to 1.0.1n
OpenSSL 1.0.0 users should upgrade to 1.0.0s
OpenSSL 0.9.8 users should upgrade to 0.9.8zg

This issue was reported to OpenSSL on 31st March 2015 by Johannes Bauer. The
fix was developed by Dr. Stephen Henson of the OpenSSL development team.

Race condition handling NewSessionTicket (CVE-2015-1791)


Severity: Low

If a NewSessionTicket is received by a multi-threaded client

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [19 Mar 2015]
===

OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291)
=

Severity: High

If a client connects to an OpenSSL 1.0.2 server and renegotiates with an
invalid signature algorithms extension a NULL pointer dereference will occur.
This can be exploited in a DoS attack against the server.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was was reported to OpenSSL on 26th February 2015 by David Ramos
of Stanford University. The fix was developed by Stephen Henson and Matt
Caswell of the OpenSSL development team.

Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)


Severity: High

This security issue was previously announced by the OpenSSL project and
classified as low severity. This severity rating has now been changed to
high.

This was classified low because it was originally thought that server RSA
export ciphersuite support was rare: a client was only vulnerable to a MITM
attack against a server which supports an RSA export ciphersuite. Recent
studies have shown that RSA export ciphersuites support is far more common.

This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team. It was previously announced in the OpenSSL
security advisory on 8th January 2015.

Multiblock corrupted pointer (CVE-2015-0290)


Severity: Moderate

OpenSSL 1.0.2 introduced the multiblock performance improvement. This feature
only applies on 64 bit x86 architecture platforms that support AES NI
instructions. A defect in the implementation of multiblock can cause OpenSSL's
internal write buffer to become incorrectly set to NULL when using non-blocking
IO. Typically, when the user application is using a socket BIO for writing, this
will only result in a failed connection. However if some other BIO is used then
it is likely that a segmentation fault will be triggered, thus enabling a
potential DoS attack.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was reported to OpenSSL on 13th February 2015 by Daniel Danner and
Rainer Mueller. The fix was developed by Matt Caswell of the OpenSSL development
team.

Segmentation fault in DTLSv1_listen (CVE-2015-0207)
===

Severity: Moderate

The DTLSv1_listen function is intended to be stateless and processes the initial
ClientHello from many peers. It is common for user code to loop over the call to
DTLSv1_listen until a valid ClientHello is received with an associated cookie. A
defect in the implementation of DTLSv1_listen means that state is preserved in
the SSL object from one invocation to the next that can lead to a segmentation
fault. Errors processing the initial ClientHello can trigger this scenario. An
example of such an error could be that a DTLS1.0 only client is attempting to
connect to a DTLS1.2 only server.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2a.

This issue was reported to OpenSSL on 27th January 2015 by Per Allansson. The
fix was developed by Matt Caswell of the OpenSSL development team.

Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286)
===

Severity: Moderate

The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is
made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check
certificate signature algorithm consistency this can be used to crash any
certificate verification operation and exploited in a DoS attack. Any
application which performs certificate verification is vulnerable including
OpenSSL clients and servers which enable client authentication.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a
OpenSSL 1.0.1 users should upgrade to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered and fixed by Stephen Henson of the OpenSSL
development team.

Segmentation fault for invalid PSS parameters (CVE-2015-0208)
=

Severity: Moderate

The signature verification routines will crash with a NULL pointer
dereference if presented with an ASN.1 signature using the RSA PSS
algorithm and invalid parameters. Since these routines are used to verify

[openssl-dev] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [08 Jan 2015]
===

DTLS segmentation fault in dtls1_get_record (CVE-2014-3571)
===

Severity: Moderate

A carefully crafted DTLS message can cause a segmentation fault in OpenSSL due
to a NULL pointer dereference. This could lead to a Denial Of Service attack.

This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k.
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p.
OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Markus Stenberg of
Cisco Systems, Inc. The fix was developed by Stephen Henson of the OpenSSL
core team.

DTLS memory leak in dtls1_buffer_record (CVE-2015-0206)
===

Severity: Moderate

A memory leak can occur in the dtls1_buffer_record function under certain
conditions. In particular this could occur if an attacker sent repeated DTLS
records with the same sequence number but for the next epoch. The memory leak
could be exploited by an attacker in a Denial of Service attack through memory
exhaustion.

This issue affects OpenSSL versions: 1.0.1 and 1.0.0.

OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k.
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p.

This issue was reported to OpenSSL on 7th January 2015 by Chris Mueller who also
provided an initial patch. Further analysis was performed by Matt Caswell of the
OpenSSL development team, who also developed the final patch.

no-ssl3 configuration sets method to NULL (CVE-2014-3569)
=

Severity: Low

When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is
received the ssl method would be set to NULL which could later result in
a NULL pointer dereference.

This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 17th October 2014 by Frank Schmirler. The
fix was developed by Kurt Roeckx.


ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572)
==

Severity: Low

An OpenSSL client will accept a handshake using an ephemeral ECDH ciphersuite
using an ECDSA certificate if the server key exchange message is omitted. This
effectively removes forward secrecy from the ciphersuite.

This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.


RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
==

Severity: Low

An OpenSSL client will accept the use of an RSA temporary key in a non-export
RSA key exchange ciphersuite. A server could present a weak temporary key
and downgrade the security of the session.

This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.


DH client certificates accepted without verification [Server] (CVE-2015-0205)
=

Severity: Low

An OpenSSL server will accept a DH certificate for client authentication
without the certificate verify message. This effectively allows a client
to authenticate without the use of a private key. This only affects servers
which trust a client certificate authority which issues certificates
containing DH keys: these are extremely rare and hardly ever encountered.

This issue affects OpenSSL versions: 1.0.1 and 1.0.0.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.


Certificate fingerprints can be modified (CVE-2014-8275)


Severity: Low

OpenSSL accepts several non-DER-variations of certificate signature
algorithm and signature encodings. OpenSSL also does not enforce a
match between the signature algorithm between the signed and unsigned
portions

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [15 Oct 2014]
===

SRTP Memory Leak (CVE-2014-3513)


Severity: High

A flaw in the DTLS SRTP extension parsing code allows an attacker, who
sends a carefully crafted handshake message, to cause OpenSSL to fail
to free up to 64k of memory causing a memory leak. This could be
exploited in a Denial Of Service attack. This issue affects OpenSSL
1.0.1 server implementations for both SSL/TLS and DTLS regardless of
whether SRTP is used or configured. Implementations of OpenSSL that
have been compiled with OPENSSL_NO_SRTP defined are not affected.

OpenSSL 1.0.1 users should upgrade to 1.0.1j.

This issue was reported to OpenSSL on 26th September 2014, based on an original
issue and patch developed by the LibreSSL project. Further analysis of the issue
was performed by the OpenSSL team.

The fix was developed by the OpenSSL team.


Session Ticket Memory Leak (CVE-2014-3567)
==

Severity: Medium

When an OpenSSL SSL/TLS/DTLS server receives a session ticket the
integrity of that ticket is first verified. In the event of a session
ticket integrity check failing, OpenSSL will fail to free memory
causing a memory leak. By sending a large number of invalid session
tickets an attacker could exploit this issue in a Denial Of Service
attack.

OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc. 

This issue was reported to OpenSSL on 8th October 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.


SSL 3.0 Fallback protection
===

Severity: Medium

OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
to block the ability for a MITM attacker to force a protocol
downgrade.

Some client applications (such as browsers) will reconnect using a
downgraded protocol to work around interoperability bugs in older
servers. This could be exploited by an active man-in-the-middle to
downgrade connections to SSL 3.0 even if both sides of the connection
support higher protocols. SSL 3.0 contains a number of weaknesses
including POODLE (CVE-2014-3566).

OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc. 

https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00
https://www.openssl.org/~bodo/ssl-poodle.pdf

Support for TLS_FALLBACK_SCSV was developed by Adam Langley and Bodo Moeller.


Build option no-ssl3 is incomplete (CVE-2014-3568)
==

Severity: Low

When OpenSSL is configured with no-ssl3 as a build option, servers
could accept and complete a SSL 3.0 handshake, and clients could be
configured to send them.

OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc. 

This issue was reported to OpenSSL by Akamai Technologies on 14th October 2014.

The fix was developed by Akamai and the OpenSSL team.


References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv_20141015.txt

Note: the online version of the advisory may be updated with additional
details over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/about/secpolicy.html

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUPnPYAAoJENnE0m0OYESRaBsH/Au+URgDVRsG/LJT89adeBnA
jPEdxf2CV2M4aH5bs2FRES43iWQNQUtDHkmSfOfyICLHYN8no2/78QqMhPr1/euA
bRGB7+P+Epac8LRjXGR9+CJx46Oc0LqDgXdU/7nGe2qB8qo0oR6S3M+ZUsuSB6IU
XbQC0wTeDRXZKJ0dLXLj1ro7JaFd2F692XKilUVdg4cLUuK5IbxdXWzp2ttgoQGB
EbBNHSbbSbbNODUyr/oyna+c+FImAbcTOee0PuGOukEmsDQh/wofbRDb9tn0JdZw
/ZJDJtU1VVeIl+j+uU9fQ0aG/TTjPBMeT5uelA9P/t4SPh+7JDneHbuhY5GCfnI=
=ic92
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [6 Aug 2014]


Information leak in pretty printing functions (CVE-2014-3508)
=

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.


Crash with SRP ciphersuite in Server Hello message (CVE-2014-5139)
==

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.


Race condition in ssl_parse_serverhello_tlsext (CVE-2014-3509)
==

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.


Double Free when processing DTLS packets (CVE-2014-3505)


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.


DTLS memory exhaustion (CVE-2014-3506)
==

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.


DTLS memory leak from zero-length fragments (CVE-2014-3507)
===

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 anonymous EC(DH) denial of service (CVE-2014-3510)
===

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.


OpenSSL TLS protocol downgrade attack (CVE-2014-3511)
=

A flaw in the OpenSSL SSL/TLS server code causes the server

RE: OpenSSL Security Advisory

[Green, Gatewood]

Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems to 
be missing the symbol BN_consttime_swap.

Woody

Gatewood C Green Jr (Woody)
Principal Software Engineer, Product Security Champion
SIEM Engineering
McAfee. Part of Intel Security.
Direct: 208.552.8269
Mobile: 208.206.7455

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of OpenSSL
Sent: Thursday, June 05, 2014 5:54 AM
To: openssl-dev@openssl.org; openssl-us...@openssl.org; 
openssl-annou...@openssl.org
Subject: OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [05 Jun 2014]


Resend: first version contained characters which could cause signature failure.

SSL/TLS MITM vulnerability (CVE-2014-0224) 
===

An attacker using a carefully crafted handshake can force the use of weak 
keying material in OpenSSL SSL/TLS clients and servers. This can be exploited 
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify 
traffic from the attacked client and server.

The attack can only be performed between a vulnerable client *and* server. 
OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only 
known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL 
servers earlier than 1.0.1 are advised to upgrade as a precaution.

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 
1.0.0m__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Dr. Stephen Henson]

On Thu, Jun 05, 2014, Green, Gatewood wrote:

 Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems 
 to be missing the symbol BN_consttime_swap.
 

Fixed now. Workaround is to compile with no-ec: the EC algorithsm aren't
approved for FIPS operation for the FIPS capable OpenSSL 0.9.8 anyway
(not present in 1.2.* module).

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [05 Jun 2014]


SSL/TLS MITM vulnerability (CVE-2014-0224)
===

An attacker using a carefully crafted handshake can force the use of weak
keying material in OpenSSL SSL/TLS clients and servers. This can be exploited
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and 
modify traffic from the attacked client and server.

The attack can only be performed between a vulnerable client *and*
server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers
are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users
of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and
researching this issue.  This issue was reported to OpenSSL on 1st May
2014 via JPCERT/CC.

The fix was developed by Stephen Henson of the OpenSSL core team partly based
on an original patch from KIKUCHI Masashi.

DTLS recursion flaw (CVE-2014-0221)


By sending an invalid DTLS handshake to an OpenSSL DTLS client the code
can be made to recurse eventually crashing in a DoS attack.

Only applications using OpenSSL as a DTLS client are affected.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue.  This
issue was reported to OpenSSL on 9th May 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.

DTLS invalid fragment vulnerability (CVE-2014-0195)


A buffer overrun attack can be triggered by sending invalid DTLS fragments
to an OpenSSL DTLS client or server. This is potentially exploitable to
run arbitrary code on a vulnerable client or server.

Only applications using OpenSSL as a DTLS client or server affected.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

Thanks to Jüri Aedla for reporting this issue.  This issue was
reported to OpenSSL on 23rd April 2014 via HP ZDI.

The fix was developed by Stephen Henson of the OpenSSL core team.

SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
=

A flaw in the do_ssl3_write function can allow remote attackers to
cause a denial of service via a NULL pointer dereference.  This flaw
only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is
enabled, which is not the default and not common.

OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.  The fix was developed by
Matt Caswell of the OpenSSL development team.

SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
===
 
A race condition in the ssl3_read_bytes function can allow remote
attackers to inject data across sessions or cause a denial of service.
This flaw only affects multithreaded applications using OpenSSL 1.0.0
and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the
default and not common.

OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.  

Anonymous ECDH denial of service (CVE-2014-3470)


OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a
denial of service attack.

OpenSSL 0.9.8 users should upgrade to 0.9.8za
OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

Thanks to Felix Gröbert and Ivan Fratrić at Google for discovering this
issue.  This issue was reported to OpenSSL on 28th May 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.

Other issues


OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for
CVE-2014-0076: Fix for the attack described in the paper Recovering
OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack
Reported by Yuval Yarom and Naomi Benger.  This issue was previously
fixed in OpenSSL 1.0.1g.


References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20140605.txt

Note: the online version of the advisory may be updated with additional
details over time.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJTkEfyAAoJENNXdQf6QOnimvkP/0J12wcv/wq6NDfLCu8X

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [05 Jun 2014]


Resend: first version contained characters which could cause signature failure.

SSL/TLS MITM vulnerability (CVE-2014-0224)
===

An attacker using a carefully crafted handshake can force the use of weak
keying material in OpenSSL SSL/TLS clients and servers. This can be exploited
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and 
modify traffic from the attacked client and server.

The attack can only be performed between a vulnerable client *and*
server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers
are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users
of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and
researching this issue.  This issue was reported to OpenSSL on 1st May
2014 via JPCERT/CC.

The fix was developed by Stephen Henson of the OpenSSL core team partly based
on an original patch from KIKUCHI Masashi.

DTLS recursion flaw (CVE-2014-0221)


By sending an invalid DTLS handshake to an OpenSSL DTLS client the code
can be made to recurse eventually crashing in a DoS attack.

Only applications using OpenSSL as a DTLS client are affected.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue.  This
issue was reported to OpenSSL on 9th May 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.

DTLS invalid fragment vulnerability (CVE-2014-0195)


A buffer overrun attack can be triggered by sending invalid DTLS fragments
to an OpenSSL DTLS client or server. This is potentially exploitable to
run arbitrary code on a vulnerable client or server.

Only applications using OpenSSL as a DTLS client or server affected.

OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za
OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m.
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h.

Thanks to Juri Aedla for reporting this issue.  This issue was
reported to OpenSSL on 23rd April 2014 via HP ZDI.

The fix was developed by Stephen Henson of the OpenSSL core team.

SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
=

A flaw in the do_ssl3_write function can allow remote attackers to
cause a denial of service via a NULL pointer dereference.  This flaw
only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is
enabled, which is not the default and not common.

OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.  The fix was developed by
Matt Caswell of the OpenSSL development team.

SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
===
 
A race condition in the ssl3_read_bytes function can allow remote
attackers to inject data across sessions or cause a denial of service.
This flaw only affects multithreaded applications using OpenSSL 1.0.0
and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the
default and not common.

OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

This issue was reported in public.  

Anonymous ECDH denial of service (CVE-2014-3470)


OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a
denial of service attack.

OpenSSL 0.9.8 users should upgrade to 0.9.8za
OpenSSL 1.0.0 users should upgrade to 1.0.0m.
OpenSSL 1.0.1 users should upgrade to 1.0.1h.

Thanks to Felix Grobert and Ivan Fratric at Google for discovering this
issue.  This issue was reported to OpenSSL on 28th May 2014.

The fix was developed by Stephen Henson of the OpenSSL core team.

Other issues


OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for
CVE-2014-0076: Fix for the attack described in the paper Recovering
OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack
Reported by Yuval Yarom and Naomi Benger.  This issue was previously
fixed in OpenSSL 1.0.1g.


References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20140605.txt

Note: the online version of the advisory may be updated with additional
details over time.
-BEGIN PGP SIGNATURE-
Version: GnuPG

Re: OpenSSL Security Advisory

[Dr. Stephen Henson]

On Thu, Jun 05, 2014, OpenSSL wrote:

 
 OpenSSL Security Advisory [05 Jun 2014]
 
 
 Resend: first version contained characters which could cause signature 
 failure.
 

Oops, something else to add to the list of things to double check before
making a release...

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Ted Byers]

How do I determine whether or not the web servers I run are affected?  They
are Apache 2.4, built for 64 bit Windows and downloaded from Apachelounge.
I have no idea what version of openssl it was built with.  Does anyone here
know if the feature that introduces the risk can be turned off, without
introducing other risks?  If so, how?

Also, could the security keys we bought have been compromised?

Any advice on how I can protect my servers better would be appreciated.

Thanks

Ted

-- 
R.E.(Ted) Byers, Ph.D.,Ed.D.


On Mon, Apr 7, 2014 at 4:31 PM, OpenSSL open...@openssl.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 OpenSSL Security Advisory [07 Apr 2014]
 

 TLS heartbeat read overrun (CVE-2014-0160)
 ==

 A missing bounds check in the handling of the TLS heartbeat extension can
 be
 used to reveal up to 64k of memory to a connected client or server.

 Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
 1.0.1f and 1.0.2-beta1.

 Thanks for Neel Mehta of Google Security for discovering this bug and to
 Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for
 preparing the fix.

 Affected users should upgrade to OpenSSL 1.0.1g. Users unable to
 immediately
 upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

 1.0.2 will be fixed in 1.0.2-beta2.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)

 iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV
 sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/
 QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn
 zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC
 LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg
 GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/
 OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF
 Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty
 zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG
 aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za
 S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd
 J37YgDNuefzrsA+B5/o7
 =szjb
 -END PGP SIGNATURE-
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-us...@openssl.org
 Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Ali Jawad]

http://filippo.io/Heartbleed/#www.unlocator.com


On Wed, Apr 9, 2014 at 2:05 PM, Ted Byers r.ted.by...@gmail.com wrote:

 How do I determine whether or not the web servers I run are affected?
 They are Apache 2.4, built for 64 bit Windows and downloaded from
 Apachelounge.  I have no idea what version of openssl it was built with.
 Does anyone here know if the feature that introduces the risk can be turned
 off, without introducing other risks?  If so, how?

 Also, could the security keys we bought have been compromised?

 Any advice on how I can protect my servers better would be appreciated.

 Thanks

 Ted

 --
 R.E.(Ted) Byers, Ph.D.,Ed.D.


 On Mon, Apr 7, 2014 at 4:31 PM, OpenSSL open...@openssl.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 OpenSSL Security Advisory [07 Apr 2014]
 

 TLS heartbeat read overrun (CVE-2014-0160)
 ==

 A missing bounds check in the handling of the TLS heartbeat extension can
 be
 used to reveal up to 64k of memory to a connected client or server.

 Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
 1.0.1f and 1.0.2-beta1.

 Thanks for Neel Mehta of Google Security for discovering this bug and to
 Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for
 preparing the fix.

 Affected users should upgrade to OpenSSL 1.0.1g. Users unable to
 immediately
 upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

 1.0.2 will be fixed in 1.0.2-beta2.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)

 iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV
 sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/
 QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn
 zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC
 LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg
 GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/
 OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF
 Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty
 zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG
 aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za
 S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd
 J37YgDNuefzrsA+B5/o7
 =szjb
 -END PGP SIGNATURE-
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-us...@openssl.org
 Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL Security Advisory [07 Apr 2014]


TLS heartbeat read overrun (CVE-2014-0160)
==

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV
sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/
QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn
zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC
LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg
GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/
OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF
Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty
zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG
aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za
S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd
J37YgDNuefzrsA+B5/o7
=szjb
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Dr. Stephen Henson]

On Thu, Feb 07, 2013, Kurt Roeckx wrote:

 
 That would mean the following aren't in the 1.0.0 branch:
 commit b908e88ec15aa0a74805e3f2236fc4f83f2789c2
 Author: Dr. Stephen Henson st...@openssl.org
 Date:   Tue Jan 29 14:44:36 2013 +
 
 Timing fix mitigation for FIPS mode.
 We have to use EVP in FIPS mode so we can only partially mitigate
 timing differences.
 
 Make an extra call to EVP_DigestSignUpdate to hash additonal blocks
 to cover any timing differences caused by removal of padding.
 
 commit 34ab3c8c711ff79c2b768f0b17e4b2a78fd1df5d
 Author: Dr. Stephen Henson st...@openssl.org
 Date:   Thu Jan 31 23:04:39 2013 +
 
 typo.
 
 commit 04e45b52ee3be81121359cc1198fd01e38096e9f
 Author: Dr. Stephen Henson st...@openssl.org
 Date:   Fri Feb 1 13:53:43 2013 +
 
 Don't access EVP_MD_CTX internals directly.
 
 commit 8bfd4c659f180a6ce34f21c0e62956b362067fba
 Author: Andy Polyakov ap...@openssl.org
 Date:   Fri Feb 1 15:31:50 2013 +0100
 
 ssl/*: remove SSL3_RECORD-orig_len to restore binary compatibility.
 
 Kludge alert. This is arranged by passing padding length in unused
 bits of SSL3_RECORD-type, so that orig_len can be reconstructed.
 
 
 (The RedHat bug fails to mention c6b82f7ee9434d81ccbb30d4cf3126a23398d6c7
 for the 1.0.0 branch, but it's not going to build without that.)
 
 I think the first 2 just don't apply to the 1.0.0 branch, the 3rd isn't 
 important,
 but I'm worried about the last commit since it talks about binary 
 compatibility.
 

Thanks for looking through these.

Yes the first two are for FIPS only and OpenSSL 1.0.0 isn't FIPS capable so
these don't apply.

The c6b82f7ee9434d81ccbb30d4cf3126a23398d6c7 commit only affects builds which
use libeay.num such as Windows.

The last commit 8bfd4c659f180a6ce34f21c0e62956b362067fba does address a
(admittedly remote) chance of binary incompatibility. The structure being
modified is the SSL3_STATE structure which applications shouldn't be messing
with directly but nervertheless this should've been included. I'll add the
commit so it appears in the subsequent releases.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Kurt Roeckx]

On Tue, Feb 05, 2013 at 03:18:28PM +0100, OpenSSL wrote:
 OpenSSL Security Advisory [05 Feb 2013]
 
 
 SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169)
 
 
 Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling
 of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing
 differences arising during MAC processing. Details of this attack can be
 found at: http://www.isg.rhul.ac.uk/tls/
 
 All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x
 
 Note: this vulnerability is only partially mitigated when OpenSSL is used
 in conjuction with the OpenSSL FIPS Object Module and the FIPS mode of
 operation is enabled.
 
 Thanks go to Nadhem J. AlFardan and Kenneth G. Paterson of the Information
 Security Group Royal Holloway, University of London for discovering this flaw.
 
 An initial fix was prepared by Adam Langley a...@chromium.org and Emilia
 K??sper ekas...@google.com of Google. Additional refinements were added by
 Ben Laurie, Andy Polyakov and Stephen Henson of the OpenSSL group.
 
 Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y

Looking at the diff for 1.0.0k it seems to be missing commits from
the 1.0.1d version:
I believe the following commits in the 1.0.1 branch are part of the fix:
2ee798880a246d648ecddadc5b91367bee4a5d98
e130841bccfc0bb9da254dc84e23bc6a1c78a64e
6cb19b7681f600b2f165e4adc57547b097b475fd
9f27de170d1b7bef3d46d41382dc4dafde8b3900
014265eb02e26f35c8db58e2ccbf100b0b2f0072
b908e88ec15aa0a74805e3f2236fc4f83f2789c2
81ce0e14e72e8e255ad1bd9c7cfaa47a6291919c
34ab3c8c711ff79c2b768f0b17e4b2a78fd1df5d
cab13fc8473856a43556d41d8dac5605f4ba1f91
36260233e7e3396feed884d3f501283e0453c04f
d5371324d978e4096bf99b9d0fe71b2cb65d9dc8
04e45b52ee3be81121359cc1198fd01e38096e9f
8bfd4c659f180a6ce34f21c0e62956b362067fba / 
ec07246a0835a36af9d892f1e28b594018be6da1

The 1.0.0 branch has those commits:
9c00a950604aca819cee977f1dcb4b45f2af3aa6 (from 
2ee798880a246d648ecddadc5b91367bee4a5d98)
e5420be6cd09af2550b128575a675490cfba0483 (from 
e130841bccfc0bb9da254dc84e23bc6a1c78a64e)
f852b60797dc68aa86c99c4f7b905488d1538d99 (from 
014265eb02e26f35c8db58e2ccbf100b0b2f0072)
080f39539295d2c7c932e79dd670526b90a215a8
610dfc3ef4c4019394534023115226f4ed0e7204 (from 
6cb19b7681f600b2f165e4adc57547b097b475fd)
b23da2919b332fd83fa6de87caacb0651f64a3f5 (from 
9f27de170d1b7bef3d46d41382dc4dafde8b3900)
3cdaca2436643908863c6a62918b0d9703477655 (from 
cab13fc8473856a43556d41d8dac5605f4ba1f91)
11c48a0fd20d2ec091fde218449f3ba0ff1cf672 (from 
36260233e7e3396feed884d3f501283e0453c04f)
33f44acbbe83ab718ae15c0d2c6a57e802705a36 (from 
d5371324d978e4096bf99b9d0fe71b2cb65d9dc8)
c6b82f7ee9434d81ccbb30d4cf3126a23398d6c7 (from 
81ce0e14e72e8e255ad1bd9c7cfaa47a6291919c)

That would mean the following aren't in the 1.0.0 branch:
commit b908e88ec15aa0a74805e3f2236fc4f83f2789c2
Author: Dr. Stephen Henson st...@openssl.org
Date:   Tue Jan 29 14:44:36 2013 +

Timing fix mitigation for FIPS mode.
We have to use EVP in FIPS mode so we can only partially mitigate
timing differences.

Make an extra call to EVP_DigestSignUpdate to hash additonal blocks
to cover any timing differences caused by removal of padding.

commit 34ab3c8c711ff79c2b768f0b17e4b2a78fd1df5d
Author: Dr. Stephen Henson st...@openssl.org
Date:   Thu Jan 31 23:04:39 2013 +

typo.

commit 04e45b52ee3be81121359cc1198fd01e38096e9f
Author: Dr. Stephen Henson st...@openssl.org
Date:   Fri Feb 1 13:53:43 2013 +

Don't access EVP_MD_CTX internals directly.

commit 8bfd4c659f180a6ce34f21c0e62956b362067fba
Author: Andy Polyakov ap...@openssl.org
Date:   Fri Feb 1 15:31:50 2013 +0100

ssl/*: remove SSL3_RECORD-orig_len to restore binary compatibility.

Kludge alert. This is arranged by passing padding length in unused
bits of SSL3_RECORD-type, so that orig_len can be reconstructed.


(The RedHat bug fails to mention c6b82f7ee9434d81ccbb30d4cf3126a23398d6c7
for the 1.0.0 branch, but it's not going to build without that.)

I think the first 2 just don't apply to the 1.0.0 branch, the 3rd isn't 
important,
but I'm worried about the last commit since it talks about binary compatibility.


Kurt

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [05 Feb 2013]


SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169)


Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling
of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing
differences arising during MAC processing. Details of this attack can be
found at: http://www.isg.rhul.ac.uk/tls/

All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x

Note: this vulnerability is only partially mitigated when OpenSSL is used
in conjuction with the OpenSSL FIPS Object Module and the FIPS mode of
operation is enabled.

Thanks go to Nadhem J. AlFardan and Kenneth G. Paterson of the Information
Security Group Royal Holloway, University of London for discovering this flaw.

An initial fix was prepared by Adam Langley a...@chromium.org and Emilia
Käsper ekas...@google.com of Google. Additional refinements were added by
Ben Laurie, Andy Polyakov and Stephen Henson of the OpenSSL group.

Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y

TLS 1.1 and 1.2 AES-NI crash (CVE-2012-2686)
=

A flaw in the OpenSSL handling of CBC ciphersuites in TLS 1.1 and TLS 1.2 on
AES-NI supporting platforms can be exploited in a DoS attack. If you are
unsure if you are using AES-NI see References below.

Anyone using an AES-NI platform for TLS 1.2 or TLS 1.1 on OpenSSL 1.0.1c is
affected. Platforms which do not support AES-NI or versions of OpenSSL which
do not implement TLS 1.2 or 1.1 (for example OpenSSL 0.9.8 and 1.0.0) are
not affected.

Thanks go to Adam Langley a...@chromium.org for initially discovering the
bug and developing a fix and to Wolfgang Ettlingers
 wolfgang.ettlin...@gmail.com for independently discovering this issue.

Affected users should upgrade to OpenSSL 1.0.1d

OCSP invalid key DoS issue (CVE-2013-0166)


A flaw in the OpenSSL handling of OCSP response verification can be exploitedin 
a denial of service attack.

All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x

This flaw was discovered and fixed by Stephen Henson of the OpenSSL core team.

Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y.

References
==
URL for this Security Advisory:
http://www.openssl.org/news/secadv_20130204.txt
Wikipedia AES-NI description:
http://en.wikipedia.org/wiki/AES-NI

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBURETXqLSm3vylcdZAQLE2QgAuHTRN3khjkmt/NRS4hg/mT+YRD+aJMsU
mhCoqYvVuW0GVJHCY4yiBUoj0bgTfwWyazQRaWSFX8ewc/mHqNKYoVBSczb9nxqZ
Kh41maLcKGMHtDNQlb5bINa95+9Ix9+J9Izdd7dWycpApN/azCV+r/kkXVArAq8J
jYZ5Wl7PtSELArAtN5R56TgmSpcZvnIkqm7dV9rkJZGE9PBXskiLJjozWqPHgvQC
HcAXNuAgrWJjuCKimictGoC0gP+tmF7tMIqYKT8/16qAqWs4vBk/Z0rxpQ4wV6pU
6jWjcFL+dVQm/59RKtYwsnBPmXgH9zg7kS2y0xcHTWJG3EKucxe8zQ==
=BgHn
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [10 May 2012]
===

Invalid TLS/DTLS record attack (CVE-2012-2333)
===

A flaw in the OpenSSL handling of CBC mode ciphersuites in TLS 1.1, 1.2 and
DTLS can be exploited in a denial of service attack on both clients and
servers.

DTLS applications are affected in all versions of OpenSSL. TLS is only
affected in OpenSSL 1.0.1 and later.

Thanks to Codenomicon for discovering this issue using Fuzz-o-Matic fuzzing
as a service testing platform.

The fix was developed by Stephen Henson of the OpenSSL core team.

Affected users should upgrade to OpenSSL 1.0.1c, 1.0.0j or 0.9.8x

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120510.txt


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBT6w226LSm3vylcdZAQKTzgf/cksRhBmKkc5BWGXHxRuNEpr7SplMvM1k
5HcyLrlUKE4E2tredaylgYhbpy9+50e8euv8cWdD5ErBklJ9SGso2YKl/FVOSO0e
T5MyGgOeQ4jAeyLlBahw6O74bUYrO3WntVyLJDrH6gRGN1dDjenMPErPUKUQGUMw
8Yy0JXbxIVhw731ymL6Iv2DuleFZvGCdSgPXbX39qXrAe5mD5wd5jGP50f7S0mEO
mj6/3zPxAHLrn5H9XXwqgebEylQkCHWdMIxSqYihea865/BShT5lXJdLief7YDlh
YEJVquVjGlRgTJZeq6YZab5c1Lg+Jlc9cxtniQv1QaAgfryEJ5biPQ==
=/mgW
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[Mark J Cox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [24 Apr 2012]
===

ASN1 BIO incomplete fix (CVE-2012-2131)
===

It was discovered that the fix for CVE-2012-2110 released on 19 Apr
2012 was not sufficient to correct the issue for OpenSSL 0.9.8.

Please see http://www.openssl.org/news/secadv_20120419.txt for details
of that vulnerability.

This issue only affects OpenSSL 0.9.8v.  OpenSSL 1.0.1a and 1.0.0i
already contain a patch sufficient to correct CVE-2012-2110.

Thanks to Red Hat for discovering and fixing this issue.

Affected users should upgrade to 0.9.8w.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120424.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAwUBT5ZV8+6tTP1JpWPZAQIQHwQAvrWr3lRsvFkskFR1apYn/xf0l7cUABGX
HUUtmDRQJuYFyK0UMdInvcrZ7W82FhzzuGNLwnwI5b8Ttn4oOwcntM335WMf8d10
O4S7OjJmjpNEM1Lb0Ik9ZQdxJTepuWgG4iNKXtZIMdY8amCC+a0jPcwDzji2RfHP
OKUh7LxTI5E=
=HggZ
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: OpenSSL Security Advisory

[Murphy, Sandra]

Also - any idea if BBN is using OpenSSL?

--Sandy


From: owner-openssl-...@openssl.org [owner-openssl-...@openssl.org] on behalf 
of OpenSSL [open...@master.openssl.org]
Sent: Thursday, April 19, 2012 9:04 AM
To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; 
openssl-us...@master.openssl.org
Subject: OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [19 Apr 2012]
===

ASN1 BIO vulnerability (CVE-2012-2110)
===

A potentially exploitable vulnerability has been discovered in the OpenSSL
function asn1_d2i_read_bio.

Any application which uses BIO or FILE based functions to read untrusted DER
format data is vulnerable. Affected functions are of the form d2i_*_bio or
d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp.

Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc)
are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected.

Applications only using the PEM routines are not affected.

S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or
SMIME_read_CMS *are* affected.

The OpenSSL command line utility is also affected if used to process untrusted
data in DER format.

Note: although an application using the SSL/TLS portions of OpenSSL is not
automatically affected it might still call a function such as d2i_X509_bio on
untrusted data and be vulnerable.

Thanks to Tavis Ormandy, Google Security Team, for discovering this issue and
to Adam Langley a...@chromium.org for fixing it.

Affected users should upgrade to OpenSSL 1.0.1a, 1.0.0i or 0.9.8v.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120419.txt


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBT5AJh6LSm3vylcdZAQII+Af/dPNEQrJZ6YHlytaMW6zvkG64pvYBLuoO
BdJQnFBR3oWolOIQDyFD7byECly/czVHA5mTifsG+XyHeLHB5Zr2PsnLBLj3d6Su
verXPt8JU/XQb+Rhn1P9F32qTMwhZkgNcjV3eOprpUBD7qNz+nQd1pJtlKX3asmK
wtVYyX6Dbbe61GQ6nDxT4fLpAL6Yk/YJH3jRA/R4MW/0vyJzYCALKiCsFuAzp2Fl
Ov5n3Gkn+Y+1jaaGpqNxdWv1F3OI8vieC4lN4CfbaDDkQxNCNBRwcucK/tBBKAxK
3gravlQDuqnGn3M6GOpVJ89hZaPscMvsKx80jUKZtn2kPBaC7NxYeQ==
=91XR
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [19 Apr 2012]
===

ASN1 BIO vulnerability (CVE-2012-2110)
===

A potentially exploitable vulnerability has been discovered in the OpenSSL
function asn1_d2i_read_bio.

Any application which uses BIO or FILE based functions to read untrusted DER
format data is vulnerable. Affected functions are of the form d2i_*_bio or
d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp.

Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc)
are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected.

Applications only using the PEM routines are not affected.

S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or
SMIME_read_CMS *are* affected.

The OpenSSL command line utility is also affected if used to process untrusted
data in DER format.

Note: although an application using the SSL/TLS portions of OpenSSL is not
automatically affected it might still call a function such as d2i_X509_bio on
untrusted data and be vulnerable.

Thanks to Tavis Ormandy, Google Security Team, for discovering this issue and
to Adam Langley a...@chromium.org for fixing it.

Affected users should upgrade to OpenSSL 1.0.1a, 1.0.0i or 0.9.8v.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120419.txt


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBT5AJh6LSm3vylcdZAQII+Af/dPNEQrJZ6YHlytaMW6zvkG64pvYBLuoO
BdJQnFBR3oWolOIQDyFD7byECly/czVHA5mTifsG+XyHeLHB5Zr2PsnLBLj3d6Su
verXPt8JU/XQb+Rhn1P9F32qTMwhZkgNcjV3eOprpUBD7qNz+nQd1pJtlKX3asmK
wtVYyX6Dbbe61GQ6nDxT4fLpAL6Yk/YJH3jRA/R4MW/0vyJzYCALKiCsFuAzp2Fl
Ov5n3Gkn+Y+1jaaGpqNxdWv1F3OI8vieC4lN4CfbaDDkQxNCNBRwcucK/tBBKAxK
3gravlQDuqnGn3M6GOpVJ89hZaPscMvsKx80jUKZtn2kPBaC7NxYeQ==
=91XR
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Questions re: OpenSSL Security Advisory CVE-2012-2110

[Erik Tkal]

The detailed analysis for CVE-2012-2110 implies issues with truncation, 
specifically int vs long vs size_t.  Is the problem limited to platforms where 
these are different sizes?  The analysis says not limited to I32LP64, but does 
not rule out any platforms where it is not an issue.  Can it occur on ILP32 or 
ILP32LL64 platforms?



  Thanks!


Erik Tkal
Juniper OAC/UAC/Pulse Development

Re: Questions re: OpenSSL Security Advisory CVE-2012-2110

[Dr. Stephen Henson]

On Thu, Apr 19, 2012, Erik Tkal wrote:

 The detailed analysis for CVE-2012-2110 implies issues with truncation,
 specifically int vs long vs size_t.  Is the problem limited to platforms
 where these are different sizes?  The analysis says not limited to I32LP64,
 but does not rule out any platforms where it is not an issue.  Can it occur
 on ILP32 or ILP32LL64 platforms?
 

Yes: it isn't just limited to I32LP64.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL security advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [12 Mar 2012]
===

CMS and S/MIME Bleichenbacher attack (CVE-2012-0884)


A weakness in the OpenSSL CMS and PKCS #7 code can be exploited
using Bleichenbacher's attack on PKCS #1 v1.5 RSA padding
also known as the million message attack (MMA).

Only users of CMS, PKCS #7, or S/MIME decryption operations are affected. A
successful attack needs on average 2^20 messages. In practice only automated
systems will be affected as humans will not be willing to process this many
messages.

SSL/TLS applications are *NOT* affected by this problem since the 
SSL/TLS code does not use the PKCS#7 or CMS decryption code. 

Thanks to Ivan Nestlerode inestler...@us.ibm.com for discovering
this weakness.

The fix was developed by Stephen Henson of the OpenSSL core team.

Affected users should upgrade to OpenSSL 1.0.0h or 0.9.8u.

References
==

RFC3218

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120312.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBT14b4aLSm3vylcdZAQLNTAf9GZmm+2oCVvpOx1DPv/byirbrVgKzxGUe
bE+KDVFbRFt0t/MkC/CoWAQDZs7ef2E9YZ8R8jy7cEriUTbipuBIetBah2+oTZnM
j3g1LeUth8gYBy//9epcVRTtpjkZ/oZVKYsjbdWnQIgW1hTvpgaqtPRFX3aDWIZv
ArpUSG5YmX+Zg4NYwB3ZMa+je4d2jTQmItqNsTUYv6jdxYYn8LwUQfa3r3f5mkMt
usI7YP2QFaR3q0iTknMM+BmzzxNOcs/3Y4VfXASWiVVVd4i0jltSxgqsvTB2lH3G
woUBIL+tF6KylHGfu9TMdvwj17eD5Q47y94Bg/rxf+hUn/AlPjsWRw==
=aUDu
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [18 Jan 2011]
===

DTLS DoS attack (CVE-2012-0050)


A flaw in the fix to CVE-2011-4108 can be exploited in a denial of
service attack. Only DTLS applications using OpenSSL 1.0.0f and
0.9.8s are affected.


Thanks to Antonio Martin, Enterprise Secure Access Research and
Development, Cisco Systems, Inc. for discovering this bug and
preparing a fix.

Affected users should upgrade to OpenSSL 1.0.0g or 0.9.8t.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120118.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBTxbTZqLSm3vylcdZAQIVsgf/b+bSo2XrK9aWx1MCvgcz9Y1rJS8mOfLS
c1E9ZpIp2uXcHai9PNhtJ8MRW3pVpyHMxqNQ/9ULXYBjRwVl9YT2ipDBN4iZda9M
3Rh3g6vuWwbpNDNnd9xiuTVq8y7cVk1U0VXoOZ9tXIkkKgEITXiAqH1qmo9nthkT
Rv/5cgWmfplnhz0gMANHreRh3cZr/BhQaKHZAZ8Fsa2EqRHdyZagGlwspGqQab85
dT8jiNYABnQDWju28tjpMT/W8vnW0/zTXll21hbNj/R+D/L3lhLY8XNhYsoQrCZo
UIY+quRAsdggLWrFizDA3vxsEdtU1z/5yE+4bs5hzaJhTe0RJUieNw==
=Dkux
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Tomas Hoger]

On Wed,  4 Jan 2012 21:04:06 +0100 (CET) OpenSSL wrote:

 SGC Restart DoS Attack (CVE-2011-4619)
 ==
 
 Support for handshake restarts for server gated cryptograpy (SGC) can
 be used in a denial-of-service attack.

This issue seems to fall into the same category as CVE-2011-1473 that
has been asked about on openssl lists couple of times and does not seem
to have got feedback from openssl team.

http://thread.gmane.org/gmane.comp.encryption.openssl.user/43645/focus=43699
http://thread.gmane.org/gmane.comp.encryption.openssl.user/43706
http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19839

There was a request for guidance on how to best work around this in
applications, whether callback approach is the recommended one:

http://thread.gmane.org/gmane.comp.encryption.openssl.user/43304

Also some efforts to propose a fix:

http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19872

Can anyone from openssl team provide a statement on this issue and
clarify if there are any changes planned to be made in openssl (be it a
change that throttles or limits renegotiations, or makes it easier for
applications to do so), comment on what kind of openssl fix may be
acceptable, or recommend a way to best handle this in applications if no
openssl fix is planned?

Thank you!

-- 
Tomas Hoger
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [04 Jan 2012]
===

Six security flaws have been fixed in OpenSSL 1.0.0f and 0.9.8s.

DTLS Plaintext Recovery Attack (CVE-2011-4108)
==

Nadhem Alfardan and Kenny Paterson have discovered an extension of the 
Vaudenay padding oracle attack on CBC mode encryption which enables an 
efficient plaintext recovery attack against the OpenSSL implementation
of DTLS. Their attack exploits timing differences arising during
decryption processing. A research paper describing this attack can be
found at http://www.isg.rhul.ac.uk/~kp/dtls.pdf

Thanks go to Nadhem Alfardan and Kenny Paterson of the Information
Security Group at Royal Holloway, University of London
(www.isg.rhul.ac.uk) for discovering this flaw and to Robin Seggelmann
seggelm...@fh-muenster.de and Michael Tuexen tue...@fh-muenster.de
for preparing the fix.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

Double-free in Policy Checks (CVE-2011-4109)


If X509_V_FLAG_POLICY_CHECK is set in OpenSSL 0.9.8, then a policy
check failure can lead to a double-free. The bug does not occur 
unless this flag is set. Users of OpenSSL 1.0.0 are not affected.

This flaw was discovered by Ben Laurie and a fix provided by Emilia
Kasper ekas...@google.com of Google.

Affected users should upgrade to OpenSSL 0.9.8s.

Uninitialized SSL 3.0 Padding (CVE-2011-4576)
=

OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as
block cipher padding in SSL 3.0 records. This affects both clients and
servers that accept SSL 3.0 handshakes: those that call SSL_CTX_new with
SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does
not affect TLS.

As a result, in each record, up to 15 bytes of uninitialized memory
may be sent, encrypted, to the SSL peer. This could include sensitive
contents of previously freed memory.

However, in practice, most deployments do not use
SSL_MODE_RELEASE_BUFFERS and therefore have a single write buffer per
connection. That write buffer is partially filled with non-sensitive,
handshake data at the beginning of the connection and, thereafter,
only records which are longer any any previously sent record leak any
non-encrypted data. This, combined with the small number of bytes
leaked per record, serves to limit to severity of this issue.

Thanks to Adam Langley a...@chromium.org for identifying and fixing
this issue.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

Malformed RFC 3779 Data Can Cause Assertion Failures (CVE-2011-4577)


RFC 3779 data can be included in certificates, and if it is malformed,
may trigger an assertion failure. This could be used in a
denial-of-service attack.

Note, however, that in the standard release of OpenSSL, RFC 3779
support is disabled by default, and in this case OpenSSL is not
vulnerable. Builds of OpenSSL are vulnerable if configured with 
enable-rfc3779.

Thanks to Andrew Chi, BBN Technologies, for discovering the flaw, and
Rob Austein s...@hactrn.net for fixing it.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

SGC Restart DoS Attack (CVE-2011-4619)
==

Support for handshake restarts for server gated cryptograpy (SGC) can
be used in a denial-of-service attack.

Thanks to Adam Langley a...@chromium.org for identifying and fixing
this issue.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

Invalid GOST parameters DoS Attack (CVE-2012-0027)
===

A malicious TLS client can send an invalid set of GOST parameters
which will cause the server to crash due to lack of error checking.
This could be used in a denial-of-service attack.

Only users of the OpenSSL GOST ENGINE are affected by this bug.

Thanks to Andrey Kulikov amde...@gmail.com for identifying and fixing
this issue.

Affected users should upgrade to OpenSSL 1.0.0f.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120104.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBTwSwVqLSm3vylcdZAQL8nwgAtNob9cIjI0SlNW1sLrlzP9bLPpNV9o6p
+sD9jIMBKsoMZcB9ANMMgcu6bMAz5Hm+7//ff35WJP9oDN4vYnw/cAzXuj8+dclm
qQLs9jR+qkyDtjh4Oiyabvjsq7uAgEp7D88pgFK+PF+0TRaH/2hyZgGNlg1JOrNR
SoFN5rVwNhIybkMhd3kNjU8cIkA2lI0vjNqmGOafZ5xTyWhViHuvN014hRyffiNS
JE4icLuQV25DidcZkvxjuiaHiJz70DZgerSOds5H8kNeoNlIevPxPzWEaZ7HMsuL
loK+hqE/nMMaL3lk29+a7k1lcqNvljt3M5dX/CVbevvV0NCV62bojA==
=56UI
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [6 September 2011]

Two security flaws have been fixed in OpenSSL 1.0.0e

CRL verification vulnerability in OpenSSL
=

Under certain circumstances OpenSSL's internal certificate verification
routines can incorrectly accept a CRL whose nextUpdate field is in the past.
(CVE-2011-3207)

This issue applies to OpenSSL versions 1.0.0 through 1.0.0d. Versions of
OpenSSL before 1.0.0 are not affected.

Users of affected versions of OpenSSL should update to the OpenSSL 1.0.0e
release, which contains a patch to correct this issue.

Thanks to Kaspar Brand o...@velox.ch for identifying this bug and 
suggesting a fix.


TLS ephemeral ECDH crashes in OpenSSL
=

OpenSSL server code for ephemeral ECDH ciphersuites is not thread-safe, and
furthermore can crash if a client violates the protocol by sending handshake
messages in incorrect order. (CVE-2011-3210)

This issue applies to OpenSSL 0.9.8 through 0.9.8s (experimental ECCdraft
ciphersuites) and to OpenSSL 1.0.0 through 1.0.0d.

Affected users of OpenSSL should update to the OpenSSL 1.0.0e release, which
contains a patch to correct this issue. If you cannot immediately upgrade,
we recommend that you disable ephemeral ECDH ciphersuites if you have enabled
them.

Thanks to Adam Langley a...@chromium.org for identifying and fixing this
issue.

Which applications are affected
===

Applications are only affected by the CRL checking vulnerability if they enable
OpenSSL's internal CRL checking which is off by default. For example by setting
the verification flag X509_V_FLAG_CRL_CHECK or X509_V_FLAG_CRL_CHECK_ALL.
Applications which use their own custom CRL checking (such as Apache) are not
affected.

Only server-side applications that specifically support ephemeral ECDH
ciphersuites are affected by the ephemeral ECDH crash bug and only if
ephemeral ECDH ciphersuites are enabled in the configuration. You can check
to see if application supports ephemeral ECDH ciphersuites by looking for
SSL_CTX_set_tmp_ecdh, SSL_set_tmp_ecdh, SSL_CTRL_SET_TMP_ECDH,
SSL_CTX_set_tmp_ecdh_callback, SSL_set_tmp_ecdh_callback,
SSL_CTRL_SET_TMP_ECDH_CB in the source code.

References
==

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20110906.txt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBTmYhWqLSm3vylcdZAQKsnQgAsD+GwbfpXuZyhLNcHrJjTiHgfVWQLiFq
6RupYmgfxPiCrGdSEvp6Uh3Y+bcOOoDXTXujk7T6RTRU4iYiARFkXo8bUtH47dWO
AfwOyMxiM88G9TYj69RUjKNP70j1rEATIz+m4kpnDgmmsodDNsPj56k4gptsoELc
S4Cb4+97uCBv1mkVFgvu71RVXbIwqOMt/vveHUttQQLEcdu2XcUylbMarDaOcZui
e9AjYX3LoqdhPRl2v01tuJf3c8wmNTE+GtsO8hwda6eo8Mu/BAnqtFsiFRVjmJ2M
vgj1Ot/SPQHcpDu7N3V3GY4tdY8iDHWZ5FfbyaoXvzM6guS+o4cDww==
=xfeL
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Auto Reply: OpenSSL Security Advisory

[huieying . lee]

I will be on vacation from Sep/05/2011 thru Sep/16/2011  (back in the office on 
Sep 19).
Have a great day !

Huie-Ying
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[The Doctor]

On Tue, Sep 06, 2011 at 03:40:30PM +0200, OpenSSL wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 OpenSSL Security Advisory [6 September 2011]
 
 Two security flaws have been fixed in OpenSSL 1.0.0e
 
 CRL verification vulnerability in OpenSSL
 =
 
 Under certain circumstances OpenSSL's internal certificate verification
 routines can incorrectly accept a CRL whose nextUpdate field is in the past.
 (CVE-2011-3207)
 
 This issue applies to OpenSSL versions 1.0.0 through 1.0.0d. Versions of
 OpenSSL before 1.0.0 are not affected.
 
 Users of affected versions of OpenSSL should update to the OpenSSL 1.0.0e
 release, which contains a patch to correct this issue.
 
 Thanks to Kaspar Brand o...@velox.ch for identifying this bug and 
 suggesting a fix.
 
 
 TLS ephemeral ECDH crashes in OpenSSL
 =
 
 OpenSSL server code for ephemeral ECDH ciphersuites is not thread-safe, and
 furthermore can crash if a client violates the protocol by sending handshake
 messages in incorrect order. (CVE-2011-3210)
 
 This issue applies to OpenSSL 0.9.8 through 0.9.8s (experimental ECCdraft
 ciphersuites) and to OpenSSL 1.0.0 through 1.0.0d.
 
 Affected users of OpenSSL should update to the OpenSSL 1.0.0e release, which
 contains a patch to correct this issue. If you cannot immediately upgrade,
 we recommend that you disable ephemeral ECDH ciphersuites if you have enabled
 them.
 
 Thanks to Adam Langley a...@chromium.org for identifying and fixing this
 issue.
 
 Which applications are affected
 ===
 
 Applications are only affected by the CRL checking vulnerability if they 
 enable
 OpenSSL's internal CRL checking which is off by default. For example by 
 setting
 the verification flag X509_V_FLAG_CRL_CHECK or X509_V_FLAG_CRL_CHECK_ALL.
 Applications which use their own custom CRL checking (such as Apache) are not
 affected.
 
 Only server-side applications that specifically support ephemeral ECDH
 ciphersuites are affected by the ephemeral ECDH crash bug and only if
 ephemeral ECDH ciphersuites are enabled in the configuration. You can check
 to see if application supports ephemeral ECDH ciphersuites by looking for
 SSL_CTX_set_tmp_ecdh, SSL_set_tmp_ecdh, SSL_CTRL_SET_TMP_ECDH,
 SSL_CTX_set_tmp_ecdh_callback, SSL_set_tmp_ecdh_callback,
 SSL_CTRL_SET_TMP_ECDH_CB in the source code.
 
 References
 ==
 
 URL for this Security Advisory:
 http://www.openssl.org/news/secadv_20110906.txt
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQEVAwUBTmYhWqLSm3vylcdZAQKsnQgAsD+GwbfpXuZyhLNcHrJjTiHgfVWQLiFq
 6RupYmgfxPiCrGdSEvp6Uh3Y+bcOOoDXTXujk7T6RTRU4iYiARFkXo8bUtH47dWO
 AfwOyMxiM88G9TYj69RUjKNP70j1rEATIz+m4kpnDgmmsodDNsPj56k4gptsoELc
 S4Cb4+97uCBv1mkVFgvu71RVXbIwqOMt/vveHUttQQLEcdu2XcUylbMarDaOcZui
 e9AjYX3LoqdhPRl2v01tuJf3c8wmNTE+GtsO8hwda6eo8Mu/BAnqtFsiFRVjmJ2M
 vgj1Ot/SPQHcpDu7N3V3GY4tdY8iDHWZ5FfbyaoXvzM6guS+o4cDww==
 =xfeL
 -END PGP SIGNATURE-
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-us...@openssl.org
 Automated List Manager   majord...@openssl.org

Will this affect openssl 1.0.1 ?


-- 
Member - Liberal International  This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
God, Queen and country! Never Satan President Republic! Beware AntiChrist 
rising! 
https://www.fullyfollow.me/rootnl2k
IT is done!  http://groups.google.com/group/rec.arts.drwho/about
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory: OCSP stapling vulnerability

[Rob Stradling]

Bodo, some comments inline...

On Tuesday 08 Feb 2011 18:09:46 Bodo Moeller wrote:
 OpenSSL Security Advisory [8 February 2011]
 
 OCSP stapling vulnerability in OpenSSL
snip
 Which applications are affected
 ---
 
 Applications are only affected if they act as a server and call
 SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
 Apache httpd = 2.3.3.

In httpd = 2.3.3, OCSP Stapling is currently disabled by default.  To enable 
it, the SSLUseStapling On directive must be added to the config.  Since 
SSL_CTX_set_tlsext_status_cb() is only called when OCSP Stapling has been 
enabled, I conclude that the default configuration is not vulnerable.

A couple of months ago I proposed to httpd-dev that OCSP Stapling should be 
enabled by default.  Steve Henson was cautiously sympathetic to the idea...
My personal opinion would be to, at least initially, require an explicit 
directive to enable it and leave the option in future to have it enabled by 
default.
...but Igor Galić replied with...
If we want to see more extensive testing in the field, then this is the right 
time to make 'On' the default.

Maybe httpd should:
1. Check the version number of the OpenSSL runtime library.
2. Log a warning if a vulnerable OpenSSL version is detected.
3. Definitely avoid enabling Stapling by default if a vulnerable OpenSSL 
version is detected.

(Sorry, I guess I've drifted a bit off-topic for this list).

snip
 OCSP stapling is defined in RFC 2560.

RFC 2560 defines OCSP, but not OCSP Stapling.

OCSP Stapling is the popular term for the Certificate Status Request TLS 
Extension defined most recently by RFC 6066 (previous versions: RFC 4366, RFC 
3546).

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory: OCSP stapling vulnerability

[Bodo Moeller]

Thanks, Rob; I have updated the Security Advisory at
http://www.openssl.org/news/secadv_20110208.txt.

Bodo

OpenSSL Security Advisory: OCSP stapling vulnerability

[Bodo Moeller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [8 February 2011]

OCSP stapling vulnerability in OpenSSL
==

Incorrectly formatted ClientHello handshake messages could cause OpenSSL
to parse past the end of the message.

This issue applies to the following versions:
  1) OpenSSL 0.9.8h through 0.9.8q
  2) OpenSSL 1.0.0 through 1.0.0c

The parsing function in question is already used on arbitary data so no
additional vulnerabilities are expected to be uncovered by this.
However, an attacker may be able to cause a crash (denial of service) by
triggering invalid memory accesses.

The results of the parse are only availible to the application using
OpenSSL so do not directly cause an information leak. However, some
applications may expose the contents of parsed OCSP extensions,
specifically an OCSP nonce extension. An attacker could use this to read
the contents of memory following the ClientHello.

Users of OpenSSL should update to the OpenSSL 1.0.0d (or 0.9.8r) release,
which contains a patch to correct this issue. If upgrading is not
immediately possible, the source code patch provided in this advisory
should be applied.

Neel Mehta (Google) identified the vulnerability. Adam Langley and
Bodo Moeller (Google) prepared the fix.

Which applications are affected
- ---

Applications are only affected if they act as a server and call
SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
Apache httpd = 2.3.3.

Patch
- -

- --- ssl/t1_lib.c  25 Nov 2010 12:28:28 -  1.64.2.17
+++ ssl/t1_lib.c8 Feb 2011 00:00:00 -
@@ -917,6 +917,7 @@
}
n2s(data, idsize);
dsize -= 2 + idsize;
+   size -= 2 + idsize;
if (dsize  0)
{
*al = SSL_AD_DECODE_ERROR;
@@ -955,9 +956,14 @@
}
 
/* Read in request_extensions */
+   if (size  2)
+   {
+   *al = SSL_AD_DECODE_ERROR;
+   return 0;
+   }
n2s(data,dsize);
size -= 2;
- - if (dsize  size) 
+   if (dsize != size)
{
*al = SSL_AD_DECODE_ERROR;
return 0;

References
- --

This vulnerability is tracked as CVE-2011-0014.

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20110208.txt

OCSP stapling is defined in RFC 2560.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAgUBTVGA/qpYnaxaapuFAQJSqAQAo3zal2kp+/ZcBcdhXnn98kuDDJaUhCqz
tG+IpnKRqQsGqprz72cOsdlB6C1pzlaLt5tofkxVlXBiAtx1Vn8YeJwQIXAj2CEi
6edgg/w+ni1hBASZBbCQUGLfAmW5tsOxp1ShxCovwh/I+7eetzuSeDfIbB+NYpz7
p3xrSBAVwTY=
=zV3P
-END PGP SIGNATURE-



--
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory: OCSP stapling vulnerability

[Bodo Moeller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [8 February 2011]

OCSP stapling vulnerability in OpenSSL
==

Incorrectly formatted ClientHello handshake messages could cause OpenSSL
to parse past the end of the message.

This issue applies to the following versions:
  1) OpenSSL 0.9.8h through 0.9.8q
  2) OpenSSL 1.0.0 through 1.0.0c

The parsing function in question is already used on arbitary data so no
additional vulnerabilities are expected to be uncovered by this.
However, an attacker may be able to cause a crash (denial of service) by
triggering invalid memory accesses.

The results of the parse are only availible to the application using
OpenSSL so do not directly cause an information leak. However, some
applications may expose the contents of parsed OCSP extensions,
specifically an OCSP nonce extension. An attacker could use this to read
the contents of memory following the ClientHello.

Users of OpenSSL should update to the OpenSSL 1.0.0d (or 0.9.8r) release,
which contains a patch to correct this issue. If upgrading is not
immediately possible, the source code patch provided in this advisory
should be applied.

Neel Mehta (Google) identified the vulnerability. Adam Langley and
Bodo Moeller (Google) prepared the fix.

Which applications are affected
- ---

Applications are only affected if they act as a server and call
SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
Apache httpd = 2.3.3.

Patch
- -

- --- ssl/t1_lib.c  25 Nov 2010 12:28:28 -  1.64.2.17
+++ ssl/t1_lib.c8 Feb 2011 00:00:00 -
@@ -917,6 +917,7 @@
}
n2s(data, idsize);
dsize -= 2 + idsize;
+   size -= 2 + idsize;
if (dsize  0)
{
*al = SSL_AD_DECODE_ERROR;
@@ -955,9 +956,14 @@
}
 
/* Read in request_extensions */
+   if (size  2)
+   {
+   *al = SSL_AD_DECODE_ERROR;
+   return 0;
+   }
n2s(data,dsize);
size -= 2;
- - if (dsize  size) 
+   if (dsize != size)
{
*al = SSL_AD_DECODE_ERROR;
return 0;

References
- --

This vulnerability is tracked as CVE-2011-0014.

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20110208.txt

OCSP stapling is defined in RFC 2560.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAgUBTVGA/qpYnaxaapuFAQJSqAQAo3zal2kp+/ZcBcdhXnn98kuDDJaUhCqz
tG+IpnKRqQsGqprz72cOsdlB6C1pzlaLt5tofkxVlXBiAtx1Vn8YeJwQIXAj2CEi
6edgg/w+ni1hBASZBbCQUGLfAmW5tsOxp1ShxCovwh/I+7eetzuSeDfIbB+NYpz7
p3xrSBAVwTY=
=zV3P
-END PGP SIGNATURE-


-- 
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL security advisory

[Jean-Marc Desperrier]

OpenSSL wrote:

OpenSSL Ciphersuite Downgrade Attack
=

A flaw has been found in the OpenSSL SSL/TLS server code where an old bug
workaround allows malicous clients to modify the stored session cache
ciphersuite. In some cases the ciphersuite can be downgraded to a weaker one
on subsequent connections.

The OpenSSL security team would like to thank Martin Rex for reporting this
issue.

This vulnerability is tracked as CVE-2010-4180


I understand that RedHat had already identified this issue five years 
ago : https://bugzilla.redhat.com/show_bug.cgi?id=175779


You should have a better channel of communication with RedHat so that 
when they find something like that, they communicate it to you, even 
when it's about something that they see as a minor issue.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL security advisory

[Dr. Stephen Henson]

On Mon, Dec 06, 2010, Jean-Marc Desperrier wrote:

 OpenSSL wrote:
 OpenSSL Ciphersuite Downgrade Attack
 =

 A flaw has been found in the OpenSSL SSL/TLS server code where an old bug
 workaround allows malicous clients to modify the stored session cache
 ciphersuite. In some cases the ciphersuite can be downgraded to a weaker 
 one
 on subsequent connections.

 The OpenSSL security team would like to thank Martin Rex for reporting 
 this
 issue.

 This vulnerability is tracked as CVE-2010-4180

 I understand that RedHat had already identified this issue five years ago : 
 https://bugzilla.redhat.com/show_bug.cgi?id=175779

 You should have a better channel of communication with RedHat so that when 
 they find something like that, they communicate it to you, even when it's 
 about something that they see as a minor issue.


That is actually a different issue AFAICS. In that case a ciphersuite not
supported by the server can be used. That was fixed here:

http://cvs.openssl.org/chngview?cn=17490

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL security advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [2 December 2010]

OpenSSL Ciphersuite Downgrade Attack
=

A flaw has been found in the OpenSSL SSL/TLS server code where an old bug
workaround allows malicous clients to modify the stored session cache
ciphersuite. In some cases the ciphersuite can be downgraded to a weaker one
on subsequent connections.

The OpenSSL security team would like to thank Martin Rex for reporting this
issue.

This vulnerability is tracked as CVE-2010-4180

OpenSSL JPAKE validation error
===

Sebastian Martini found an error in OpenSSL's J-PAKE implementation
which could lead to successful validation by someone with no knowledge
of the shared secret. This error is fixed in 1.0.0c. Details of the
problem can be found here:

http://seb.dbzteam.org/crypto/jpake-session-key-retrieval.pdf

Note that the OpenSSL Team still consider our implementation of J-PAKE
to be experimental and is not compiled by default.

This issue is tracked as CVE-2010-4252 

Who is affected?
=

All versions of OpenSSL contain the ciphersuite downgrade vulnerability.

Any OpenSSL based SSL/TLS server is vulnerable if it uses
OpenSSL's internal caching mechanisms and the
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG flag (many applications enable this
by using the SSL_OP_ALL option).

Users of OpenSSL 0.9.8j or later who do not enable weak ciphersuites are
still vulnerable but the bug has no security implications as the attacker can
only change from one strong ciphersuite to another.

All users of OpenSSL's experimental J-PAKE implementation are vulnerable
to the J-PAKE validation error.

Recommendations for users of OpenSSL
=

Users of all OpenSSL 0.9.8 releases including 0.9.8p should update
to the OpenSSL 0.9.8q release which contains a patch to correct this issue.

Alternatively do not set the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
and/or SSL_OP_ALL flags.

Users of OpenSSL 1.0.0 releases should update to the OpenSSL 1.0.0c release
which contains a patch to correct this issue and also contains a corrected
version of the CVE-2010-3864 vulnerability fix.

If upgrading is not immediately possible, the relevant source code patch
provided in this advisory should be applied.

Any user of OpenSSL's J-PAKE implementaion (which is not compiled in by 
default) should upgrade to OpenSSL 1.0.0c.

Patch
=

Index: ssl/s3_clnt.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_clnt.c,v
retrieving revision 1.129.2.16
diff -u -r1.129.2.16 s3_clnt.c
- --- ssl/s3_clnt.c 10 Oct 2010 12:33:10 -  1.129.2.16
+++ ssl/s3_clnt.c   24 Nov 2010 14:32:37 -
@@ -866,8 +866,11 @@
s-session-cipher_id = s-session-cipher-id;
if (s-hit  (s-session-cipher_id != c-id))
{
+/* Workaround is now obsolete */
+#if 0
if (!(s-options 
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG))
+#endif
{
al=SSL_AD_ILLEGAL_PARAMETER;

SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_OLD_SESSION_CIPHER_NOT_RETURNED);
Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.171.2.22
diff -u -r1.171.2.22 s3_srvr.c
- --- ssl/s3_srvr.c 14 Nov 2010 13:50:29 -  1.171.2.22
+++ ssl/s3_srvr.c   24 Nov 2010 14:34:28 -
@@ -985,6 +985,10 @@
break;
}
}
+/* Disabled because it can be used in a ciphersuite downgrade
+ * attack: CVE-2010-4180.
+ */
+#if 0
if (j == 0  (s-options  
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG)  (sk_SSL_CIPHER_num(ciphers) == 1))
{
/* Special case as client bug workaround: the 
previously used cipher may
@@ -999,6 +1003,7 @@
j = 1;
}
}
+#endif
if (j == 0)
{
/* we need to have the cipher in the cipher



References
===

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20101202.txt

URL for updated CVS-2010-3864 Security Advisory:
http://www.openssl.org/news/secadv_20101116-2.txt


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBTPfvZ6LSm3vylcdZAQI9Lwf+JT3pzOySPkeMKS+OY19d/teHObhwxeI/
z/gS303F+CUmhQhmi0ueYno6gYfmpzYG/xNA+7dLwVinOjKpwTHNqZVHtLhFgwQm
wZS+vqiPBjzakjTGz0YXrA1uPQG/1ASbVV3C0a9s7nKCsDzYiWJkzFrZiVTzkVat
Y39Z5hTBCwUxssCyJU4VSRGNF4kcHzvbuDeNJDnK0shdz+hgNx2mNb8EFgYDRqbx
ahIMGAKEtpVIn3WgeHL0r6VjG2RFaV1QLPyehAPvU/YjBnbph++PyXqnsTmEbtgn
ma3aqbxbSLI0+WobVXabDlB4PD6H57Uwt2R57vZs2yNCSX8sSkMBqg==
=vUwE
-END PGP SIGNATURE

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [16 November 2010]

TLS extension parsing race condition.
=

A flaw has been found in the OpenSSL TLS server extension code parsing which
on affected servers can be exploited in a buffer overrun attack.

The OpenSSL security team would like to thank Rob Hulswit for reporting this
issue.

The fix was developed by Dr Stephen Henson of the OpenSSL core team.

This vulnerability is tracked as CVE-2010-3864

Who is affected?
=

All versions of OpenSSL supporting TLS extensions contain this vulnerability
including OpenSSL 0.9.8f through 0.9.8o, 1.0.0, 1.0.0a releases.

Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses
OpenSSL's internal caching mechanism. Servers that are multi-process and/or
disable internal session caching are NOT affected.

In particular the Apache HTTP server (which never uses OpenSSL internal
caching) and Stunnel (which includes its own workaround) are NOT affected.

Recommendations for users of OpenSSL
=

Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should update
to the OpenSSL 0.9.8p release which contains a patch to correct this issue.

Users of OpenSSL 1.0.0 and 1.0.0a should update to the OpenSSL 1.0.0b release
which contains a patch to correct this issue.

If upgrading is not immediately possible, the relevant source code patch
provided in this advisory should be applied.

Patch for OpenSSL 0.9.8 releases


Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.13.2.27
diff -u -r1.13.2.27 t1_lib.c
- --- ssl/t1_lib.c  12 Jun 2010 13:18:58 -  1.13.2.27
+++ ssl/t1_lib.c15 Nov 2010 15:20:14 -
@@ -432,14 +432,23 @@
switch (servname_type)
{
case TLSEXT_NAMETYPE_host_name:
- - if (s-session-tlsext_hostname == NULL)
+   if (!s-hit)
{
- - if (len  
TLSEXT_MAXLEN_host_name || 
- - 
((s-session-tlsext_hostname = OPENSSL_malloc(len+1)) == NULL))
+   if(s-session-tlsext_hostname)
+   {
+   *al = 
SSL_AD_DECODE_ERROR;
+   return 0;
+   }
+   if (len  
TLSEXT_MAXLEN_host_name)
{
*al = 
TLS1_AD_UNRECOGNIZED_NAME;
return 0;
}
+   if 
((s-session-tlsext_hostname = OPENSSL_malloc(len+1)) == NULL)
+   {
+   *al = 
TLS1_AD_INTERNAL_ERROR;
+   return 0;
+   }

memcpy(s-session-tlsext_hostname, sdata, len);

s-session-tlsext_hostname[len]='\0';
if 
(strlen(s-session-tlsext_hostname) != len) {
@@ -452,7 +461,8 @@
 
}
else 
- - s-servername_done = 
strlen(s-session-tlsext_hostname) == len 
+   s-servername_done = 
s-session-tlsext_hostname
+
strlen(s-session-tlsext_hostname) == len 
 
strncmp(s-session-tlsext_hostname, (char *)sdata, len) == 0;

break;

Patch for OpenSSL 1.0.0 releases


Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.64.2.14
diff -u -r1.64.2.14 t1_lib.c
- --- ssl/t1_lib.c  15 Jun 2010 17:25:15 -  1.64.2.14
+++ ssl/t1_lib.c15 Nov 2010 15:26:19 -
@@ -714,14 +714,23 @@
switch (servname_type)
{
case

Re: OpenSSL Security Advisory: Record of death

[Adam Langley]

On Thu, Mar 25, 2010 at 5:16 PM, Claus Assmann ca+ssl-...@esmtp.org wrote:
 So far I haven't been able to determine which change caused the
 problem, so I'm still looking at various diff's, but I'm not
 familiar with the source code to (easily) spot the problem.

I imagine the reason that the exact breakdown wasn't given was because
it would let attackers know exactly what to do.

From the advisory:

- If 'short' is a 16-bit integer, this issue applies only to OpenSSL 0.9.8m.
- Otherwise, this issue applies to OpenSSL 0.9.8f through 0.9.8m.

Almost certainly short is 16-bits for you, so it only matters if
you're running 0.9.8m. You are very unlikely to have introduced the
problem via a patch.


AGL

-- 
Adam Langley a...@imperialviolet.org http://www.imperialviolet.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Jean-Marc Desperrier]

Bodo Moeller wrote:

it's code elsewhere that no longer tolerates the coarse logic we are
changing in the patch, which has been around forever.


In fact, I already suspected that, thanks for the confirmation.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Jean-Marc Desperrier]

OpenSSL wrote:

Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m


How comes the vulnerability doesn't touch 0.9.8e though the patched file 
wasn't modified between 0.9.8e and 0.9.8f ?


But that code was modified between 0.9.8d and 0.9.8e, see this patch :
http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61

Could it be a reference mistake and that this vulnerability is from 
0.9.8e through 0.9.8m ?

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Bodo Moeller]

On Mar 25, 2010, at 6:33 PM, Jean-Marc Desperrier wrote:


OpenSSL wrote:

Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m


How comes the vulnerability doesn't touch 0.9.8e though the patched  
file wasn't modified between 0.9.8e and 0.9.8f ?


But that code was modified between 0.9.8d and 0.9.8e, see this patch :
http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61

Could it be a reference mistake and that this vulnerability is from  
0.9.8e through 0.9.8m ?


No, it's not a mistake -- it's code elsewhere that no longer tolerates  
the coarse logic we are changing in the patch, which has been around  
forever.


Bodo

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: OpenSSL Security Advisory

[Paul Suhler]

Am I reading the changes file correctly:  if you don't use Kerberos,
then this vulnerability doesn't apply?

Thanks,

Paul
___
Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
949.856.7748 | paul.suh...@quantum.com 
___
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individuals or organizations, without restriction.

-Original Message-
From: owner-openssl-...@openssl.org
[mailto:owner-openssl-...@openssl.org] On Behalf Of Bodo Moeller
Sent: Thursday, March 25, 2010 11:40 AM
To: openssl-dev@openssl.org
Subject: Re: OpenSSL Security Advisory

On Mar 25, 2010, at 6:33 PM, Jean-Marc Desperrier wrote:

 OpenSSL wrote:
 Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m

 How comes the vulnerability doesn't touch 0.9.8e though the patched 
 file wasn't modified between 0.9.8e and 0.9.8f ?

 But that code was modified between 0.9.8d and 0.9.8e, see this patch :
 http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61

 Could it be a reference mistake and that this vulnerability is from 
 0.9.8e through 0.9.8m ?

No, it's not a mistake -- it's code elsewhere that no longer tolerates
the coarse logic we are changing in the patch, which has been around
forever.

Bodo

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory: Record of death

[Claus Assmann]

On Thu, Mar 25, 2010, Bodo Moeller wrote:

 Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m

 No, it's not a mistake -- it's code elsewhere that no longer
 tolerates the coarse logic we are changing in the patch, which has
 been around forever.

Could you please elaborate?

I'm asking this because:
- we ship OpenSSL 0.9.8k + some security patches, e.g., turn off
  renegotiation.
- I need to find out whether our version is affected (if it is,
  we need to update our products to include this patch)
So far I haven't been able to determine which change caused the
problem, so I'm still looking at various diff's, but I'm not
familiar with the source code to (easily) spot the problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Dr. Stephen Henson]

On Thu, Mar 25, 2010, Paul Suhler wrote:

 Am I reading the changes file correctly:  if you don't use Kerberos,
 then this vulnerability doesn't apply?
 

There are two separate issues.

CVE-2010-0740 applies to 0.9.8m SSL/TLS and has nothing to do with Kerberos.
That is why we made the special release.

CVE-2010-0433 applies only if OpenSSL is compiled with kerberos support (it
isn't by default). This was fixed before and since it only affected kerberos
builds it was felt it didn't warrant a release.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #1899] [patch] something that didn't make it into HEAD, related to OpenSSL Security Advisory [07-Jan-2009] CVE2008-5077

[Ger Hobbelt via RT]

Error result code check in ./crypto/x509/x509_vfy.c: error return
value can be negative.

(My personal lesson from this: don't wait to see if one of the Top
Dogs bother asking 'hm, shouldn't this change as well?' - I waited for
the O.G., then forgot. And now I'm still not 110% sure if I saw
something the rest didn't or the statistical more probable(?) version
where I am completely and utterly /wrong/. Though when we factor in my
a.r. regarding error checking... Well, enough banter, spin the wheel,
darling...)


Note: I did *not* check if this was done in any stable at the time.
(I've been riding the bleeding edge wave for years now, with no
glaring ill effects.) This is the result of my own code review
following that CVE. X509_verify_cert() is one of the functions which'
return code should be checked for both zero AND negative values; this
was done in one spot, but not in another. This patch is the other.

I now searched back for that CVE as my comment in my own tree only
mentioned the date, and here's the log for the CVS entry at the time
(posted around 11:48 2009/01/07):

-
Log:
Properly check EVP_VerifyFinal() and similar return values
(CVE-2008-5077).
Submitted by: Ben Laurie, Bodo Moeller, Google Security Team
--




In case there's a 'HUH?' or 'WTF?' popping up in any brain anywhere:

X509_verify_cert()
is one of the functions which is included in the CVE (and the patch
for it posted from official CVS at 7/jan/2009 with above Log quote).
It can not only return the usual zero(0) value in case of an error /
invalid report, but given its nature, negative return values in case
of errors / invalid reports are possible as well.
This was previously not checked for, leading to the CVE.

The original CVS patch @ 7/1/2009 patches the OpenSSL source tree for
this in one location for X509_verify_cert(), just not in a second
place where X509_verify_cert() was invoked as well.

That is what this single line of change patch today is about: fixing
the checking of the return value at that second spot in case
X509_verify_cert() produces a NEGATIVE return value. Just like the
original CVE fix did at the other spot.



Ergo: this patch should maybe be applied to the other branches as well.
ducks for cover ;-) 


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--

--- /home/ger/prj/1original/openssl/openssl/./crypto/x509/x509_vfy.c	2008-10-08 00:55:27.0 +0200
+++ ./crypto/x509/x509_vfy.c	2009-04-07 11:07:52.0 +0200
@@ -1124,7 +1124,7 @@
 	/* Verify CRL issuer */
 	ret = X509_verify_cert(crl_ctx);
 
-	if (!ret)
+	if (ret = 0) /* OpenSSL Security Advisory [07-Jan-2009] */
 		goto err;
 
 	/* Check chain is acceptable */

Re: OpenSSL Security Advisory

[Remo Inverardi]

One way to exploit this flaw would be for a remote attacker who is in
control of a malicious server or who can use a 'man in the middle'
attack to present a malformed SSL/TLS signature from a certificate chain
to a vulnerable client, bypassing validation.


In my opinion, this statement is not very clear. After reading the 
advisory, I was under the impression that the validation of the 
DSA/ECDSA signature of the SSL/TLS server certificate could be bypassed.


After looking into the code more closely, I am pretty confident that 
this is not possible. However, I do realize that the validation of the 
signatures in the SSL/TLS protocol messages can be bypassed, possibly 
allowing an attacker to take part in the key exchange process.


Are these assumptions correct?

Thanks.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Ger Hobbelt]

On Wed, Jan 7, 2009 at 1:10 PM, Dr. Stephen Henson st...@openssl.org wrote:
[...]
 diff -ur openssl-0.9.8i-ORIG/apps/speed.c openssl-0.9.8i/apps/speed.c
[...]
 diff -ur openssl-0.9.8i-ORIG/ssl/ssltest.c openssl-0.9.8i/ssl/ssltest.c

0.9.9 CVS head (and probably 0.9.8 as well): for completeness sake
there's one more spot not listed in the published patch, where another
call to X509_verify_cert() was done.
(based on full source code scan; not a run-time test)

Correct me if I'm wrong or code-pedantic.


Addendum to patch supplied here:

-
--- \\Debbie\ger\prj\1original\openssl\openssl\crypto\x509\x509_vfy.c   
2008-10-07
23:55:27.0 +-0100
+++ \\Debbie\ger\prj\3actual\openssl\crypto\x509\x509_vfy.c 2009-01-07
18:04:33.0 +-0100
@@ -1121,15 +1120,15 @@
crl_ctx.parent = ctx;
crl_ctx.verify_cb = ctx-verify_cb;

/* Verify CRL issuer */
ret = X509_verify_cert(crl_ctx);

-   if (!ret)
+   if (ret = 0) /* OpenSSL Security Advisory [07-Jan-2009] */
goto err;

/* Check chain is acceptable */

ret = check_crl_chain(ctx, ctx-chain, crl_ctx.chain);
err:
X509_STORE_CTX_cleanup(crl_ctx);
return ret;
-





-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Harakiri]

--- On Wed, 1/7/09, Dr. Stephen Henson st...@openssl.org wrote:

 Incorrect checks for malformed signatures
 - ---


It is not perfectly clear to me if regular certificate validiations and smime 
signature validiation is also affected by this. Could you please elaborate if 
this vul could be used while verifying certificate (chains) and/or smime 
signatures?

Thanks


  
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory

[Dr. Stephen Henson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [07-Jan-2009]

Incorrect checks for malformed signatures
- ---

Several functions inside OpenSSL incorrectly checked the result after
calling the EVP_VerifyFinal function, allowing a malformed signature
to be treated as a good signature rather than as an error.  This issue
affected the signature checks on DSA and ECDSA keys used with
SSL/TLS.

One way to exploit this flaw would be for a remote attacker who is in
control of a malicious server or who can use a 'man in the middle'
attack to present a malformed SSL/TLS signature from a certificate chain
to a vulnerable client, bypassing validation.

This vulnerability is tracked as CVE-2008-5077.

The OpenSSL security team would like to thank the Google Security Team
for reporting this issue.

Who is affected?
- -

Everyone using OpenSSL releases prior to 0.9.8j as an SSL/TLS client
when connecting to a server whose certificate contains a DSA or ECDSA key.

Use of OpenSSL as an SSL/TLS client when connecting to a server whose
certificate uses an RSA key is NOT affected.

Verification of client certificates by OpenSSL servers for any key type
is NOT affected.

Recommendations for users of OpenSSL
- 

Users of OpenSSL 0.9.8 should update to the OpenSSL 0.9.8j release
which contains a patch to correct this issue.

The patch used is also appended to this advisory for users or
distributions who wish to backport this patch to versions they build
from source.

Recommendations for projects using OpenSSL
- --

Projects and products using OpenSSL should audit any use of the
routine EVP_VerifyFinal() to ensure that the return code is being
correctly handled.  As documented, this function returns 1 for a
successful verification, 0 for failure, and -1 for an error.

General recommendations
- ---

Any server that has clients using OpenSSL verifying DSA or ECDSA
certificates, regardless of the software used by the server, should
either ensure that all clients are upgraded or stop using DSA/ECDSA
certificates. Note that unless certificates are revoked (and clients
check for revocation) impersonation will still be possible until the
certificate expires.




diff -ur openssl-0.9.8i-ORIG/apps/speed.c openssl-0.9.8i/apps/speed.c
- --- openssl-0.9.8i/apps/speed.c   2007-11-15 13:33:47.0 +
+++ openssl-0.9.8i/apps/speed-new.c 2008-12-04 00:00:00.0 +
@@ -2132,7 +2132,7 @@
{
ret=RSA_verify(NID_md5_sha1, buf,36, buf2,
rsa_num, rsa_key[j]);
- - if (ret == 0)
+   if (ret = 0)
{
BIO_printf(bio_err,
RSA verify failure\n);
diff -ur openssl-0.9.8i-ORIG/apps/spkac.c openssl-0.9.8i/apps/spkac.c
- --- openssl-0.9.8i-ORIG/apps/spkac.c  2005-04-05 19:11:18.0 +
+++ openssl-0.9.8i/apps/spkac.c 2008-12-04 00:00:00.0 +
@@ -285,7 +285,7 @@
pkey = NETSCAPE_SPKI_get_pubkey(spki);
if(verify) {
i = NETSCAPE_SPKI_verify(spki, pkey);
- - if(i) BIO_printf(bio_err, Signature OK\n);
+   if (i  0) BIO_printf(bio_err, Signature OK\n);
else {
BIO_printf(bio_err, Signature Failure\n);
ERR_print_errors(bio_err);
diff -ur openssl-0.9.8i-ORIG/apps/verify.c openssl-0.9.8i/apps/verify.c
- --- openssl-0.9.8i-ORIG/apps/verify.c 2004-11-29 11:28:07.0 +
+++ openssl-0.9.8i/apps/verify.c2008-12-04 00:00:00.6 +
@@ -266,7 +266,7 @@
 
ret=0;
 end:
- - if (i)
+   if (i  0)
{
fprintf(stdout,OK\n);
ret=1;
@@ -367,4 +367,3 @@
ERR_clear_error();
return(ok);
}
- -
diff -ur openssl-0.9.8i-ORIG/apps/x509.c openssl-0.9.8i/apps/x509.c
- --- openssl-0.9.8i-ORIG/apps/x509.c   2007-10-12 00:00:10.0 +
+++ openssl-0.9.8i/apps/x509.c  2008-12-04 00:00:00.4 +
@@ -1151,7 +1151,7 @@
/* NOTE: this certificate can/should be self signed, unless it was
 * a certificate request in which case it is not. */
X509_STORE_CTX_set_cert(xsc,x);
- - if (!reqfile  !X509_verify_cert(xsc))
+   if (!reqfile  X509_verify_cert(xsc) = 0)
goto end;
 
if (!X509_check_private_key(xca,pkey))
diff -ur openssl-0.9.8i-ORIG/crypto/cms/cms_sd.c 
openssl-0.9.8i/crypto/cms/cms_sd.c
- --- openssl-0.9.8i-ORIG/crypto/cms/cms_sd.c   2008-04-06 16:30:38.0 
+
+++ openssl-0.9.8i/crypto/cms/cms_sd.c  2008-12-04 00:00:00.4 +
@@ -830,7 +830,7 @@
cms_fixup_mctx(mctx, si-pkey

Re: OpenSSL Security Advisory

[Kyle Hamilton]

Does the release of 0.9.8j also include the FIPS module support?
(i.e., is this a bug-fix only release, or does this include what you
have been working on for the past few months as well?)

-Kyle H

On Wed, Jan 7, 2009 at 4:10 AM, Dr. Stephen Henson st...@openssl.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 OpenSSL Security Advisory [07-Jan-2009]

 Incorrect checks for malformed signatures
 - ---
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL Security Advisory

[Brad House]

 Does the release of 0.9.8j also include the FIPS module support?
 (i.e., is this a bug-fix only release, or does this include what you
 have been working on for the past few months as well?)

The actual 0.9.8j release announcement stated:

This is the first full release of OpenSSL that can link against the
validated FIPS module version 1.2

-Brad
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #225] OpenSSL Security Advisory (30 July 2002), recompiling application s using OpenSSL, enhancement request

[via RT]

Dear Sirs,

I have read your OpenSSL Security Advisory (30 July 2002), where there is
the recommendation to upgrade to OpenSSL 0.9.6e for those using 0.9.6d and
earlier.

We are using OpenSSL version 0.9.6a-9 and OpenSSH version 2.9p1-7. The OS is
SuSE - Linux 7.2 (i386)

You recommend also recompiling all applications using OpenSSL to provide SSL
or TLS. 

I would like you to tell me what exactly is meant by recompilation. Do I
have to download the source code for OpenSSH (since I had already OpenSSH
installed on the system as binary package) and compile again to take SSL or
whatever changes in effect?


Any help would be greatly appreciated.

Thanks in Advance for your kind support


Best Regards,

Bengi Ako

__

Unix System Administrator

Bundesdruckerei GmbH
Kommandantenstr. 15
10958 Berlin - Germany

Tel.: +49 - 30 - 25 98 13 89


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]