[openssl-users] OpenSSL Security Advisory

[Matt Caswell]

OpenSSL Security Advisory [12 November 2018]


Microarchitecture timing vulnerability in ECC scalar multiplication 
(CVE-2018-5407)
===

Severity: Low

OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been shown
to be vulnerable to a microarchitecture timing side channel attack. An attacker
with sufficient access to mount local timing attacks during ECDSA signature
generation could recover the private key.

This issue does not impact OpenSSL 1.1.1 and is already fixed in the latest
version of OpenSSL 1.1.0 (1.1.0i). OpenSSL 1.0.2 is affected but due to the low
severity of this issue we are not creating a new release at this time. The 1.0.2
mitigation for this issue can be found in commit b18162a7c.

OpenSSL 1.1.0 users should upgrade to 1.1.0i.

This issue was reported to OpenSSL on 26th October 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and Nicola Tuveri.

Note


OpenSSL 1.1.0 is currently only receiving security updates. Support for this
version will end on 11th September 2019. Users of this version should upgrade to
OpenSSL 1.1.1.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20181112.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



signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


OpenSSL Security Advisory [12 June 2018]


Client DoS due to large DH parameter (CVE-2018-0732)


Severity: Low

During key agreement in a TLS handshake using a DH(E) based ciphersuite a
malicious server can send a very large prime value to the client. This will
cause the client to spend an unreasonably long period of time generating a key
for this prime resulting in a hang until the client has finished. This could be
exploited in a Denial Of Service attack.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i
and OpenSSL 1.0.2p when they become available. The fix is also available in
commit ea7abeeab (for 1.1.0) and commit 3984ef0b7 (for 1.0.2) in the OpenSSL git
repository.

This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken who also
developed the fix.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20180612.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-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsfnTgACgkQ2cTSbQ5g
RJE9Twf/VSgXaFPlW+JyA2BAiwGREMr/oMQe8mhmka3WQgNb7oMQRxk4ZqwRvLi2
ggPVOQilJ+tkXgeifEQ3SDRxDnnmcUvxbWB8Lt+7tjhM6O+GYGbGbzupnkBs2IIY
72vll4l7ySMQ8/fcdU/uuNyObfigLC9XndH3tEewxffs6uvDxMyGhZmNQpq1aZNj
rGj3dETUuO/Ln8siAD7nkv9xodRINViMP76fSKAtdaikvZa3uhLBMhX5tOzpR/ta
tc2+6uthdU9JjSRZZpfDlzzhsOFqMrLfOLrJQIIXshxUNeOZyJCkmT9ED8XZRDMB
twb1kOxCKz8Ky+Xm/Rki9uRVoZFjBg==
=kKic
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [16 Apr 2018]


Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)


Severity: Low

The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a
cache timing side channel attack. An attacker with sufficient access to mount
cache timing attacks during the RSA key generation process could recover the
private key.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i
and OpenSSL 1.0.2p when they become available. The fix is also available in
commit 6939eab03 (for 1.1.0) and commit 349a41da1 (for 1.0.2) in the OpenSSL git
repository.

This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
The fix was developed by Billy Brumley.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20180416.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-

iQEcBAEBCAAGBQJa1MKgAAoJENnE0m0OYESRKOoIAKmRnj0YtE1y89WnRiCjMk8l
Z7XAsPk6nkEa8dlrEvEsUhS90CFSf9OcYliAlfjD/+RVZXXeK4AHn8/g7HxAdDcK
62biQiHbxICBqnrE6DCe6GrMXEy3MWuefSWnoTyd/x8W1grjdhkrlmIqe68DP0iv
WItmStRVOpx4mQDcrYqw6ZKhhu1Lv007khyAornJP+S6NSlK6brdNQyRNmp3+HO4
irqPi6xQWGcaAtrdpWi8mDnomld75j5m+G98N/gCqaCAIn7Zau+kAAW1+1dO5S4L
tsQ0CifVnRfUTz0cCL51L8G3a3RWYs34AXRZvSRi3q88AiZ1L6FCF2cHZJu1KuE=
=+TYO
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


OpenSSL Security Advisory [27 Mar 2018]


