OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL Security Advisory [16th May 2024]
=
Excessive time spent checking DSA keys and parameters (CVE-2024-4603)
=
Severity: Low
Issue summary: Checking excessively long DSA keys or parameters may be very
slow.
Impact summary: Applications that use the functions EVP_PKEY_param_check()
or EVP_PKEY_public_check() to check a DSA public key or DSA parameters may
experience long delays. Where the key or parameters that are being checked
have been obtained from an untrusted source this may lead to a Denial of
Service.
The functions EVP_PKEY_param_check() or EVP_PKEY_public_check() perform
various checks on DSA parameters. Some of those computations take a long time
if the modulus ("p" parameter) is too large.
Trying to use a very large modulus is slow and OpenSSL will not allow using
public keys with a modulus which is over 10,000 bits in length for signature
verification. However the key and parameter check functions do not limit
the modulus size when performing the checks.
An application that calls EVP_PKEY_param_check() or EVP_PKEY_public_check()
and supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
These functions are not called by OpenSSL itself on untrusted DSA keys so
only applications that directly call these functions may be vulnerable.
Also vulnerable are the OpenSSL pkey and pkeyparam command line applications
when using the "-check" option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue.
OpenSSL 3.3, 3.2, 3.1 and 3.0 are vulnerable to this issue.
OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.
Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit 53ea0648 (for 3.3),
commit da343d06 (for 3.2), commit 9c39b385 (for 3.1) and commit 3559e868
(for 3.0) in the OpenSSL git repository.
OSSfuzz first detected and automatically reported this issue on 13th February
2024 using a fuzzer recently added to OpenSSL written by Kurt Roeckx. The fix
was developed by Tomas Mraz.
General Advisory Notes
==
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20240516.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-
iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmZGLbUACgkQUnRmohyn
nm27iRAAkvc/HNdfAY3l6kBJ2GVUbvPLODxFhzpei5DW1JxUojQwPXe3cXZlBs9D
PDtw85WX4IPULvcrq7BeGxOs4hDR1xkUfzr/5b0t7a9olFy1oYE/and0qpQx3AzP
eS7O9b001ssXtAs43aO6S4H0L5+3lRXPnLhyDfeh4odty4fbSIP8apLXtmaTKt6P
hdm+JLJdrx92aKjraKBcc1YKl2HgCBNRsxBnimKJzZGZVokUZsF0mIZ/G1SZVs0J
W4usEF1JuRD2vAUWcSDU92tZd0Bkz55SjVC7NVPqvqSUAo04f3LhZj1c7rMjSD5p
zjbG6c4PiCC08LRCHRtZUu56Kp1tBYy+X7zZrzDiPF1R/TY9pYYA1JKS6EvbBb/d
8IB3cxeeTzW0StnuxKmOchrMsGJtizh9hGIhy7yzjbQ8oMkhcRsUlbZDQwiHvCUk
qgXP2v0pnqBmVEBfqCBvUOKAy19XMVOUH69JBsuMEPIKzx2k7Y5QvVKZNq3DtboA
lOc0zkfLbtXrNZFDUDqpq2megmVbVlTw619NQE51jN/LPzo7b+fdw1cHTTnQE2Gt
rSQYZnklb0fmfQQJOl4HpCK16SfVebPYU4hRDJ1Yqk6jcClFbit1F7Fz6Ypjv4nM
iTOJAAoat2jQhmqg2VTpuUQGjRMAADvKlpABL4dTYCvJv6RMXTk=
=Efz1
-END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [8th April 2024] == Unbounded memory growth with session handling in TLSv1.3 (CVE-2024-2511) Severity: Low Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions Impact summary: An attacker may exploit certain server configurations to trigger unbounded memory growth that would lead to a Denial of Service This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is being used (but not if early_data support is also configured and the default anti-replay protection is in use). In this case, under certain conditions, the session cache can get into an incorrect state and it will fail to flush properly as it fills. The session cache will continue to grow in an unbounded manner. A malicious client could deliberately create the scenario for this failure to force a Denial of Service. It may also happen by accident in normal operation. This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS clients. The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.0.2 is also not affected by this issue. OpenSSL 3.2, 3.1, 3.0, 1.1.1 are vulnerable to this issue. OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released. OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released (premium support customers only). Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit e9d7083e (for 3.2), commit 7e4d731b (for 3.1) and commit b52867a9 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit 5f8d2577 (for 1.1.1). This issue was reported on 27th February 2024 by Manish Patidar (Hewlett Packard Enterprise). The fix was developed by Matt Caswell. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20240408.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- iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmYT9+oACgkQUnRmohyn nm1jPRAAlvRaeTjSlW7PULpYxAfCrCfLlMzdC15ybP1mO12ixsbdBN4qRxcXWGFP TMqseW1pTCvcfQzEjSzswkio6kjBCh8iN3jSEPCJSIW7FWsZBpIZLwdqytp1pMaL D8Pe1B542dztrCQy+1pobHpxH8EbFVLX8X9VR0nbH2xx6a3cspGc+JwS7RRQzvK3 a27fW+KM/dyjRE8SGbFzxcgparZTcKDhB2WsjW4Hm0Z62J4v/mkxeC30SOrgH4j2 PBsjJW0XqxOdwM40aKqRPXfjnFwDWOaXVZDjARzT9+olnt01WJiXTpnuKKYQ9y1C 4rmUJo+qbxDnsTg+cjBiZGgsEGqH6Fu/VCw6cJF4Wj0+dZDpvludwTtLh4IRaeCp FqO6HWkdPg+qe9yKBvvqvf84i2kOvmSu4bVrJ5Zh524G3tYj43Uq76IiTSoLxM61 xmSVG3n0ri8H7aiavIjuq8U75uPhqmylwAIbL5wjEuIJayuprCINyBLAcV5VAprs avXD6D2XBXLFFDLZ4GEDuNIOWVxO3mGGxZ0kulpGWhESIGJaZk7Rvd+xr3jLtxwT dWdakCmOFtFIAcAdyYow4D5vCJr1p4iaLD3RCvle5bu3KIcThzWHo0ZnTygjyWt6 EgE0LExGT/1RTdtsXQaFQxzKd+gy4gdGfgl0u8ycYbMENKJ/tpE= =rMVW -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [25th January 2024] = PKCS12 Decoding crashes (CVE-2024-0727) === Severity: Low Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL to crash leading to a potential Denial of Service attack Impact summary: Applications loading files in the PKCS12 format from untrusted sources might terminate abruptly. A file in PKCS12 format can contain certificates and keys and may come from an untrusted source. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly check for this case. This can lead to a NULL pointer dereference that results in OpenSSL crashing. If an application processes PKCS12 files from an untrusted source using the OpenSSL APIs then that application will be vulnerable to this issue. OpenSSL APIs that are vulnerable to this are: PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes() and PKCS12_newpass(). We have also fixed a similar issue in SMIME_write_PKCS7(). However since this function is related to writing data we do not consider it security significant. The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 3.2, 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.2 users should upgrade to OpenSSL 3.2.1 once it is released. OpenSSL 3.1 users should upgrade to OpenSSL 3.1.5 once it is released. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.13 once it is released. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1x once it is released (premium support customers only). OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zj once it is released (premium support customers only). Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit x (for 3.2), commit x (for 3.1) and commit x (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit x (for 1.1.1) and in commit x (for 1.0.2). This issue was reported on 23rd November 2023 by Bahaa Naamneh (Crosspoint Labs). The fix was developed by Matt Caswell. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20240125.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.htm -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmWyq2gACgkQ2cTSbQ5g RJFubAf/QN+25L2Kmev6Lk9P1BK8E2jZG+l9sa2O82tJwOyjRIimPQ0BW7KXwnKx M+oEr952wwiCu/1I7dECn3/BOtQ/TDBVaELvS2W40RVyn4gGd2jD3igkrMsNb+Xu U5oAu+kwfHp+PHhhCBxiGHVxj9cea17H3qH5DQZ4YK/X0ygdq16vvOBjNwkP8WTV adfnWr107NvqUGCxhCDexyx1+YUWAdKuVfaKjkw6jBfR/MUPwH6qqBttfpqPUr1Z o6bptN12iCuK9pQxFrUypL1OjsV83IMuxsBr0SOkrOH8+J7E9n33/xJZ7USRGSDY rTBsL12SFQ8nxODAzgJOVT5QOp5Ayg== =BQuZ -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [15th January 2024] = Excessive time spent checking invalid RSA public keys (CVE-2023-6237) = Severity: Low Issue summary: Checking excessively long invalid RSA public keys may take a long time. Impact summary: Applications that use the function EVP_PKEY_public_check() to check RSA public keys may experience long delays. Where the key that is being checked has been obtained from an untrusted source this may lead to a Denial of Service. When function EVP_PKEY_public_check() is called on RSA public keys, a computation is done to confirm that the RSA modulus, n, is composite. For valid RSA keys, n is a product of two or more large primes and this computation completes quickly. However, if n is an overly large prime, then this computation would take a long time. An application that calls EVP_PKEY_public_check() and supplies an RSA key obtained from an untrusted source could be vulnerable to a Denial of Service attack. The function EVP_PKEY_public_check() is not called from other OpenSSL functions however it is called from the OpenSSL pkey command line application. For that reason that application is also vulnerable if used with the "-pubin" and "-check" options on untrusted data. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. OpenSSL versions 3.0.0 to 3.0.12, 3.1.0 to 3.1.4 and 3.2.0 are vulnerable to this issue. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 0b0f7abf (for 3.2), commit a830f551 (for 3.1) and commit 18c02492 (for 3.0) in the OpenSSL git repository. This issue was reported on 2nd November 2023 by OSS-Fuzz. The fix was developed by Tomas Mraz. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20240115.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- iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmWlJXsACgkQUnRmohyn nm067Q//X41VgBUcS9YWimbkD7Pj1nWIhgOUOTaXcBTkroNOjgiJOBuqnOKJorj6 N0KuAA9d+Jq3xVFbwFNiZZDl2O3Az8nmW9Yg63xyoZNXeB/80ZhUCcxX+mrnKeSt XUJ8y5bSLuFrDsSp1Ew+xnfAo8DXn3DhRwHKi9Ww0kwdAN5+j84mtnGC3MfTAdLN 2WAnRY/AJGL4dACB2HEMz0zv6wU8QtV0hQUOwsDus8zw+6jkdOWpnadmqzA884MS qJsKFLUN+ca64E0VsjLzHipJK464Qdyp1QIm7QG6hZtb3IDjb6oK4zo1M7bGvR+O Wt6NKUMUovVYX6h3/e+Qpki0RS2rdxqbjTcXms2ijq/70iNrhP5p7nMfQWUkQM9G QDwV0E+5OvOh1t1eHnn7MjGhUGEhTGeGXJ/oACt96i47lzYtobovi2y+B0fRhsuf L8CPrArteBsFcPDyS/1Z/88HmOtDa9QhCawvAv9j8pwZgBxR0BV9fqsG4i+Mshdl h88J/Xbd5+Gzp1Zt8F2eQlYk8xL3aPrIOmuYym3wbiXXXSRI894jyae7+AV2WItK 1FBVXw4wlh+ZPOaAOMEirxYMZ5+6c2wYyd9XEHlw+J6vjU+/CtM0Z2SYg/b56dkJ ko/9Dor3UF6JjWdfOZqZXEOk8Rk20VHF9lDllJk8Xu2GAO5Wuug= =UUwr -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [9th January 2024] POLY1305 MAC implementation corrupts vector registers on PowerPC (CVE-2023-6129) Severity: Low Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications running on PowerPC CPU based platforms if the CPU provides vector instructions. Impact summary: If an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL for PowerPC CPUs restores the contents of vector registers in a different order than they are saved. Thus the contents of some of these vector registers are corrupted when returning to the caller. The vulnerable code is used only on newer PowerPC processors supporting the PowerISA 2.07 instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However unless the compiler uses the vector registers for storing pointers, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of this AEAD cipher is with TLS protocol versions 1.2 and 1.3. If this cipher is enabled on the server a malicious client can influence whether this AEAD cipher is used. This implies that TLS server applications using OpenSSL can be potentially impacted. However we are currently not aware of any concrete application that would be affected by this issue therefore we consider this a Low severity security issue. OpenSSL versions 3.0.0 to 3.0.12, 3.1.0 to 3.1.4 and 3.2.0 are vulnerable to this issue. The FIPS provider is not affected because the POLY1305 MAC algorithm is not FIPS approved and the FIPS provider does not implement it. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 5b139f95 (for 3.2), commit f3fc5808 (for 3.1) and commit 050d263 (for 3.0) in the OpenSSL git repository. This issue was reported on 9th October 2023 by Sverker Eriksson (Ericsson). The fix was developed by Rohan McLure (IBM). General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20240109.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- iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmWddmsACgkQUnRmohyn nm3nyBAAokn+TaX6ctAfk5TddGFSLabmBWOieIt52qAEqVxOnOn3IK/Ezuv6x3Gk SrXzuTY9w8mAezME2ZUrDULuixji0u/n84RRXCqJaAo0s4bPl5BY9munrG+2dBsh rusDdd8bzYdeDtRLjVeYjqMreVrpDSVx8JKto/nKcxK1w/yrzCXwpTe+n6pDu8PI OXQAcnDvFXWN7I7x23XQrv/Gx2crwNo3GuV1Seoih+595dAjjeyTsxChQCAwAooV MoCrHjdur6l9ALlQBj3Y4zZkBcyuUV4ngiNiptBVcBQB+ktcaVzMp2C6AVz3xARJ eiVXBAflL/UVkYcskgBeZfuDxS/NBcImpyKyjrfp5HQPh7ahqeyLdQraQBh82VjJ ArpKzLP/Ngl6QsCikkJZKEGAP7hTlaXShmNyKy7qIGmMNadMV4epL+lNxEEXk9aP f65obbiumGsBypY/4BzIEv2Kr9EXXeVJiHibscAaWch5e3q9e0eQuLXO/TOHpxLf NEhOXVSpBt6sp4C6hgztRTIX3/2H/xTH4ZqVwJezhra2x9ytrIDhiQVzOvE5tDdH Kzr+ydZhp7H/3NrhO2LgIHC67McU3MQNv44xUx9UTm1WaspZiZtqgP+vrgEfffs4 Vx9Uv06OxZmTD/X2OHzgNhkqN5FwHaRUhnWmRzt63XThHO1Rxm4= =8de2 -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [6th November 2023] = Excessive time spent in DH check / generation with large Q parameter value (CVE-2023-5678) == Severity: Low Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. While DH_check() performs all the necessary checks (as of CVE-2023-3817), DH_check_pub_key() doesn't make any of these checks, and is therefore vulnerable for excessively large P and Q parameters. Likewise, while DH_generate_key() performs a check for an excessively large P, it doesn't check for an excessively large Q. An application that calls DH_generate_key() or DH_check_pub_key() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. DH_generate_key() and DH_check_pub_key() are also called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate(). Also vulnerable are the OpenSSL pkey command line application when using the "-pubcheck" option, as well as the OpenSSL genpkey command line application. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue. OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit ddeb4b6c6d527e54ce9a99cba785c0f7776e54b6 (for 3.1) and commit db925ae2e65d0d925adef429afc37f75bd1c2017 (for 3.0). It is available to premium support customers in commit 710fee740904b6290fef0dd5536fbcedbc38ff0c (for 1.1.1) and in commit 34efaef6c103d636ab507a0cc34dca4d3aecc055 (for 1.0.2). This issue was reported on 16th August 2023 by David Benjamin (Google). The fix was developed by Richard Levitte. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20231106.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/general/security-policy.html -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAmVJCvoACgkQ1enkP335 7oytjRAAl2eNIEk0dNel7QoTFCTyXFl7IWUqWqNqx1WEr4oD/2SnFiOtQzOGl1U2 +Wr7y0GBz1cfY7xj5yw3JBajnq8v92rWHXfLheN4makflwhHwjx/faX/uTGey5Xp +5ZdKZTnkSMC4gY4gS3/SWlmyHZAYVjs/OJIlKXNYRl0q+91OBydQEcixvetIF+c tdog1im+92xvkOtm6RfYJXEg84keft4twzw+xxeiFQ8c856SvBOSEtIhewpF9gyo mP2QS8/Ne6zeLXuw52pbwc/nXSXR1qPSwv+PDcDMIaVtAKYthdMbsugW05pNori1 +bjbDQ9lM+No+jtbkWXObGKuXciWCnqGmKxgBIDCmpvTKSVJ2Bfnewy08a+nMkG4 ZNmvOpF53dqVAaJRMPPZURW5697cYteF1WDWen48rx+eEP96KGB0u/jPitF1yGWC larXfkpeoL8nK8c8BZS9wF1J8xUfH1TBzl78YdQInI6yNH1cIXCYquGPVYgJQU4O TIQwqYCghL2+c46AkooepW5E7ltWK7LHB/64BU7BiTZeMKH+DO8L1YvFgliZLpzo v9n3amunUylXzdcDznt01PtIwzTsEAKioxl0Xq7k9EQyNAdx3BL21MifkjxofUTV 54AyaYXtBVHNxqsZrdv6wVGc7F23vqmhmtS5IpgPkxtDQzKWdYk= =FBln -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [24th October 2023] = Incorrect cipher key & IV length processing (CVE-2023-5363) === Severity: Moderate Issue summary: A bug has been identified in the processing of key and initialisation vector (IV) lengths. This can lead to potential truncation or overruns during the initialisation of some symmetric ciphers. Impact summary: A truncation in the IV can result in non-uniqueness, which could result in loss of confidentiality for some cipher modes. When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after the key and IV have been established. Any alterations to the key length, via the "keylen" parameter or the IV length, via the "ivlen" parameter, within the OSSL_PARAM array will not take effect as intended, potentially causing truncation or overreading of these values. The following ciphers and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB. For the CCM, GCM and OCB cipher modes, truncation of the IV can result in loss of confidentiality. For example, when following NIST's SP 800-38D section 8.2.1 guidance for constructing a deterministic IV for AES in GCM mode, truncation of the counter portion could lead to IV reuse. Both truncations and overruns of the key and overruns of the IV will produce incorrect results and could, in some cases, trigger a memory exception. However, these issues are not currently assessed as security critical. Changing the key and/or IV lengths is not considered to be a common operation and the vulnerable API was recently introduced. Furthermore it is likely that application developers will have spotted this problem during testing since decryption would fail unless both peers in the communication were similarly vulnerable. For these reasons we expect the probability of an application being vulnerable to this to be quite low. However if an application is vulnerable then this issue is considered very serious. For these reasons we have assessed this issue as Moderate severity overall. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this because the issue lies outside of the FIPS provider boundary. OpenSSL 3.1 and 3.0 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.12. OpenSSL 3.1 users should upgrade to OpenSSL 3.1.4. This issue was reported on 21st September 2023 by Tony Battersby of Cybernetics. The fix was developed by Dr Paul Dale. This problem was independently reported on the 3rd of December 2022 as part of issue #19822, but it was not recognised as a security vulnerability at that time. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20231024.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/general/security-policy.html OpenSSL 1.1.1 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE78CkZ9YTy4PH7W0w2JTizos9efUFAmU33bsACgkQ2JTizos9 efVwAg/8Dh8qiBA3LEzTP39JtwAZzf0MPUEe0I5bvS7GUXIX8EemYojcNyoa/i+x Lr/DQtRJ0j/woiy2PhMFbej+NNMwtHD4Cu83JB+wEEiXbnt4n5yi+rWb9hw19Fs6 g17EDbsi1j5fgCQ81Psgxg02bgC/3iE2AnDYty6mRQnfMPe599SMUEnUsRfeGdTh QGOwLbAH58a3OydMFD5tUHY6JKKwU7WhLrYanAT7YIlU4oQbAIEKL7+K0roIzhyq 3o7EjtfKAr2ttcl+iOXdJYRb+0OwP59y/BBAOOOdCcb2oqDs1fPvXB8BXHhR43Ew i5EF47fUFxICu2kuXEe00RbbJipAqF5S0KvIKurYPjepukWjOqnNBQc4euned0gN bYcQgMLjYoZAp79V42kRMTQ+uMP1ElUCx4gwY8iOn6R65TmHloiNWv/q0I3XhWeH piLOv9lm/pMNmArpFGpySQzTY/wyyEvc9ZQcThSdWSiJOIebG4wFLYP+LvzG81/Q KX0yMK1dB8nyD6n+p14aIxhaWHr/7YgNO0882YbG11OQftIB5HXIXsQT5XFdVm8h OUCJfj1iPv1O3Xr7UkTISzGzRZyYLoUxFSi9+DrMHWaK9pQqSYDjqB6XE8vImnZN wJJj9hGRRZzCON5pXuh5+bIPSozdUPaZtWWm9ICobB/PLyvD05M= =aGd3 -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [8th September 2023] == POLY1305 MAC implementation corrupts XMM registers on Windows (CVE-2023-4807) = Severity: Low Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64 processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However given the contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be potentially impacted. However we are currently not aware of any concrete application that would be affected by this issue therefore we consider this a Low severity security issue. As a workaround the AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x20 OpenSSL versions 1.1.1 to 1.1.1v, 3.0.0 to 3.0.10, and 3.1.0 to 3.1.2 are vulnerable to this issue. The FIPS provider is not affected because the POLY1305 MAC algorithm is not FIPS approved and the FIPS provider does not implement it. OpenSSL version 1.0.2 is not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 4bfac447 (for 3.1), commit 6754de4a (for 3.0), and commit a632d534 (for 1.1.1) in the OpenSSL git repository. This issue was reported publicly on GitHub on 23rd July 2023 by Zach Wilson (Nvidia) and subsequently to the OpenSSL security team on 28th August 2023 by Bernd Edlinger. The fix disabling the vulnerable codepath was developed by Bernd Edlinger. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230908.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 OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmT6/5ESHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tLK8P/joFSPF9oBeoMBcSZJ5eG26WNoqvj2hh kYggHZL++wzFpBDgRwjyQW7Pm6BsythIYwId+6+QPJNCxf7juWv7vWuO42KbMqXh KnDk4NmFOKv6aF4TahfytgLzljVMwwRs9k+kmFfTNOq66NNiJBKFcIzTp7UlOkUD SOwify1Yq/du6jYyXX0tD+l6IfIEBlPPx+o5L8PG5+G+yR8bvHnlu1MrM3jYlil7 7AQjqk+115Y6cJpER9FHW5oLApK2yn3mSlQ+0Cn9LjqCaYGAlJTHe1wP9OMmV+nk fhH5S714WvMgYxfbNgAsvfLBuahJkCyZ7ddaRF/OZtU5Kk72aK+mFVqxf7hgHHd6 0W7xMIdZzhyfytQMKq3IK8bhc1T83nk83FxdDodx0XARNNoMAiYFbnQtuCtZzIM8 WVXh9Yad37Nxg27rmjYdzezyeGTGT2dlwKMhNqHlp/rf9A67sC+Lrt9UJL7nAyJo zmmNjrZQuc+WGpQvKjHxirGuRzqLxPxQNQinXK4X23QsdbiFoMB/INd+7GqKfuOE 2kdGH3hBpSoP9MrI9LHqq1G9fNnp/NOgUuwbxFXapDoNZMbOoDftpjZwCyRKqbf5 PQSDny0hDER43/MNZOnmRlnFJHMjLKxi28BqwZpt6ZmdQM8FpZkNsMWnPic1J0tK V+IiOjmRLVcj =2sPx -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [31st July 2023] == Excessive time spent checking DH q parameter value (CVE-2023-3817) == Severity: Low Issue summary: Checking excessively long DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_check(), DH_check_ex() or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. The function DH_check() performs various checks on DH parameters. After fixing CVE-2023-3446 it was discovered that a large q parameter value can also trigger an overly long computation during some of these checks. A correct q value, if present, cannot be larger than the modulus p parameter, thus it is unnecessary to perform these checks if q is larger than p. An application that calls DH_check() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. The function DH_check() is itself called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DH_check_ex() and EVP_PKEY_param_check(). Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications when using the "-check" option. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue. OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 6a1eb62c2 (for 3.1), commit 9002fd073 (for 3.0) and commit 91ddeba0f (for 1.1.1) in the OpenSSL git repository. It is available to premium support customer in commit 869ad69a (for 1.0.2). This issue was reported on 20th July 2023 by Bernd Edlinger. The fix was developed by Tomas Mraz. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230731.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 OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmTH1M4ACgkQ2cTSbQ5g RJGhtAf9E3HklBKezKOXvAbsPmCqcjySMVTV/JrBjrDn14UIRjZmhVoHd5QGusN2 ReRtA3bRL41UQYdLKDkdYjp9XmlDDFb5hKO3G7P0ldtDaw21TkIQeI/90OKjgsQu A+vpf/TcE1a1Pbz8cIRKYBjIaS3z9yIDW4eB0gytWxsqMxze+9IOYNuAbDa0KsqO PFTUiHr5xu01wsdVdHeUMpZ01E8tGbVwgyY7tvCUAUJcjjLcTb9+gXQLn6cmVRJt 6kU8jsamkiYpL1MoKI5yQvYx0nXZUxXbH1ICPltytC4pBsMEypCCnJTkcJKhRRNt 76Z4/x3XDqMzapYMPimIRifdzPV9FQ== =Ve/V -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenSSL Security Advisory [19th July 2023]
==
Excessive time spent checking DH keys and parameters (CVE-2023-3446)
Severity: Low
Issue summary: Checking excessively long DH keys or parameters may be very slow.
Impact summary: Applications that use the functions DH_check(), DH_check_ex()
or EVP_PKEY_param_check() to check a DH key or DH parameters may experience long
delays. Where the key or parameters that are being checked have been obtained
from an untrusted source this may lead to a Denial of Service.
The function DH_check() performs various checks on DH parameters. One of those
checks confirms that the modulus ("p" parameter) is not too large. Trying to use
a very large modulus is slow and OpenSSL will not normally use a modulus which
is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus value
even if it has already been found to be too large.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulernable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the "-check" option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit fc9867c1 (for 3.1),
commit 1fa20cf2 (for 3.0) and commit 8780a896 (for 1.1.1) in the OpenSSL git
repository. It is available to premium support customer in commit 9a0a4d3c (for
1.0.2).
OSSfuzz first detected and automatically reported this issue on 25th June
2023 using a fuzzer recently added to OpenSSL written by Kurt Roeckx. The fix
was developed by Matt Caswell.
General Advisory Notes
==
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20230714.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
OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security
fixes for 1.1.1 will only be available to premium support customers.
-BEGIN PGP SIGNATURE-
iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmS3yhISHHRvbWFzQG9w
ZW5zc2wub3JnAAoJEFJ0ZqIcp55tn1MP/3rGGOFg5XqhMW5hjzdH/u7wbZSQIBGr
PwGCCYm8McrgHsmqvE5efo5QIxjNj09xS/6+h+WsWeXkAvuL37idzQ5FC8oAlop2
XvjI0bJfCNQA8NcEFecWROHv9G7XEX7g+yV/yBUkT1CnuzqNjdnNeqBCIYafTE/x
X4mZKaj/dJZTB/c8XI5foGZ9RklsO3QqrPt2DGhusP/u57ayghWLqv/7EyogDyeS
2FfB1yYsM0pmO7TjzrSlVhwPqAmsNGwOYVH8ggHGr9pRIbRQhrfKKVqn+o/5JLeR
XXIXQGTiXhs0eDcO3N+kgWf0PXpuA5x03EZlrGOJoJLf0Gw6Mds8mjMD8s1RWJbD
pogwwfGEavedW5WUH1f1W1cpoHqmSNwGrFIJJfZ0t1X4/z8/U6CipF6bCCjfEiFS
ROzOkj44O8rXNwU4+ACxBx/E+PLpP0zhn9uJNTzBfMTonFNyWxuFwpVv3EIHrrq+
YB/ccvbWXapejxIRHhrI41eA7tflZAPBNw8CwBfBRfQbJ+BOveKjGhaGfe3JUDiO
Ry97AGuRGlSCkhUrW9Iy5qrNTnT6AFbdUDpip77UUQDn1eYusW5YtHsLiJpouFq+
MPMn0B7mJypHjvDm4QeaUuJMaYHvcJtpRN684MXfBkcMsAldeYuwO0dl3E3HB5Dr
uP4KAxS6q91M
=sghT
-END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [14th July 2023] == AES-SIV implementation ignores empty associated data entries (CVE-2023-2975) Severity: Low Issue summary: The AES-SIV cipher implementation contains a bug that causes it to ignore empty associated data entries which are unauthenticated as a consequence. Impact summary: Applications that use the AES-SIV algorithm and want to authenticate empty data entries as associated data can be misled by removing, adding or reordering such empty entries as these are ignored by the OpenSSL implementation. We are currently unaware of any such applications. The AES-SIV algorithm allows for authentication of multiple associated data entries along with the encryption. To authenticate empty data the application has to call EVP_EncryptUpdate() (or EVP_CipherUpdate()) with NULL pointer as the output buffer and 0 as the input buffer length. The AES-SIV implementation in OpenSSL just returns success for such a call instead of performing the associated data authentication operation. The empty data thus will not be authenticated. As this issue does not affect non-empty associated data authentication and we expect it to be rare for an application to use empty associated data entries this is qualified as Low severity issue. OpenSSL versions 3.0.0 to 3.0.9, and 3.1.0 to 3.1.1 are vulnerable to this issue. The FIPS provider is not affected as the AES-SIV algorithm is not FIPS approved and FIPS provider does not implement it. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 6a83f0c9 (for 3.1) and commit 00e2f5ee (for 3.0) in the OpenSSL git repository. This issue was reported on 16th May 2023 by Juerg Wullschleger (Google). The fix was developed by Tomas Mraz. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230714.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 OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmSxxSgACgkQUnRmohyn nm3ogw//Zqnff7kHNFaqXQB7plwif+utEBi6/siMNC+/bTn8RSRWsuIJp0vgGTB/ EEkiD2vK5Twrf1mYpKgOiCdQq2AaneHbjqcLtkmBS2apeXcGsBB6ZQgJKe1kRhaL nC87QJKuUdlQojS4+SBD+MIz/ET1uQNsjjvKfANpKK0L4TgUs2tHNskZG3H6p4az Kt0uhKaAFBp7jGb+wt3zYIgoyLvnZvx51mIwrf/vv3VAJl8OgEgG+hIk+8AtAVEa ZCWmkDRuuJxEHuwCjX0iSncwqIViph1JnpqnrXARNcdfZCMdAIfEmVdSTfXmmlQr TmQPDiBDIlk5ZjHlOGbVCEkUnPQAwiKEQ5bi0x4zI1e/yN64RTARjjaXn5nQsyTf XHHqFQNSCZ9Fpc4JVuJsSzzxnALKuzIC6uUwzPZxfDQ844e7EBim/V42kcbKizbZ N073hrxkm54nGRdfXkDguGPGK82GwHJnxPo7COBiBnROswWK++o2eW9PJwD2Vkt3 dQ7t58YXDc+76+yE+L4mYuF6ml6wmUPx9kBzhzBxjgINZod5O8YyuTRrqnRbtsFU yasNBspjAaVdS5zRFewn4ghQTKIv6OfBn2fTIUNVCfXeAR9Dzd5Ts5zAcYJTaT3o NNLUBwvP+Fcm2rE2RZ3p6n6YmQLiY8URjtxGGPxJsLDaCTw6IiY= =eZhV -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [30th May 2023] = Possible DoS translating ASN.1 object identifiers (CVE-2023-2650) = Severity: Moderate Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow. Impact summary: Applications that use OBJ_obj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service. An OBJECT IDENTIFIER is composed of a series of numbers - sub-identifiers - most of which have no size limit. OBJ_obj2txt() may be used to translate an ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSL type ASN1_OBJECT) to its canonical numeric text form, which are the sub-identifiers of the OBJECT IDENTIFIER in decimal form, separated by periods. When one of the sub-identifiers in the OBJECT IDENTIFIER is very large (these are sizes that are seen as absurdly large, taking up tens or hundreds of KiBs), the translation to a decimal number in text may take a very long time. The time complexity is O(n^2) with 'n' being the size of the sub-identifiers in bytes (*). With OpenSSL 3.0, support to fetch cryptographic algorithms using names / identifiers in string form was introduced. This includes using OBJECT IDENTIFIERs in canonical numeric text form as identifiers for fetching algorithms. Such OBJECT IDENTIFIERs may be received through the ASN.1 structure AlgorithmIdentifier, which is commonly used in multiple protocols to specify what cryptographic algorithm should be used to sign or verify, encrypt or decrypt, or digest passed data. Applications that call OBJ_obj2txt() directly with untrusted data are affected, with any version of OpenSSL. If the use is for the mere purpose of display, the severity is considered low. In OpenSSL 3.0 and newer, this affects the subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS. It also impacts anything that processes X.509 certificates, including simple things like verifying its signature. The impact on TLS is relatively low, because all versions of OpenSSL have a 100KiB limit on the peer's certificate chain. Additionally, this only impacts clients, or servers that have explicitly enabled client authentication. In OpenSSL 1.1.1 and 1.0.2, this only affects displaying diverse objects, such as X.509 certificates. This is assumed to not happen in such a way that it would cause a Denial of Service, so these versions are considered not affected by this issue in such a way that it would be cause for concern, and the severity is therefore considered low. No version of the FIPS provider is affected by this issue. OpenSSL 3.0.x and 3.1.x are vulnerable to this issue. OpenSSL 1.1.1 and 1.0.2 users may be affected by this issue when calling OBJ_obj2txt() directly. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.9. OpenSSL 3.1 users should upgrade to OpenSSL 3.1.1. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1u. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zh (premium support customers only). OSSfuzz first detected and automatically reported this issue on 16th January 2020. At that time OpenSSL 3.0 was still in early development and it was not identified as a security concern at that time. On 23rd April 2023 the issue was reexamined and identified as a security issue by Matt Caswell. The fix was developed by Richard Levitte. (*) A measurement showed about 2 seconds for 100KiB and a minute for 500KiB. This measurement wasn't made to demonstrate exact time ranges, but rather to demonstrate the quadratic nature of the issue. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230530.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/general/security-policy.html OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmR1/kQSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tXS0QAJpUoGfoirteiNuvdRy4PP72E0ZHVsll 2PlsArtQwogpEJD5Z4Escq+Cb7ZPl7uqBdfosJTX31Kr3e/ri6HY3Bzjxa1xOKUo GHC/RADZqGWemBiabr9BDtJAaadQDS3a8tGSklgab0ueHtCX9zX0ptWE3lW8NGp5 DXQ4pBVzGHpldHgN8OLhpreshbw9RJNvdAXrl445MtUNXy4rJYRTqlHCqwH6qjCM a/a6sFaIevgspm85L30YWtx38T+vqfNFhl9RZuKbQB9PlL1g3UWpsnvVUCSrXytH ehlNhyfCX03vNn4Ym/Gp9cj5/1EM0wsF6EVuXGBe6+D/vwh5eLTPgndLr8KKo12C ysJF4dGdLSKg3KaL6xV4Km+XXv8S4s4MF9FOYqachF6hnBWyTdwkVcTNWBYPmexS Kw/MpXku65hWrjZT9FGfoFsl3RBYOde9E31ubd6/gUANkzF8jqaMfn966oCmoz2O uQb29gjEKUQWZD8Es23Yub3Jj0wTvN1i03fIhrzzbgoIR/RGOX
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [20th April 2023] === Input buffer over-read in AES-XTS implementation on 64 bit ARM (CVE-2023-1255) == Severity: Low Issue summary: The AES-XTS cipher decryption implementation for 64 bit ARM platform contains a bug that could cause it to read past the input buffer, leading to a crash. Impact summary: Applications that use the AES-XTS algorithm on the 64 bit ARM platform can crash in rare circumstances. The AES-XTS algorithm is usually used for disk encryption. The AES-XTS cipher decryption implementation for 64 bit ARM platform will read past the end of the ciphertext buffer if the ciphertext size is 4 mod 5, e.g. 144 bytes or 1024 bytes. If the memory after the ciphertext buffer is unmapped, this will trigger a crash which results in a denial of service. If an attacker can control the size and location of the ciphertext buffer being decrypted by an application using AES-XTS on 64 bit ARM, the application is affected. This is fairly unlikely making this issue a Low severity one. OpenSSL versions 3.0.0 to 3.0.8, and 3.1.0 are vulnerable to this issue, including the FIPS provider in those versions. OpenSSL versions 1.1.1 and 1.0.2 are not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit bc2f61ad (for 3.1) and commit 02ac9c94 (for 3.0) in the OpenSSL git repository. This issue was reported on 27th February 2023 by Anton Romanov (Amazon). The fix was developed by Nevine Ebeid (Amazon). General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230420.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 OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmRBYoMSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tRl4P/3pRFLUviJ+dgVd0DV25ViBRI2qEOF9O FrcpB2buCF6JA2MQBKFV4x6kMjgzjFkj3LyP9eqUCfw6VhRtR6cnVXgUNi+XX3OL x8fxMY6OmEy67Oq/w7FL7mth1Rz5trDJWhCoAoKvaBYOWzLhPQVqIXaJ7MY8HPGv qoLt2ODYbm0D44LCXiigTIO13HIF5MRRxex1C2+c2ZO7XV3pq0Sr4xcVyBAcneHW /dyYNeEsLBaa39QrFoz/h/C96pCHwc10DKRVFUC8q3o10Bs+D46sueoe666cLfeN pm2Y/AYaXKLCCFRT3IDJwXgBtcLt+PrZr3C3iyVrCWOcoHzfNS5BzTKOQMv/CSkW KEK7ezqOBWvvzeEcFeg6mUcILVRanUEKS+u4tZQ6JzJAck1CHjpcRQVNbxhayjzM dTASVeLzb4xrXVVMYLqKeVBACGcOo69oyssnORDg7/iBW/Gm5toUraS/8uKft51W NsBUV4A4eagE4VNwCT9mFH7uAXjQgWggivdA6PtaUf/S69wy5Dh1cWc+XWd3suj8 QgPTU3H0E86BTbIAkBQUatWmMnFc1gxhUpEo+rcGZY00Zkrz42PoCP/pFDsszUt6 JAlFPS7xQNYAgaUAnkyMTbkSDqFbm8nppAY6l6HpYEVywagoXtSPEgn+miSOJn6S 7I/fm11VSkjm =SU46 -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [28th March 2023] === Invalid certificate policies in leaf certificates are silently ignored (CVE-2023-0465) == Severity: Low Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit facfb1ab (for 3.1), commit 1dd43e07 (for 3.0), commit b013765a (for 1.1.1) in the OpenSSL git repository, and commit 10325176 (for 1.0.2) in the OpenSSL git repository for premium customers. This issue was reported on 12th January 2023 by David Benjamin (Google). The fix was developed by Matt Caswell. Certificate policy check not enabled (CVE-2023-0466) Severity: Low The function X509_VERIFY_PARAM_add0_policy() is documented to implicitly enable the certificate policy check when doing certificate verification. However the implementation of the function does not enable the check which allows certificates with invalid or incorrect policies to pass the certificate verification. As suddenly enabling the policy check could break existing deployments it was decided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy() function. Instead the applications that require OpenSSL to perform certificate policy check need to use X509_VERIFY_PARAM_set1_policies() or explicitly enable the policy check by calling X509_VERIFY_PARAM_set_flags() with the X509_V_FLAG_POLICY_CHECK flag argument. Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications. OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. Applications need to be updated if they are affected by the issue. Due to the low severity of this issue we are not creating a new release at this time. The documentation fix is also available in commit fc814a30 (for 3.1), commit 51e8a84c (for 3.0), commit 0d16b7e9 (for 1.1.1) in the OpenSSL git repository, and commit 73398dea (for 1.0.2) in the OpenSSL git repository for premium customers. This issue was reported on 12th January 2023 by David Benjamin (Google). The documentation fix was developed by Tomas Mraz. General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230328.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 OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -BEGIN PGP SIGNATURE- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmQi8tMSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tem4P/3ujaUzEUXSMAX58jCiMzScB8o1HFyo1 KQguXKh41dM7ooehR4J8JjveH6PExw2C0fI7CzROjdlOkcd66jfokJb5CIOTf3zs 0pDn0gH1TcY4skKlUkFoo8d51ql3zlySxLX5MGEUiUq43U+H2sog/cLaMl5KJRJ4 kDBGksdgsAb1o6rCcXpTHw40Dq5cEr3HaSy6hbbxubjt8SQv8fbK2vkZPu3pVwfw RR6w8K43aiDwcEC6eMPO5QOx3xTOFGU0tUNEG11QZhb2gOkmgshjRBZmbf9mEyU2 mTk0P8G6ttlVP80qqXA33lSXIJlfpTqqSx9rlx6ovO4iu0TZPJYETkAhP6nBvEU6 eyy/RTSphBUK4uSh44K3RTMcnPAvplZdzlX9jOHfiuOjwG1ff8pxWnJZt0s77MNI ByCKaOWwhyoph3jxkt+k4AP0f229qxFxryz1UKXWQ+2BXtXusXFVGs70FwHIvSWV nGpLKXedCnebPaQqlYKqFWmJPsDf4iEcSgluFyFr4zYW7+dN+7hNF3gFzYJjSCIo jvnKktMk3Vuu8xOMJ6uQQNmGvsEyhmDYsxqNuM/6QxaQmnfEGe8+bdp21g8PBLtG z+tnX2/7Cltm/5oIHnqVclNChqjOev9rho5/QVK7eNFDcuDTWVosWPPyqbhkmVpw acx7hxvK++Zl =L6VH -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Excessive Resource Usage Verifying X.509 Policy Constraints (CVE-2023-0464) === Severity: Low A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function. OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 2017771e (for 3.1), commit 959c59c7 (for 3.0), commit 879f7080 (for 1.1.1) in the OpenSSL git repository, and commit 2dcd4f1e (for 1.0.2) in the OpenSSL git repository for premium customers. Once they are released: OpenSSL 3.1 users should upgrade to 3.1.1. OpenSSL 3.0 users should upgrade to 3.0.9. OpenSSL 1.1.1 users should upgrade to 1.1.1u. OpenSSL 1.0.2 users should upgrade to 1.0.2zh (premium support customers only). This issue was reported on 12th January 2023 by David Benjamin (Google). The fix was developed by Dr Paul Dale. OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20230322.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- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmQbItgSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55t8AgP/3mUOflbZ7e8yLjgEMqFqCSFlSQo5bFK gh2h2NOKBjkvzFtlqnAR+bqNPAr9CEosSRF1LiVtKu9RhaIh1LlTsp53aFWSP48p 7LekiPmd5hnorO72dB1eLlbHPIe0lh2It2cDlkYc95BVcttQEzHbyygVKBD0f0cN WqslsIeVPIqMIZMHAlpnINz630Rsn/4cif+6U8gYgNN51f7WeCArPp3U7hAhHVuC b7lOVXBNzdfdFzKVjSTHqvWBib/Ji+Ga4knHFZya7VLQagKjDJiQB9uBpuCOmzxD kb9nJCSroIwf74wDxJxr4gb314/hju+jpC2Xny8l7SXxJUahdMywJLgofPMEOhWb lRod8SHr0Je5Gpp4R+p6cmwr0PM76KPxcLOvsa7OsIwIZQvFyxMVvsGYdMxg0ads qDqROqkb1Mx+Fa0smySe6Xru0RtEgXAk7AIltz8AqHmCvMED8S7ZwhsHipM/eLYZ Iky8SsSYn4K3a4Sa05+IrQARWmDCZHRHp9JfHacPq0HunNrAX5unDfHUNAx1TZcX 0cSeN/SF56sds+SEjJpURCHxO+Z4toUxpaVKqZyLsDhuq/IwrbbaxhBFkNiHcWOg vCinoWvhpjo2YBs0BVJNIu4wpNhnCwOP7+91zmTAvD28xoBhSHKWkwGuypPkW3bO Y6lneBDfoNpj =iUFS -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [7th February 2023] = X.400 address type confusion in X.509 GeneralName (CVE-2023-0286) = Severity: High There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network. OpenSSL versions 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers only). This issue was reported on 11th January 2023 by David Benjamin (Google). The fix was developed by Hugo Landau. Timing Oracle in RSA Decryption (CVE-2022-4304) === Severity: Moderate A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection. OpenSSL 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t. OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers only). An initial report of a possible timing side channel was made on 14th July 2020 by Hubert Kario (Red Hat). A refined report identifying a specific timing side channel was made on 15th July 2022 by Hubert Kario. The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario. X.509 Name Constraints Read Buffer Overflow (CVE-2022-4203) === Severity: Moderate A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. The read buffer overrun might result in a crash which could lead to a denial of service attack. In theory it could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext) although we are not aware of any working exploit leading to memory contents disclosure as of the time of release of this advisory. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. OpenSSL versions 3.0.0 to 3.0.7 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 3rd November 2022 by Corey Bonnell from Digicert. The fix was developed by Viktor Dukhovni. Use-after-free following BIO_new_NDEF (CVE-2023-0215) = Severity: Moderate The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [01 November 2022] X.509 Email Address 4-byte Buffer Overflow (CVE-2022-3602) == Severity: High A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 17th October 2022 by Polar Bear. The fixes were developed by Dr Paul Dale. We are not aware of any working exploit that could lead to code execution, and we have no evidence of this issue being exploited as of the time of release of this advisory (November 1st 2022). X.509 Email Address Variable Length Buffer Overflow (CVE-2022-3786) === Severity: High A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.' character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.7. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was discovered on 18th October 2022 by Viktor Dukhovni while researching CVE-2022-3602. The fixes were developed by Dr Paul Dale. We have no evidence of this issue being exploited as of the time of release of this advisory (November 1st 2022). References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20221101.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- iQJGBAEBCAAwFiEE3HAyZir4heL0fyQ/UnRmohynnm0FAmNhRdsSHHRvbWFzQG9w ZW5zc2wub3JnAAoJEFJ0ZqIcp55tARIP/R4TFlh4N3wH4enjT74oJowxjmwNIu0q uRTmmwtMwJOd1Nw0tfydVEtd3qaN/KMcMnnBMzIzvCdzQ202g8SRSzX7zeHZtAEe idu9qQyQep1ECK7UGybdN+4Ahey30Py6J99okWejCmdHSpxo7+OOtADFdraqrV5A 5vwyojD1Iv95Z0/RqYxMmMBEoJZitsGxeraw1IxBJCqw6sL2WwDelGb9NZwKFee1 BrfeF+dwaXlAZ97Hsaai6ssDf8VOoTNbCDsrsnbo4MAbFAc6ZraynMcWMm9kwF96 y+pO+0P9etzWeHkP+qHAeCCHZqU76Rexr58XtuWQpTdmbPbmLpnwr7wgwBAZxHA0 RkhpR244vPLYrF3cIssNxEstHCi2NFX0cMtOnbY84lJfmnxgHTJqH/7LvUmHibC6 FBNM9CCSezZgEiSvERB0R/auHZnpODj9riCyWWq82sXTkk3XrqkdnN3mAjgVpnDK 3Cacx9vJxpUDl2U4ObEVCE1I1qHKomAcKVAErAMmLLsdkbzoK9dUquG2VhFaJYJW 3TtqDMhQM0fqRgRu750P42w6dm1glH/UIK41viB0eVwbBZ0RdaAnI3+Tuk2NXH2o nZdH5Lx6scgS+l4K+IF2WzO+WCYThG0Sg22hC6NnFbdksoGA/XaXl80Kf5Ec1LJr QLeTSjQDj6Fc =8mrQ -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [11 October 2022] === Using a Custom Cipher with NID_undef may lead to NULL encryption (CVE-2022-3358) Severity: Low OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls. This function was deprecated in OpenSSL 3.0 and application authors are instead encouraged to use the new provider mechanism in order to implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as other similarly named encryption and decryption initialisation functions). Instead of using the custom cipher directly it incorrectly tries to fetch an equivalent cipher from the available providers. An equivalent cipher is found based on the NID passed to EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a given cipher. However it is possible for an application to incorrectly pass NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL encryption/decryption initialisation function will match the NULL cipher as being equivalent and will fetch this from the available providers. This will succeed if the default provider has been loaded (or if a third party provider has been loaded that offers this cipher). Using the NULL cipher means that the plaintext is emitted as the ciphertext. Applications are only affected by this issue if they call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an encryption/decryption initialisation function. Applications that only use SSL/TLS are not impacted by this issue. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.6. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 9th August 2022 by Chris Rapier of the Pittsburgh Supercomputing Center. The fix was developed by Matt Caswell. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20221011.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmNFgFcACgkQ2cTSbQ5g RJFEZwf/WiGIlYQfuis0lbwvqPHEpBZkuQgnXtkZ2nOe2SAera+fUNMKGf6/Pmbx 3orhrG9xEpTyZjczccRTjZ1pimGRpF0Lyvnv/N+RjrywpD3nTpanhKPlw8cnpH6p xlqSNEgXog9E5i3y27SYbdDw2Pu4I61vZe/zzJfI/pnpgsFkJRwAKFOPDHnS9hgh J8DdaVa6iW8/cOtWBiNHpNKebpjJ+pl5ZpbGt8CYMBHAAc1V/hmuOTesybyGeI9a I2qL5WXXl0VR5bPNNkUXLLm+q0XYFahL58lx7R2qn/HL3r3YeNtFVd7u/UV581vM dLhh43faekIct7eN3TXlsSkpKEwCQg== =EO32 -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [5 July 2022] === Heap memory corruption with RSA private key operation (CVE-2022-2274) = Severity: High The OpenSSL 3.0.4 release introduced a serious bug in the RSA implementation for X86_64 CPUs supporting the AVX512IFMA instructions. This issue makes the RSA implementation with 2048 bit private keys incorrect on such machines and memory corruption will happen during the computation. As a consequence of the memory corruption an attacker may be able to trigger a remote code execution on the machine performing the computation. SSL/TLS servers or other servers using 2048 bit RSA private keys running on machines supporting AVX512IFMA instructions of the X86_64 architecture are affected by this issue. Note that on a vulnerable machine, proper testing of OpenSSL would fail and should be noticed before deployment. Users of the OpenSSL 3.0.4 version should upgrade to OpenSSL 3.0.5. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 22nd June 2022 by Xi Ruoyao. The fix was developed by Xi Ruoyao. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20220705.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 AES OCB fails to encrypt some bytes (CVE-2022-2097) === Severity: MODERATE AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised implementation will not encrypt the entirety of the data under some circumstances. This could reveal sixteen bytes of data that was preexisting in the memory that wasn't written. In the special case of "in place" encryption, sixteen bytes of the plaintext would be revealed. Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected. This issue affects versions 1.1.1 and 3.0. It was addressed in the releases of 1.1.1q and 3.0.5 on the 5th July 2022. OpenSSL 1.1.1 users should upgrade to 1.1.1q OpenSSL 3.0 users should upgrade to 3.0.5 This issue was reported to OpenSSL on the 15th June 2022 by Alex Chernyakhovsky from Google. The fix was developed by Alex Chernyakhovsky, David Benjamin and Alejandro Sedeño from Google. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAmLEEkUACgkQ1enkP335 7ozR5g/+Ofu4COpLp2VjRUuH268vwfaRCPgr9nbv3v9/KwW7FLzAWS/JqLqTmJiI GDP2TOM7jKSVh8oG8vnQ0c9DY1CULk28gaH6fp9jhfhvsblpva9Hdk74xYy3ebbR 5gLI++3WlROoGYf486R/t13X5vTLLJaun5R+3khf/i5+6SwDKrw4WM3UXNHLOxjM SFJ/hIPuVSFIHagZAzwcLMwOG+qa5JVU4i5TL9hio40Bl2gDKEkpDmj5UTWBT1Tu FZ66FMveM4sTlX3QrjWAQjAX2iq7S5Ng7PXWKsNYB4lckigG88jj2uC30oS+S8Bs /V10Yp9zlkfPAVZNo/qjy5ui+1KrZidF/deGPCs36ULbE2e9/aYFz6xfz0zfdkmr 8hgZBhMwJ+49woC45Vo67PPf7dHGvGh3OpPbApkeX0VtwPIElanf7uK8YQ/yCvYK +T8wKSDE/qcl9trTDZa567KTcv341LmxMFuVP5Ohxzfr+O1fKEPGCWepxOaP2GZY zx5MmLQmahcoYDInWr9iJD0OkySaJKWbEUM90oBHvjwY5+sW770LAX0nt8Uthb6J JPRyAeu6Un70u63GmXuPEvtuUGjYYnQsSke9/M2IgnE+1E+Hj5rfhCjWMQURUcvZ cC/hRphJ80ReuR8vEyBaN81tdr0/Dp6MUuvDnvkcYSzNHrgJL1o= =bJgr -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [21 June 2022] The c_rehash script allows command injection (CVE-2022-2068) Severity: Moderate In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. OpenSSL 1.0.2 users should upgrade to 1.0.2zf (premium support customers only) OpenSSL 1.1.1 users should upgrade to 1.1.1p OpenSSL 3.0 users should upgrade to 3.0.4 This issue was reported to OpenSSL on the 20th May 2022. It was found by Chancen of Qingteng 73lab. A further instance of the issue was found by Daniel Fiala of OpenSSL during a code review of the script. The fix for these issues was developed by Daniel Fiala and Tomas Mraz from OpenSSL. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20220621.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmKx1vMACgkQ2cTSbQ5g RJFo3gf/XY0cjt1lXtTrGBGu5lDf6Gou7USlUy4lo0wQwkHJ11b2PDxINS+xGNzp GoOSxCGcQEPrUPkQTwbTtVxSDKuIkQmQG0py155zUrKzsRTad3rIsHy+NzfweBW+ RSwTYZT702J5XRMkeaLhzqG2WY5fxibydaKRKIU2IcyvOQP4tEdrRBQ1taaYKORG ZZmlcL8Et96YgbFDotLJAeZQ9nbOnHEti7zGCvp48klOqc4llH+0QnHmRsJFxO2F QHNd0ZUsb0gzVajEOz1rBEIotS4tYDltRCkgJz7evJSPrXrbbacXflfHGsveWjgw h8Wr4I7UK1liE3lmb5LuW/BXf7CAQg== =31ys -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [03 May 2022] === The c_rehash script allows command injection (CVE-2022-1292) Severity: Moderate The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. OpenSSL 1.0.2 users should upgrade to 1.0.2ze (premium support customers only) OpenSSL 1.1.1 users should upgrade to 1.1.1o OpenSSL 3.0 users should upgrade to 3.0.3 This issue was reported to OpenSSL on the 2nd April 2022. It was found by Elison Niven of Sophos. The fix was developed by Tomas Mraz from OpenSSL. OCSP_basic_verify may incorrectly verify the response signing certificate (CVE-2022-1343) = Severity: Moderate The function `OCSP_basic_verify` verifies the signer certificate on an OCSP response. In the case where the (non-default) flag OCSP_NOCHECKS is used then the response will be positive (meaning a successful verification) even in the case where the response signing certificate fails to verify. It is anticipated that most users of `OCSP_basic_verify` will not use the OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return a negative value (indicating a fatal error) in the case of a certificate verification failure. The normal expected return value in this case would be 0. This issue also impacts the command line OpenSSL "ocsp" application. When verifying an ocsp response with the "-no_cert_checks" option the command line application will report that the verification is successful even though it has in fact failed. In this case the incorrect successful response will also be accompanied by error messages showing the failure and contradicting the apparently successful result. This issue affects OpenSSL version 3.0. OpenSSL 3.0 users should upgrade to 3.0.3 This issue was reported to OpenSSL on the 6th April 2022 by Raul Metsma. The fix was developed by Matt Caswell from OpenSSL. Incorrect MAC key used in the RC4-MD5 ciphersuite (CVE-2022-1434) = Severity: Low The OpenSSL 3.0 implementation of the RC4-MD5 ciphersuite incorrectly uses the AAD data as the MAC key. This makes the MAC key trivially predictable. An attacker could exploit this issue by performing a man-in-the-middle attack to modify data being sent from one endpoint to an OpenSSL 3.0 recipient such that the modified data would still pass the MAC integrity check. Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 endpoint will always be rejected by the recipient and the connection will fail at that point. Many application protocols require data to be sent from the client to the server first. Therefore, in such a case, only an OpenSSL 3.0 server would be impacted when talking to a non-OpenSSL 3.0 client. If both endpoints are OpenSSL 3.0 then the attacker could modify data being sent in both directions. In this case both clients and servers could be affected, regardless of the application protocol. Note that in the absence of an attacker this bug means that an OpenSSL 3.0 endpoint communicating with a non-OpenSSL 3.0 endpoint will fail to complete the handshake when using this ciphersuite. The confidentiality of data is not impacted by this issue, i.e. an attacker cannot decrypt data that has been encrypted using this ciphersuite - they can only modify it. In order for this attack to work both endpoints must legitimately negotiate the RC4-MD5 ciphersuite. This ciphersuite is not compiled by default in OpenSSL 3.0, and is not available within the default provider or the default ciphersuite list. This ciphersuite will never be used if TLSv1.3 has been negotiated. In order for an OpenSSL 3.0 endpoint to use this ciphersuite the following must have occurred: 1) OpenSSL must have been compiled with the (non-default) compile time option enable-weak-ssl-ciphers 2) OpenSSL must have had the legacy provider explicitly loaded (either through application code or via configuration) 3) The ciphersuite must have been explicitly added to the ciphersuite list 4) The libssl security level must have been set to 0 (default is 1) 5) A version of SSL/TLS below TLSv1.3 must have been negotiated 6) Both endpoints must negotiate the RC4-MD5 ciphersuite in preference to any others that both endpoints have in common This issue affects OpenSSL version 3.0. OpenSSL 3.0
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [15 March 2022] Infinite loop in BN_mod_sqrt() reachable when parsing certificates (CVE-2022-0778) == Severity: High The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers only) OpenSSL 1.1.1 users should upgrade to 1.1.1n OpenSSL 3.0 users should upgrade to 3.0.2 This issue was reported to OpenSSL on the 24th February 2022 by Tavis Ormandy from Google. The fix was developed by David Benjamin from Google and Tomáš Mráz from OpenSSL. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. It is affected by the issue. Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20220315.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmIwtOcACgkQ2cTSbQ5g RJGd6wf/VColq7YEnA1dKQvd75ytnFkV8tUhb1uQ9eCjhxk76ASg3QToEar3yDd3 ykGXJZy5oPCl0zG33GORz9Pq8oWjIoCDLfhlTh3aORjWZ9uMkd+RWxVEjxyidgZp 4Rb8p5qSncxJ1EcYLoeUWu/lrDh67q1hDnwGNtNxyzVC0sqxWz++YoFXGJA2OH0m lcYZilUdZ4HLVKmFKEfQGX/xwdvxj3VTaJNjsEI+2h1xysXBN+TpXsEL2yOGx8Cq KzQXnRUrNhsdIQYEAJ7i3HXYmY0wHehTXvBoZsI/2yWiC19WWK8u/qZxdc3Y88v3 JDKNJRCyKGbji+ESZPnWB14yE3yZ0g== =9ROi -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [28 January 2022] === BN_mod_exp may produce incorrect results on MIPS (CVE-2021-4160) Severity: Moderate There is a carry propagation bug in the MIPS32 and MIPS64 squaring procedure. Many EC algorithms are affected, including some of the TLS 1.3 default curves. Impact was not analyzed in detail, because the pre-requisites for attack are considered unlikely and include reusing private keys. 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 significant. However, for an attack on TLS to be meaningful, the server would have to share the DH private key among multiple clients, which is no longer an option since CVE-2016-0701. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.0. It was addressed in the releases of 1.1.1m and 3.0.1 on the 15th of December 2021. For the 1.0.2 release it is addressed in git commit 6fc1aaaf3 that is available to premium support customers only. It will be made available in 1.0.2zc when it is released. The issue only affects OpenSSL on MIPS platforms. If that applies then: OpenSSL 1.0.2 users should apply git commit 6fc1aaaf3 (premium support customers only) OpenSSL 1.1.1 users should upgrade to 1.1.1m OpenSSL 3.0.0 users should upgrade to 3.0.1 This issue was found on the 10th of December 2021 and subsequently fixed by Bernd Edlinger. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20220128.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmH0AK4ACgkQ2cTSbQ5g RJG4Agf9HqZVxd3uG7Jq8TnM4HIR5lrQaJAq6pszxqGvSSmjmK6fkVf8G0PI6I4M J8gmlLMfnvDiE2a1yfmzAlXQu3+nTFRMlkkrpfPoBPIrX3ceHa+uRLIlvDm6jTeu vEV+Zko71AlgDb4cGGP9beAEh6l2pPS2DZ94nEiK2LWl6nIUTaTWuV0WACVHnadk Xj6YrDtbM9LpW/yELg4nUvrLCn72D+T3rjaDZVfQHCjw97/TJnSOApv5u0EgBiIi lT3zXBT83qHDsPEfXvQ3Mk4wQiloAmOO4g9B68S84qXq/J8JSowydCQBKhOVQ9uo u3EDFqOsMHS6ahex7RfBnvML0FBXbA== =RvBK -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [14 December 2021] Invalid handling of X509_verify_cert() internal errors in libssl (CVE-2021-4044) Severity: Moderate Internally libssl in OpenSSL calls X509_verify_cert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSL_connect() or SSL_do_handshake()) to not indicate success and a subsequent call to SSL_get_error() to return the value SSL_ERROR_WANT_RETRY_VERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSL_CTX_set_cert_verify_callback(). Since most applications do not do this the SSL_ERROR_WANT_RETRY_VERIFY return value from SSL_get_error() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509_verify_cert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. OpenSSL 3.0.0 SSL/TLS clients are affected by this issue. Users of this version should upgrade to OpenSSL 3.0.1. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue. This issue was reported to OpenSSL on 29th November 2021 by Tobias Nießen. The fix was developed by Matt Caswell and Tobias Nießen. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20211214.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmG4zbUACgkQ2cTSbQ5g RJG+TggAsQHgwpwy2j4FPzKFAar5hM+3cMI9hZUECu5VJBZaVUQM3fBY5Um16T5L n6weB9EFe+xpA2ncuuDeUWGvACW5oj6j/obfse4cIRc2K4XfHNydzCi/EB1cG1Qi d4/dqw4I8KgyZkk7iyZawtQ+vslSefsUbYSqrslBiETK7VMGjIrxNy7ohMadFdA7 E8dYicPPjkYX/4+vs/W0RiAe4kFAHKTFZIvh2ab65CBubAOGDS0CFavd57FvC10Y UquSKdBIWIIlfueQ8IhYx3v/VEOvS4Q8OpkPkfuoRu0j3qX8lvyHV+gipHD9MK9q zI7Kj9oa+mUqyT5cp3mhIbSqq3Qm0A== =xJgY -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [24 August 2021] == SM2 Decryption Buffer Overflow (CVE-2021-3711) == Severity: High In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to EVP_PKEY_decrypt() can be smaller than the actual size required by the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. OpenSSL versions 1.1.1k and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1l. OpenSSL 1.0.2 is not impacted by this issue. OpenSSL 3.0 alpha/beta releases are also affected but this issue will be addressed before the final release. This issue was reported to OpenSSL on 12th August 2021 by John Ouyang. The fix was developed by Matt Caswell. Read buffer overruns processing ASN.1 strings (CVE-2021-3712) = Severity: Moderate ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). OpenSSL versions 1.1.1k and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1l. OpenSSL versions 1.0.2y and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2za. Other users should upgrade to 1.1.1l. An initial instance of this issue in the X509_aux_print() function was reported to OpenSSL on 18th July 2021 by Ingo Schwarze. The bugfix was developed by Ingo Schwarze and first publicly released in OpenBSD-current on 10th July 2021 and subsequently in OpenSSL on 20th July 2021 (commit d9d838ddc). Subsequent analysis by David Benjamin on 17th August 2021 identified more instances of
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [25 March 2021] = CA certificate check bypass with X509_V_FLAG_X509_STRICT (CVE-2021-3450) Severity: High The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 18th March 2021 by Benjamin Kaduk from Akamai and was discovered by Xiang Ding and others at Akamai. The fix was developed by Tomáš Mráz. NULL pointer deref in signature_algorithms processing (CVE-2021-3449) = Severity: High An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was developed by Peter Kästle and Samuel Sapalski from Nokia. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of these issues on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20210325.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBcl6sACgkQ2cTSbQ5g RJGvnAgAtG6I7rfokDC9E5yB26KC3k0Vasfq5iH/aZz0CNRyOokWJBUyyNIVjqr0 2eZP7VsQT7zRM+tgh9c8MwH3FIghtpwJRJls4qZDHKoXts7JH4Ul4NLPd546x7xA GcKNwTD4NkZbTqtZ72NTgliInzrj0MCC8jqQrIIkcAIleGNzvZ0f64jdE+vBXoqX M2FOhWiA/JkAKtB3W7pthIt25qkOwHbrpTy+UUp/S5QD779NJ/EOYcsOFBRfLZiP gA6QILuW2L55lhG6Y2u+nVE3UI2hqd2hGgSAvDIPr2lVJxq0LQpgHca7Gj5bfIRo GLDz7n0FhN6n7NBqetP+nlHmYivcSg== =XIXK -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [16 February 2021] Null pointer deref in X509_issuer_and_serial_hash() (CVE-2021-23841) Severity: Moderate The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 15th December 2020 by Tavis Ormandy from Google. The fix was developed by Matt Caswell. Incorrect SSLv2 rollback protection (CVE-2021-23839) Severity: Low OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a server that is configured to support both SSLv2 and more recent SSL and TLS versions then a check is made for a version rollback attack when unpadding an RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are supposed to use a special form of padding. A server that supports greater than SSLv2 is supposed to reject connection attempts from a client where this special form of padding is present, because this indicates that a version rollback has occurred (i.e. both client and server support greater than SSLv2, and yet this is the version that is being requested). The implementation of this padding check inverted the logic so that the connection attempt is accepted if the padding is present, and rejected if it is absent. This means that such as server will accept a connection if a version rollback attack has occurred. Further the server will erroneously reject a connection if a normal SSLv2 connection attempt is made. Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this issue. In order to be vulnerable a 1.0.2 server must: 1) have configured SSLv2 support at compile time (this is off by default), 2) have configured SSLv2 support at runtime (this is off by default), 3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite list) OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to this issue. The underlying error is in the implementation of the RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING padding mode used by various other functions. Although 1.1.1 does not support SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the RSA_SSLV23_PADDING padding mode. Applications that directly call that function or use that padding mode will encounter this issue. However since there is no support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a security issue in that version. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 21st January 2021 by D. Katz and Joel Luellwitz from Trustwave. The fix was developed by Matt Caswell. Integer overflow in CipherUpdate (CVE-2021-23840) = Severity: Low Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. This issue was reported to OpenSSL on 13th December 2020 by Paul Kehrer. The fix was developed by Matt Caswell. Note
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [08 December 2020] EDIPARTYNAME NULL pointer de-reference (CVE-2020-1971) == Severity: High The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. OpenSSL 1.1.1 users should upgrade to 1.1.1i. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2x. Other users should upgrade to OpenSSL 1.1.1i. This issue was reported to OpenSSL on 9th November 2020 by David Benjamin (Google). Initial analysis was performed by David Benjamin with additional analysis by Matt Caswell (OpenSSL). The fix was developed by Matt Caswell. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20201208.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl/PloEACgkQ2cTSbQ5g RJERNQf/d8G0r7APrOuxlwOL2j0j4JX5HZoR/ilD1eD6kSj3uZmCbl/DTZgN9uhj hMN9UTCVdF+NcWlqldwUVLLSq16/P821QLrbqKs4Q6i2NDwHIAU6VCneRZOUIOpl VOyQ+BJDavvqQ2gNziDK29sjG8JxWUqQ10fdphfrV1vS0Wd1fV1/Kk9I0ba+yv5O RiIyvbJobCEyNz52JdqbBsKjrSCtPh6qMra3IYm6EDJDnp+T8UpliB3RBIBuIPfU ALRageyqmE9+J5BFYxbd1Lx37mHXq1PZsSYd6L09Y9Wg5fJLHzWffd74SfJHwRza xZ/UTvCvkbGUbspT/U4mkuHwHzYXcg== =41vP -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [09 September 2020] = Raccoon Attack (CVE-2020-1968) == Severity: Low The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and does not implement any "static" DH ciphersuites. OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used. These static "DH" ciphersuites are ones that start with the text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these ciphersuites all start with "TLS_DH_" but excludes those that start with "TLS_DH_anon_". OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701. Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare. Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure that affected ciphersuites are disabled through runtime configuration. Also note that the affected ciphersuites are only available on the server side if a DH certificate has been configured. These certificates are very rarely used and for this reason this issue has been classified as LOW severity. This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to allow co-ordinated disclosure with other implementations. Note OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. The impact of this issue on OpenSSL 1.1.0 has not been analysed. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20200909.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- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280 dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3 fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU= =U7OO -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [21 April 2020] = Segmentation fault in SSL_check_chain (CVE-2020-1967) = Severity: High Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Affected OpenSSL 1.1.1 users should upgrade to 1.1.1g This issue was found by Bernd Edlinger and reported to OpenSSL on 7th April 2020. It was found using the new static analysis pass being implemented in GCC, - -fanalyzer. Additional analysis was performed by Matt Caswell and Benjamin Kaduk. Note = This issue did not affect OpenSSL 1.0.2 however these versions are out of support and no longer receiving public updates. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html This issue did not affect OpenSSL 1.1.0 however these versions are out of support and no longer receiving updates. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20200421.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6e8uwACgkQ2cTSbQ5g RJHHRgf+J8iVBuK6EoOvf9xm9geiDgYVFse9ckMXH92gdGbwsW4uhTNk9fCyNC+t vsf6YGT6nKJarB5+N+LC4QB7VLo/DjlYcN9zP3mubV0eEyKHSoW6tDOWPpJ0gsbt 2Z9iTA4GnofvhBcWLiPGgv4IUHknsOaPkRmEppSF0fDTSKuYOerfNRh9jTKHulis Ph6dCOXE3kb5HfMwVj3UN2sP92XTig4FzpIQaZ1/2jKZaRXtzJD7pvu1fDCTkUGl aeta5jHNypYyRKJLuJ1+1DiBtbWTFAWMUCHlkg/kgdU4hIl/lo3vgAyFs/9mQxZQ vj2rIjoJHRj0EXqXhHoABqBHedilJQ== =AXyP -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [6 December 2019] === rsaz_512_sqr overflow bug on x86_64 (CVE-2019-1551) === Severity: Low There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. OpenSSL versions 1.1.1 and 1.0.2 are affected by this issue. However due to the low severity of this issue we are not creating new releases at this time. The 1.1.1 mitigation for this issue can be found in commit 419102400. The 1.0.2 mitigation for this issue can be found in commit f1c5eea8a. This issue was found by OSS-Fuzz and Guido Vranken and reported to OpenSSL on 12th September 2019. The fix was developed by Andy Polyakov with additional analysis by Bernd Edlinger. Note = OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Extended support is available for premium support customers: https://www.openssl.org/support/contracts.html OpenSSL 1.1.0 is out of support and no longer receiving updates. It is unknown whether issues in this advisory affect it. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20191206.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl3qhRUACgkQ2cTSbQ5g RJHQvwgAhVefbdppxDZbGhiIjc/MLTeZmYC5U57rGMvGQ7WL8+xbkGVYmFPu69kp dN+kGPVJAZySmbhJZVmbrdxgl/zCvwE1WXPh5ILQCvA8cF0z762TCJpxbDJksy/9 igmavYVMxWLePMz7+HsVo6VCcvmBNGykg8zpJm33v2/wc9dBE+c/sJoep/pcXYNI fLrcLUnsnJoWhg23VNUXEkW8Ru4jkaXTtg4v4sdxHzPbp0qBbekdhj6GAekyFRjn Zpv4buJDxohcJw91rBK36tXU/PZARW4tO6TR6CdVuB16T7XMye0wKp3kRNd0QPE9 O/LGrT1Jq8cFTxYHfFYeOrkVJKpgog== =6Z6t -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [10 September 2019] = ECDSA remote timing attack (CVE-2019-1547) == Severity: Low Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. OpenSSL 1.1.1 users should upgrade to 1.1.1d OpenSSL 1.1.0 users should upgrade to 1.1.0l OpenSSL 1.0.2 users should upgrade to 1.0.2t This issue was reported by Cesar Pereida García, Sohaib ul Hassan, Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley. The fix was developed by Billy Brumley. It was reported to OpenSSL on 5th August 2019. Fork Protection (CVE-2019-1549) === Severity: Low OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. OpenSSL version 1.1.1 is affected by this issue. OpenSSL 1.1.1 users should upgrade to 1.1.1d This issue was reported by Matt Caswell. The fix was developed by Matthias St. Pierre. It was reported to OpenSSL on 27th May 2019. Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563) Severity: Low In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. OpenSSL 1.1.1 users should upgrade to 1.1.1d OpenSSL 1.1.0 users should upgrade to 1.1.0l OpenSSL 1.0.2 users should upgrade to 1.0.2t This issue was reported by and the fix developed by Bernd Edlinger. It was reported to OpenSSL on 21st August 2019. Note = OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the last 1.1.0 release. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20190910.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- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13vK0ACgkQ2cTSbQ5g RJGJIgf+Me900bLV9TrVDWvNRQbuRe0tOPPhP59J4tJAJiRZ1GG0JV2YITQynjTP hrz9mvajgWbkGYlTZmPVFOdJr7LKbrUrxk7shEfXqmiiCLG8tHYiCe3PF+/Cy7gA X1vY9CDfv//3VSqOLM9RM3CCcWAAv3KeP851X0PgCiMVvGAJbYOu3bmB+KsEKFzm fWRDabUMbl1KCSgCIvvlNv0bKR/GfpW3cWruUvG0sfjyPWwS+yn8z0T3/ibFJqkb Cmuqa3/kC9uZg8AhiODR+nz6D1mC2UiNZ2Wa/XO6O68rO/y3ZKbaiMGLze1qJep5 3PnybOw8b3JvpVRFYw09YwgLObBX8w== =8bP1 -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [26 February 2019] 0-byte record padding oracle (CVE-2019-1559) Severity: Moderate If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). This issue does not impact OpenSSL 1.1.1 or 1.1.0. OpenSSL 1.0.2 users should upgrade to 1.0.2r. This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod Aviram, with additional investigation by Steven Collison and Andrew Hourselt. It was reported to OpenSSL on 10th December 2018. Note OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates. Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0 will end on 11th September 2019. Users of these versions should upgrade to OpenSSL 1.1.1. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20190226.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- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx1U+gACgkQ2cTSbQ5g RJFnlAf/U9yZtCz59BjgD0Kh7Eya5KxlmUWItdBu1r3DwbY4KDgL/Wwh4UxG3Qim D7Ht5Xsta4iAywrMRI/iPEdEQct8pcpWjq4/65lEbTYjToEnNWhIeWHH/Lw3Jfza gcVpIfbWoWc7OL7U4uPQuGWcb/PO8fJXF+HcCdZ+kIuut0peMSgN5sK/wBnmSdsM +sJXCei+jwVy/9WvCBMOooX7D8oerJ6NX12n2cNAYH/K7e2deiPZ7D/HB7T9MSv/ BgOi1UqFzBxcsNhFpY5NMTHG8pl0bmS0OiZ9bThN0YHwxFVJz6ZsVX/L5cYOAbm/ mJAdDE24XMmUAOlVZrROzCZKXADx/A== =8h8L -END PGP SIGNATURE-
[openssl-announce] OpenSSL Security Advisory
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-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce
[openssl-announce] OpenSSL Security Advisory
-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-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce
[openssl-announce] OpenSSL Security Advisory
-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-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce
[openssl-announce] OpenSSL Security Advisory
-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-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce
[openssl-announce] OpenSSL Security Advisory
-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-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce
[openssl-announce] OpenSSL Security Advisory
-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-announce] OpenSSL Security Advisory
-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
[openssl-announce] OpenSSL Security Advisory
-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
OpenSSL security advisory
-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 Announcement Mailing List openssl-announce@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Security Advisory
-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 Announcement Mailing List openssl-announce@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Security Advisory: OCSP stapling vulnerability
-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
Announcement Mailing List openssl-announce@openssl.org
Automated List Manager majord...@openssl.org
OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption
OpenSSL Security Advisory [19 February 2003] Timing-based attacks on SSL/TLS with CBC encryption === CONTENTS - Vulnerability - Source code patch [*] - Acknowledgement - References [*] OpenSSL 0.9.6i and OpenSSL 0.9.7a do not require this patch. The source code of OpenSSL 0.9.6i and OpenSSL 0.9.7a is available as files openssl-0.9.6i.tar.gz and openssl-0.9.7a.tar.gz from ftp://ftp.openssl.org/source;type=d (If you were previously using an OpenSSL 0.9.6* engine release and cannot upgrade to OpenSSL 0.9.7a, obtain file openssl-engine-0.9.6i.tar.gz instead. With OpenSSL 0.9.7, the engine framework has become part of the standard distribution.) If you are using a pre-compiled OpenSSL package, please look for update information from the respective software distributor. The OpenSSL group itself does not distribute OpenSSL binaries. Vulnerability - In an upcoming paper, Brice Canvel (EPFL), Alain Hiltgen (UBS), Serge Vaudenay (EPFL), and Martin Vuagnoux (EPFL, Ilion) describe and demonstrate a timing-based attack on CBC ciphersuites in SSL and TLS. The attack assumes that multiple SSL or TLS connections involve a common fixed plaintext block, such as a password. An active attacker can substitute specifically made-up ciphertext blocks for blocks sent by legitimate SSL/TLS parties and measure the time until a response arrives: SSL/TLS includes data authentication to ensure that such modified ciphertext blocks will be rejected by the peer (and the connection aborted), but the attacker may be able to use timing observations to distinguish between two different error cases, namely block cipher padding errors and MAC verification errors. This is sufficient for an adaptive attack that finally can obtain the complete plaintext block. OpenSSL version since 0.9.6c supposedly treat block cipher padding errors like MAC verification errors during record decryption (see http://www.openssl.org/~bodo/tls-cbc.txt), but MAC verification was still skipped after detection of a padding error, which allowed the timing attack. (Note that it is likely that other SSL/TLS implementations will have similar problems.) OpenSSL 0.9.6i and 0.9.7a perform a MAC computation even if incorrrect block cipher padding has been found to minimize information leaked via timing. For earlier versions starting with 0.9.6e, the enclosed security patch can be used. Source code patch - If upgrading to OpenSSL 0.9.7a (the recommended version) or to OpenSSL 0.9.6i is not immediately possible, the following patch should be applied to the OpenSSL source code tree. The patch is compatible with OpenSSL 0.9.6e and later. --- ../openssl-0.9.6h/CHANGES Thu Dec 5 22:40:48 2002 +++ ./CHANGES Tue Feb 19 00:00:00 2003 @@ -1,3 +1,19 @@ + Change from security patch [19 Feb 2003] + + (Please consider installing OpenSSL 0.9.7a or OpenSSL 0.9.6i. + These versions already include this change; do not try to apply + the patch to them!) + + *) In ssl3_get_record (ssl/s3_pkt.c), minimize information leaked + via timing by performing a MAC computation even if incorrrect + block cipher padding has been found. This is a countermeasure + against active attacks where the attacker has to distinguish + between bad padding and a MAC verification error. (CAN-2003-0078) + + [Bodo Moeller; problem pointed out by Brice Canvel (EPFL), + Alain Hiltgen (UBS), Serge Vaudenay (EPFL), and + Martin Vuagnoux (EPFL, Ilion)] + OpenSSL CHANGES ___ --- ../openssl-0.9.6h/ssl/s3_pkt.c Mon May 6 12:42:56 2002 +++ ./ssl/s3_pkt.c Wed Feb 18 00:00:00 2003 @@ -238,6 +238,8 @@ unsigned int mac_size; int clear=0; size_t extra; + int decryption_failed_or_bad_record_mac = 0; + unsigned char *mac = NULL; rr= (s-s3-rrec); sess=s-session; @@ -353,8 +355,11 @@ /* SSLerr() and ssl3_send_alert() have been called */ goto err; - /* otherwise enc_err == -1 */ - goto decryption_failed_or_bad_record_mac; + /* Otherwise enc_err == -1, which indicates bad padding +* (rec-length has not been changed in this case). +* To minimize information leaked via timing, we will perform +* the MAC computation anyway. */ + decryption_failed_or_bad_record_mac = 1; } #ifdef TLS_DEBUG @@ -380,28 +385,46 @@ SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_PRE_MAC_LENGTH_TOO_LONG); goto f_err; #else - goto decryption_failed_or_bad_record_mac; + decryption_failed_or_bad_record_mac = 1; #endif } /* check the MAC for rr-input (it's in mac_size bytes at the tail) */ - if (rr-length mac_size
