OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [27th June 2024] == SSL_select_next_proto buffer overread (CVE-2024-5535) = Severity: Low Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer. Impact summary: A buffer overread can have a range of potential consequences such as unexpected application beahviour or a crash. In particular this issue could result in up to 255 bytes of arbitrary private data from memory being sent to the peer leading to a loss of confidentiality. However, only applications that directly call the SSL_select_next_proto function with a 0 length list of supported client protocols are affected by this issue. This would normally never be a valid scenario and is typically not under attacker control but may occur by accident in the case of a configuration or programming error in the calling application. The OpenSSL API function SSL_select_next_proto is typically used by TLS applications that support ALPN (Application Layer Protocol Negotiation) or NPN (Next Protocol Negotiation). NPN is older, was never standardised and is deprecated in favour of ALPN. We believe that ALPN is significantly more widely deployed than NPN. The SSL_select_next_proto function accepts a list of protocols from the server and a list of protocols from the client and returns the first protocol that appears in the server list that also appears in the client list. In the case of no overlap between the two lists it returns the first item in the client list. In either case it will signal whether an overlap between the two lists was found. In the case where SSL_select_next_proto is called with a zero length client list it fails to notice this condition and returns the memory immediately following the client list pointer (and reports that there was no overlap in the lists). This function is typically called from a server side application callback for ALPN or a client side application callback for NPN. In the case of ALPN the list of protocols supplied by the client is guaranteed by libssl to never be zero in length. The list of server protocols comes from the application and should never normally be expected to be of zero length. In this case if the SSL_select_next_proto function has been called as expected (with the list supplied by the client passed in the client/client_len parameters), then the application will not be vulnerable to this issue. If the application has accidentally been configured with a zero length server list, and has accidentally passed that zero length server list in the client/client_len parameters, and has additionally failed to correctly handle a "no overlap" response (which would normally result in a handshake failure in ALPN) then it will be vulnerable to this problem. In the case of NPN, the protocol permits the client to opportunistically select a protocol when there is no overlap. OpenSSL returns the first client protocol in the no overlap case in support of this. The list of client protocols comes from the application and should never normally be expected to be of zero length. However if the SSL_select_next_proto function is accidentally called with a client_len of 0 then an invalid memory pointer will be returned instead. If the application uses this output as the opportunistic protocol then the loss of confidentiality will occur. This issue has been assessed as Low severity because applications are most likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not widely used. It also requires an application configuration or programming error. Finally, this issue would not typically be under attacker control making active exploitation unlikely. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 3.3, 3.2, 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue. OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2 once it is released. OpenSSL 3.2 users should upgrade to OpenSSL 3.2.3 once it is released. OpenSSL 3.1 users should upgrade to OpenSSL 3.1.7 once it is released. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.15 once it is released. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1za once it is released (premium support customers only). OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zk 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 e86ac436f0 (for 3.3), commit 99fb785a5f (for 3.2), commit 4ada436a19 (for 3.1) and commit cf6f91f612 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit b78ec0824d (for 1.1.1)
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [28th May 2024] = Use After Free with SSL_free_buffers (CVE-2024-4741) Severity: Low Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause memory to be accessed that was previously freed in some situations Impact summary: A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code. However, only applications that directly call the SSL_free_buffers function are affected by this issue. Applications that do not call this function are not vulnerable. Our investigations indicate that this function is rarely used by applications. The SSL_free_buffers function is used to free the internal OpenSSL buffer used when processing an incoming record from the network. The call is only expected to succeed if the buffer is not currently in use. However, two scenarios have been identified where the buffer is freed even when still in use. The first scenario occurs where a record header has been received from the network and processed by OpenSSL, but the full record body has not yet arrived. In this case calling SSL_free_buffers will succeed even though a record has only been partially processed and the buffer is still in use. The second scenario occurs where a full record containing application data has been received and processed by OpenSSL but the application has only read part of this data. Again a call to SSL_free_buffers will succeed even though the buffer is still in use. While these scenarios could occur accidentally during normal operation a malicious attacker could attempt to engineer a stituation where this occurs. We are not aware of this issue being actively exploited. The FIPS modules in 3.3, 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.3, 3.2, 3.1, 3.0 and 1.1.1 are vulnerable to this issue. OpenSSL 3.3 users should upgrade to OpenSSL 3.3.1 once it is released. 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 e5093133c3 (for 3.3), commit c88c3de510 (for 3.2), commit 704f725b96 (for 3.1) and commit b3f0eb0a29 (for 3.0) in the OpenSSL git repository. It is available to premium support customers in commit f7a045f314 (for 1.1.1). This issue was reported on 10th April 2024 by William Ahern (Akamai). The fix was developed by Matt Caswell and Watson Ladd (Akamai). General Advisory Notes == URL for this Security Advisory: https://www.openssl.org/news/secadv/20240528.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- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmZV9w0ACgkQ2cTSbQ5g RJFleggAunT15ijQEKk29rztc82qEl01c/mDCAKCNLD0WqCr/D00lIjYhOjAcj7W f4h9c7N8TqX4fkc1pBmV3KMM4qCzMkNdFE+lxYiDn2A/HAsZgSmh+WGpcMju7obI 5TvaINrBZbndXTa3o+10Wo4QT7oVGji/WLwsc06QzofZRLWj7BxU1h7i2JDR9Gd/ SYkg5ivgwixAgMzxpy7nQetQYKAfl6spKSUDHDymkYk0ATTvr9P14pQ5+Sr2T/gT V8V5uTOYcxjpJCRipUbUPDN5ZUy379thry3XmR9wd2GE0AeXoVOJQMpOVK7TDhzm TFookLZ04kCDtSU6gM0XXI8WAoEDUQ== =UFjh -END PGP SIGNATURE-
OpenSSL Security Advisory [corrected CVE id]
-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 [16th May 2024] = Excessive time spent checking DSA keys and parameters (CVE-2023-3446) = 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/UnRmohynnm0FAmZGJOMACgkQUnRmohyn nm3/cg/+JJtAXf0cyAEoDbPX3mTygHN1U3dqpCVFPMwYi23Bqce33wqXrXZqBxsF m9IM3KRFHsdoArt1q1WWPGpMGLVColq56JwkjGzpaKjooLrb0cEbt6vKp5oepUCW cv1ieLF5Z5dvYrWfgiO1mu5r88SY6OLCmxJdPIWMgTrgd1+h7AtzGF+olTgLHovp qEQUNhCYax6RLaFtqcPY6eHuxlH6ARuERPJaPxasv6bPi8VQfYQ349G7ks4adgw9 b0I0qt/wZuGa0p/rpZ99Ev1VAFo9iOxcB8Vftm4nQzBfjCsieKcX+cM7aTnLPUjR RFr/KmAGY9RcRFOI6UT2xemLP5xb4A3/wgeLjdPbWDeZ5eBe2nvOE07ndHZYxQIC AxTMVFlWgcVpu2bDEHuhiNvYMW+AZYAfsN2jEOBl13SjN4ty9uLt/KMtM0Dp7p0J KiDTTaGgX3jlEUt6gy/X314rEeCn5rNrupOfeQNPKnzdlInjP0yKvxF/boXDfQa3 KM7Sp+eZb674n2c83CuUPVfdIF2jmzm6VdB8a4zIAYoiPyw0HljayzPhAuUBhgOO Q9nrooNs3+aZm/UXEcs0V0X+LPz7+w22z3aQ220sRYuQuZYNkvEfRi+yRzkqqoPd 0Bs7VAdzs6WryLWabkRmfTFagQ9UT9LtXsR+7h6P0By3ps8MaaU= =DJFm -END PGP SIGNATURE-
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-
Re: OpenSSL Security Advisory
Many thanks! On Wed, Sep 9, 2020 at 4:16 PM Mark J Cox wrote: > I just spotted it via twitter, https://raccoon-attack.com/ > > Mark > > On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky wrote: > > > > Could you please let me know when it is available? > > > > On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox wrote: > >> > >> They should be releasing their paper very soon (today). > >> > >> Regards, Mark > >> > >> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky > wrote: > >> > > >> > Is the description of the attack publicly available? > >> > > >> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: > >> >> > >> >> -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 report
Re: OpenSSL Security Advisory
I just spotted it via twitter, https://raccoon-attack.com/ Mark On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky wrote: > > Could you please let me know when it is available? > > On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox wrote: >> >> They should be releasing their paper very soon (today). >> >> Regards, Mark >> >> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky wrote: >> > >> > Is the description of the attack publicly available? >> > >> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: >> >> >> >> -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 >> >>
Re: OpenSSL Security Advisory
Could you please let me know when it is available? On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox wrote: > They should be releasing their paper very soon (today). > > Regards, Mark > > On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky wrote: > > > > Is the description of the attack publicly available? > > > > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: > >> > >> -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: > &
Re: OpenSSL Security Advisory
They should be releasing their paper very soon (today). Regards, Mark On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky wrote: > > Is the description of the attack publicly available? > > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: >> >> -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- > > > > -- > SY, Dmitry Belyavsky
Re: OpenSSL Security Advisory
Is the description of the attack publicly available? On Wed, Sep 9, 2020 at 3:39 PM OpenSSL wrote: > -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- > -- SY, Dmitry Belyavsky
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 [30 July 2019] Windows builds with insecure path defaults (CVE-2019-1552) == Severity: Low OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. The mitigations are found in these commits: - - For 1.1.1, commit 54aa9d51b09d67e90db443f682cface795f5af9e - - For 1.1.0, commit e32bc855a81a2d48d215c506bdeb4f598045f7e9 and b15a19c148384e73338aa7c5b12652138e35ed28 - - For 1.0.2, commit d333ebaf9c77332754a9d5e111e2f53e1de54fdd The 1.1.1 and 1.1.0 mitigation set more appropriate defaults for mingw, while the 1.0.2 mitigation documents the issue and provides enhanced examples. This issue was reported by Rich Mirth. The fix was developed by Richard Levitte from the OpenSSL development team. It was reported to OpenSSL on 9th Jun 2019. 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. Referenses == URL for this Security Advisory: https://www.openssl.org/news/secadv/20190730.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+1enkP3357owFAl1AU3sACgkQ1enkP335 7oxnEw//ebb9FK16oXpvW6nifNgSHUBYRaq+3ApvSfGG8Er1M0Zn80iD/WY8wzM7 ZabUUNlOdnOs0iQivMYzy+8QzP9NRaqX2WZk/Q1koNT5WAt9+VDCw6hhbp6FN8B9 9aeRvdawNME9JPysl3KOR6DnYJQnpJgV0yQ2pJM2yMKNuDFkvy6E9ieMoWAGx5Ya 8JZ4KGFubA1vDPj5xowkRDxZo+SLdAaEMQw0YG8DWSK5BViZV+3d4OMAAL1RjnZy s4OSghqi7wUbgo8XO38/roN4y4BEgmEXU0IpSRNf1xrwCoFM82hEgOO3xWxPtbZk EtDcMUTtMYa1g5IMdGIkVvS4wnNr2j2BAi8WECkPf5QCzCoaX/Xc9jutslTw20M/ UoZnyGgVoOQCsO6ECwLUnSEp772mhS1056c4OKb62kfhlIcGkWi5vk5wjWVZFxEx rXJC7xabp29e051mnrJtLr85UWUv5B/ywREPyvbdjWg6lJBxB0dOYXMQLpJi6B5i /bDX7czP/1EeOg+FDSGOR174JGIyMYmPqpyzGpdds72GfOQqtGHC2z41FlvHMglB 9VobSZnF97MIan4/9H4ge+gUUq0PeIZ+invvgCHzuW4oYBOngwwVD5QXfSQUjA9a etYHkJx+3t4hPrPKAT/J0jHA7AbWtYK7dL6qTxSwli2Gl/D4ipk= =gxli -END PGP SIGNATURE-
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [6 March 2019] ChaCha20-Poly1305 with long nonces (CVE-2019-1543) == Severity: Low ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. The 1.1.1 mitigation for this issue can be found in commit f426625b6a. The 1.1.0 mitigation for this issue can be found in commit ee22257b14. This issue does not impact OpenSSL 1.0.2. This issue was discovered by Joran Dirk Greef of Ronomon. The fix was developed by Matt Caswell from the OpenSSL development team. It was reported to OpenSSL on 26th February 2019. 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/20190306.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- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlx/5b4ACgkQ2cTSbQ5g RJEXSwgAgHQkb/CyWdubYozRAeUDBT9o6gt/kgsBwPYBxAV75lRo4qwBxzfkeQ6P 6EUFSzEPhabQOhpnTY4QaqphzG2FAl4BbtDalYN+zPOZxppmH7O8Kje+j+onInDI O4jbjXLgAlgmf5jw5IyhfxQKcaFbdLtcFGzh1t4rMEhT+ehx8ePnGnklPTjfh4ea bN+BlM1Fm6Au3i/IJB2I6e8ayxFnTx9mAegPvV/RRYma43Ee/Hpvb6eBaTfTZ9yp lOp0jG4iViB4r3EP3H/l5oVC9fWCAI0Am+vcLq9PsWl632fc39hDREhPrRMfnOds 40ayI4NwoUu4Z89Qdae1iWEUkgjRgA== =Aub4 -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-project] 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-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] 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-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project