Constructed ASN.1 types with a recursive definition could exceed the stack 
(CVE-2018-0739)
==

Severity: Moderate

Constructed ASN.1 types with a recursive definition (such as can be found in
PKCS7) could eventually exceed the stack given malicious input with
excessive recursion. This could result in a Denial Of Service attack. There are
no such structures used within SSL/TLS that come from untrusted sources so this
is considered safe.

OpenSSL 1.1.0 users should upgrade to 1.1.0h
OpenSSL 1.0.2 users should upgrade to 1.0.2o

This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz project.
The fix was developed by Matt Caswell of the OpenSSL development team.

Incorrect CRYPTO_memcmp on HP-UX PA-RISC (CVE-2018-0733)


Severity: Moderate

Because of an implementation bug the PA-RISC CRYPTO_memcmp function is
effectively reduced to only comparing the least significant bit of each byte.
This allows an attacker to forge messages that would be considered as
authenticated in an amount of tries lower than that guaranteed by the security
claims of the scheme. The module can only be compiled by the HP-UX assembler, so
that only HP-UX PA-RISC targets are affected.

OpenSSL 1.1.0 users should upgrade to 1.1.0h

This issue was reported to OpenSSL on 2nd March 2018 by Peter Waltenberg (IBM).
The fix was developed by Andy Polyakov of the OpenSSL development team.

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

Severity: Low

This issue has been reported in a previous OpenSSL security advisory and a fix
was provided for OpenSSL 1.0.2. Due to the low severity no fix was released at
that time for OpenSSL 1.1.0. The fix is now available in OpenSSL 1.1.0h.

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.

OpenSSL 1.1.0 users should upgrade to 1.1.0h
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.

References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20180327.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-

iQEcBAEBCAAGBQJaulEjAAoJENnE0m0OYESRc2oH/2E5ya4GF745SK7VB7ZjCWu6
tN5q3CNr1gUiZKcsvK4nl/OdP5h+KToHYQR1RBy0tusk1cFHYRuztsZhtb/mm0DD
Z3adXvnz8VFeCyNC/aptwOO0OoPbUHgqhf1L5deNaXMZJDqEjz/6WlVfFQezSeVf
h0Sy72SmX2h+Jt1Zh+VYjfX/xMTnX6CWrbyC78KKZ88s4dSYbMsYdJuJSqpar/C1
zQpgCD6Stk0L9J4DB4DYr3MAInMJXRIMyFOZlrOm4oTbZqSdcFxIglCMVPlXpES2
Ke1Gse5bab+O0sr+Ue4Vk0zsi3wv7zaUk8d7YchMpUlqJWKeY3N3i40jnacx1fU=
=ATWc
-END PGP SIGNATURE-
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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 users should upgrade

[openssl-users] 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_EncryptUpdate overflow 

[openssl-users] 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 carried out in
constant time.

This issue affects Open

[openssl-users] 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 with DH parameters shorter than 768 bits in
releases 1.0.2b and 1.0.1n

[openssl-users] OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [3 Dec 2015]
===

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.

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
versions will be provided after that date. In the absence of significant
security issues being identified prior to that date, the 1.0.0t and 0.9.8zh
releases will be the last for those versions. Users of these versions are
advised to upgrade.


References
==

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

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

For 

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[Matt Caswell]

On 10/07/15 19:34, R C Delgado wrote:
> Hello,
> 
> One further question. Can you please confirm that the alternative
> certificate chain feature is enabled by default? It seems to be implied
> in all emails regarding this matter, and I'm assuming the Advisory email
> would have mentioned it otherwise.

Yes, it is enabled by default.

Matt

> 
> I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS
> exists but is not set in the "flags" member by default when a new X509
> context is initialised. And my code does not modify the context to
> include this flag. 
> 
> Please let me know if I'm missing something.
> 
> (I'm using OpenSSL 1.0.1o)
> 
> Many thanks,
> RCD
> 
> 
> 
> 
> 
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[R C Delgado]

Hello,

One further question. Can you please confirm that the alternative
certificate chain feature is enabled by default? It seems to be implied in
all emails regarding this matter, and I'm assuming the Advisory email would
have mentioned it otherwise.

I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS
exists but is not set in the "flags" member by default when a new X509
context is initialised. And my code does not modify the context to include
this flag.

Please let me know if I'm missing something.

(I'm using OpenSSL 1.0.1o)

Many thanks,
RCD


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

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[R C Delgado]

Thank you very much. It really helps.

On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell  wrote:

>
>
> On 10/07/15 13:09, R C Delgado wrote:
> > Hello,
> >
> > With regards to CVE-2015-1793, I've seen the example in
> verify_extra_test.c.
> > How deep does the certificate chain have to be?
> > If I have 2 self-signed CA certificates, and a non-CA certificate is
> > received for verification, will this hit the problem?
> >
> > Also, is it a condition of the bug that both CA certificates have to
> > have the same subject names and keys, as suggested in the file?
>
>
> The conditions for triggering the bug are a little complicated, but I'll
> do my best to explain it.
>
> Under normal circumstances things work as follows:
>
> We are provided with a certificate to verify from a remote peer. Lets
> call the certificate we are trying to verify Leaf.
> As well as Leaf that has been provided from the remote peer, they also
> supply us with a set of untrusted certs.
> Finally we also have a store of trusted certs.
>
> OpenSSL will first attempt to build a certificate chain. The chain
> building works as follows (much simplified):
>
> 1. Set Leaf as the top of the chain
> 2. Look for the issuer of the cert at the top of the chain from within
> the untrusted set. If we find it add it to the top of the chain
> 3. Repeat (2) until we can't find any more certs from the untrusted set
> 4. Look for the issuer of the top of the chain from the set of trusted
> certs
> 5. Repeat (4) until we can't find any more certs from the trusted set
>
> If we've found a valid chain with a trusted self signed cert at the top,
> then we stop there. If not, then we continue to look to see if there is
> an alternative chain that can be built. This works as follows:
>
> Pop all the trusted certs off the top of the chain, then start popping
> the untrusted certs off. Each time we pop an untrusted cert off start
> the chain building again from step 4.
>
> The bug occurs when during the initial chain building:
> 1) We have added at least one cert from the untrusted set
> 2) We have added at least one cert from the trusted store
>
> For 1.0.2 there is the additional condition:
> 3) After doing (1) and (2) above we do not have a valid chain
>
> Finally (for both 1.0.1 and 1.0.2)
> 4) After popping off at least one untrusted cert from the chain we can
> build an alternative valid chain
>
> Under the above conditions the end entity cert Leaf could "issue" a new
> certificate even though it is not supposed to (I'll call that invalid
> certificate "Bad").
>
> So these certs would need to be present (at a minimum):
>
> Chain 1:
>
> Trusted Cert 1
> |
> Untrusted Cert 1
> |
> Leaf
> |
> Bad
>
> Chain 2:
>
> Trusted Cert 2
> |
> Leaf
> |
> Bad
>
> There are other possible longer chains, but this is the minimum set. For
> 1.0.2, Chain 1 would have to be non-trusted, even though we have added a
> trusted cert. This can occur if Trusted Cert 1 is not self signed and
> its issuer is not in the trusted store. For 1.0.1 any chain will do.
> Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers
> of Leaf (i.e. they have the same subject names and public keys). Chain 2
> must be trusted (so Trusted Cert 2 has to be a self-signed root).
>
> Matt
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[Lewis Rosenthal]

On 07/10/2015 09:32 AM, Matt Caswell wrote:


On 10/07/15 13:09, R C Delgado wrote:

Hello,

With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c.
How deep does the certificate chain have to be?
If I have 2 self-signed CA certificates, and a non-CA certificate is
received for verification, will this hit the problem?

Also, is it a condition of the bug that both CA certificates have to
have the same subject names and keys, as suggested in the file?


The conditions for triggering the bug are a little complicated, but I'll
do my best to explain it.




So these certs would need to be present (at a minimum):

Chain 1:

Trusted Cert 1
|
Untrusted Cert 1
|
Leaf
|
Bad

Chain 2:

Trusted Cert 2
|
Leaf
|
Bad

There are other possible longer chains, but this is the minimum set. For
1.0.2, Chain 1 would have to be non-trusted, even though we have added a
trusted cert. This can occur if Trusted Cert 1 is not self signed and
its issuer is not in the trusted store. For 1.0.1 any chain will do.
Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers
of Leaf (i.e. they have the same subject names and public keys). Chain 2
must be trusted (so Trusted Cert 2 has to be a self-signed root).


Thanks, Matt. This is the most cogent explanation I've seen to date.

Cheers

--
Lewis
-
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLCwww.2rosenthals.com
visit my IT blogwww.2rosenthals.net/wordpress
IRS Circular 230 Disclosure applies   see www.2rosenthals.com
-

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

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[Matt Caswell]

On 10/07/15 13:09, R C Delgado wrote:
> Hello,
> 
> With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c.
> How deep does the certificate chain have to be?
> If I have 2 self-signed CA certificates, and a non-CA certificate is
> received for verification, will this hit the problem?
> 
> Also, is it a condition of the bug that both CA certificates have to
> have the same subject names and keys, as suggested in the file?


The conditions for triggering the bug are a little complicated, but I'll
do my best to explain it.

Under normal circumstances things work as follows:

We are provided with a certificate to verify from a remote peer. Lets
call the certificate we are trying to verify Leaf.
As well as Leaf that has been provided from the remote peer, they also
supply us with a set of untrusted certs.
Finally we also have a store of trusted certs.

OpenSSL will first attempt to build a certificate chain. The chain
building works as follows (much simplified):

1. Set Leaf as the top of the chain
2. Look for the issuer of the cert at the top of the chain from within
the untrusted set. If we find it add it to the top of the chain
3. Repeat (2) until we can't find any more certs from the untrusted set
4. Look for the issuer of the top of the chain from the set of trusted certs
5. Repeat (4) until we can't find any more certs from the trusted set

If we've found a valid chain with a trusted self signed cert at the top,
then we stop there. If not, then we continue to look to see if there is
an alternative chain that can be built. This works as follows:

Pop all the trusted certs off the top of the chain, then start popping
the untrusted certs off. Each time we pop an untrusted cert off start
the chain building again from step 4.

The bug occurs when during the initial chain building:
1) We have added at least one cert from the untrusted set
2) We have added at least one cert from the trusted store

For 1.0.2 there is the additional condition:
3) After doing (1) and (2) above we do not have a valid chain

Finally (for both 1.0.1 and 1.0.2)
4) After popping off at least one untrusted cert from the chain we can
build an alternative valid chain

Under the above conditions the end entity cert Leaf could "issue" a new
certificate even though it is not supposed to (I'll call that invalid
certificate "Bad").

So these certs would need to be present (at a minimum):

Chain 1:

Trusted Cert 1
|
Untrusted Cert 1
|
Leaf
|
Bad

Chain 2:

Trusted Cert 2
|
Leaf
|
Bad

There are other possible longer chains, but this is the minimum set. For
1.0.2, Chain 1 would have to be non-trusted, even though we have added a
trusted cert. This can occur if Trusted Cert 1 is not self signed and
its issuer is not in the trusted store. For 1.0.1 any chain will do.
Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers
of Leaf (i.e. they have the same subject names and public keys). Chain 2
must be trusted (so Trusted Cert 2 has to be a self-signed root).

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

Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[Salz, Rich]

>How deep does the certificate chain have to be?

It does not matter.

>If I have 2 self-signed CA certificates, and a non-CA certificate is received 
>for verification, will this hit the problem?
>Also, is it a condition of the bug that both CA certificates have to have the 
>same subject names and keys, as suggested in the file?

I think you are confused.  The bug is not about CA's.  It's about a non-CA 
fooling the runtime into treating it as if it were a CA and being able to issue 
a certificate.

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

[openssl-users] OpenSSL Security Advisory - CVE-2015-1793

[R C Delgado]

Hello,

With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c.
How deep does the certificate chain have to be?
If I have 2 self-signed CA certificates, and a non-CA certificate is
received for verification, will this hit the problem?

Also, is it a condition of the bug that both CA certificates have to have
the same subject names and keys, as suggested in the file?

Many thanks for your help.
RCD
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] 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 w

[openssl-users] 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
cer

[openssl-users] 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 of the certificat