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
Re: OpenSSL Security Advisory
On Thursday, 25 March 2021 15:03:24 CET, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [25 March 2021] = 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. I've created a stand-alone reproducer for it using tlsfuzzer: git clone https://github.com/tlsfuzzer/tlsfuzzer.git cd tlsfuzzer # won't be necessary after https://github.com/tlsfuzzer/tlsfuzzer/pull/748 is merged: git checkout sig-algs-tests # install dependencies: python3 -m venv py3-venv py3-venv/bin/pip install --pre tlslite-ng # run the reproducer: PYTHONPATH=. py3-venv/bin/python3 scripts/test-sig-algs-renegotiation-resumption.py -h -p In case the server has renegotiation disabled, use the --no-renego option. In case the server doesn't require presence of signature_algorithms extension when signature_algorithms_cert are present (like in case of OpenSSL 1.0.2), use the --sig-algs-drop-ok option. If everything went fine, and the server didn't crash, the test will print summary like this: TOTAL: 12 SKIP: 0 PASS: 12 XFAIL: 0 FAIL: 0 XPASS: 0 It's not necessary to install dependencies to a virtual environment, but that setup is described in the official docs: https://tlsfuzzer.readthedocs.io/en/latest/quickstart.html -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
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
On 10/09/2020 16:14, Jakob Bohm via openssl-users wrote: > On 2020-09-10 09:03, Tomas Mraz wrote: >> On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: >>> Wouldn't a more reasonable response for 1.0.2 users have been to >>> force on >>> SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected >>> cipher >>> suites >>> and telling affected people to recompile with the fix off? >> >> You seem to be mixing two different affected things. One is the static >> DH ciphersuites. There is no remediation for these except for not using >> them. Fortunately they are not really used by anyone. This can be >> achieved on the server side by simply not providing the DH certificate. >> On the client side they can be dropped from the ciphers string. This is >> the "deprecating affected cipher suites" change part. >> >> On the other hand the reuse of DH key for ephemeral DH can be only >> disabled by setting SSL_OP_SINGLE_DH_USE by the calling server >> application. This is the part relevant for wider audience. >> >> So yes, both issues can be remediated by application calling the >> OpenSSL library. On the other hand it is not always possible to change >> the application so we also provide fix to premium support customers in >> terms of changing the openssl code. >> > > > The advisory didn't include this clarification, Isn't the text below from the advisory more-or-less what Tomas said? "OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used ... 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." > and didn't state if > 1.0.2w fixes the DHE case by doing what 1.1.x does and act like > SSL_OP_SINGLE_DH_USE is always set. The advisory says that SSL_OP_SINGLE_DH_USE was made the default in 1.0.2f: "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." Matt
Re: OpenSSL Security Advisory
On 2020-09-10 09:03, Tomas Mraz wrote: On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? You seem to be mixing two different affected things. One is the static DH ciphersuites. There is no remediation for these except for not using them. Fortunately they are not really used by anyone. This can be achieved on the server side by simply not providing the DH certificate. On the client side they can be dropped from the ciphers string. This is the "deprecating affected cipher suites" change part. On the other hand the reuse of DH key for ephemeral DH can be only disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. So yes, both issues can be remediated by application calling the OpenSSL library. On the other hand it is not always possible to change the application so we also provide fix to premium support customers in terms of changing the openssl code. The advisory didn't include this clarification, and didn't state if 1.0.2w fixes the DHE case by doing what 1.1.x does and act like SSL_OP_SINGLE_DH_USE is always set. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: OpenSSL Security Advisory
On Wed, 2020-09-09 at 22:26 +0200, Jakob Bohm via openssl-users wrote: > Wouldn't a more reasonable response for 1.0.2 users have been to > force on > SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected > cipher > suites > and telling affected people to recompile with the fix off? You seem to be mixing two different affected things. One is the static DH ciphersuites. There is no remediation for these except for not using them. Fortunately they are not really used by anyone. This can be achieved on the server side by simply not providing the DH certificate. On the client side they can be dropped from the ciphers string. This is the "deprecating affected cipher suites" change part. On the other hand the reuse of DH key for ephemeral DH can be only disabled by setting SSL_OP_SINGLE_DH_USE by the calling server application. This is the part relevant for wider audience. So yes, both issues can be remediated by application calling the OpenSSL library. On the other hand it is not always possible to change the application so we also provide fix to premium support customers in terms of changing the openssl code. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: OpenSSL Security Advisory
On 2020-09-09 14:39, OpenSSL wrote: 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 Wouldn't a more reasonable response for 1.0.2 users have been to force on SSL_OP_SINGLE_DH_USE rather than recklessly deprecating affected cipher suites and telling affected people to recompile with the fix off? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
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-
Re: OpenSSL Security Advisory
That makes sense, thank you all.
Re: OpenSSL Security Advisory
On 21/04/2020 20:46, Sam Roberts wrote:
> The announcement claims that this affects SSL_check_chain().
>
> Is that an exhaustive list? If an application does NOT call that
> function, does this mean the vulnerability is not exploitable?
As Ben says - this is correct.
>
> I ask because the the fixed function tls1_check_sig_alg is called by
> tls1_check_chain, and that is called directly by SSL_check_chain, but
> it is also called by tls1_set_cert_validity, and that is called from
You will note that tls1_check_sig_alg is only affected if we go down the
TLSv1.3 codepath. However tls1_set_cert_validity() only has one caller
and it looks like this:
if (SSL_IS_TLS13(s)) {
...
} else {
tls1_set_cert_validity(s);
ssl_set_masks(s);
}
So it is only ever called in a non-TLSv1.3 handshake.
Matt
> inside the tls state machine, but with different parameters, so its a
> bit hard to see if it is affected or not.
>
> Thanks,
> Sam
>
> On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote:
>>
> 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
>
Re: OpenSSL Security Advisory
On Tue, Apr 21, 2020 at 12:46:43PM -0700, Sam Roberts wrote: > The announcement claims that this affects SSL_check_chain(). > > Is that an exhaustive list? If an application does NOT call that > function, does this mean the vulnerability is not exploitable? That is correct (speaking only in terms of public APIs). > I ask because the the fixed function tls1_check_sig_alg is called by > tls1_check_chain, and that is called directly by SSL_check_chain, but > it is also called by tls1_set_cert_validity, and that is called from > inside the tls state machine, but with different parameters, so its a > bit hard to see if it is affected or not. As you note, the valid call chains are a bit convoluted, but the relevant codepath is only exercised for TLS 1.3 and SSL_check_chain(). -Ben
Re: OpenSSL Security Advisory
The announcement claims that this affects SSL_check_chain(). Is that an exhaustive list? If an application does NOT call that function, does this mean the vulnerability is not exploitable? I ask because the the fixed function tls1_check_sig_alg is called by tls1_check_chain, and that is called directly by SSL_check_chain, but it is also called by tls1_set_cert_validity, and that is called from inside the tls state machine, but with different parameters, so its a bit hard to see if it is affected or not. Thanks, Sam On Tue, Apr 21, 2020 at 6:26 AM OpenSSL wrote: > > -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 [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-
Re: OpenSSL Security Advisory
Having reviewed the git commit for 1.1.1 I notice the following issue: The environment variables that usually point to the secure administrator directories (such as "Program Files") are not themselves secured, and not intended as a secure means of obtaining these directory locations, which are (by definition) subject to change via system configuration (initial or later!). There are official system library calls to obtain the actual locations as follows: 1. If looking for the location where a program is itself installed, use the GetModuleFilenameW(own-hinstance) call to obtain the path to once own DLL or EXE. This automatically adapts to wherever the DLL or EXE is copied or moved. This is a kernel32.dll API and returns a location with security very close to that of the binary itself.The name returned is from the in-process instance of the dynamic linker. 2. If looking for the location where the running program's top level file (such as openssl.exe or some-program-loading-an-openssl-using-plugin.exe), use that same call but pass NULL for the hinstance parameter. 3. If looking for the system-wide secured "/etc" directory, use the GetSystemDirectoryW() call and append the fixed string "\\Drivers\\etc" . This location is permanently restricted to the system administrators and already contains a few traditional unix files such as "hosts". This too is a kernel32.dll API. The name returned is from a system internal value set during OS boot. 4. If looking for the directory intended to hold system-wide configuration and data files, use the SHGetFolderPathW(CSIDL_COMMON_APPDATA) API from shfolder.dll or shell32.dll (fallback) to ask for the "all-users data directory", append a company/project name (such as "\\OpenSSL") and specify an appropriate ACL in the security argument to CreateDirectoryW() (if the directory doesn't already exist with a user-modified ACL, CreateDirectoryW will atomically detect this and return a specific error code in the per thread GetLastError() variable).Note that mkdir() only creates one level of directories per invocation and you may want different ACLs when creating missing parent directories. The values returned by SHGetFolderPathW() are typically from one or more Administrator controlled registry keys. Some of the above APIs may require their return value to be canonicalized via the GetFullPathNameW() API in corner cases, retaining the result in a global variable is advisable. On 30/07/2019 16:27, OpenSSL wrote: OpenSSL Security Advisory [30 July 2019] Windows builds with insecure path defaults (CVE-2019-1552) == Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
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-
RE: OpenSSL Security Advisory
Thanks. -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: Wednesday, February 27, 2019 11:18 AM To: openssl-users@openssl.org Subject: Re: OpenSSL Security Advisory On 27/02/2019 18:43, Scott Neugroschl wrote: > Is this a client-side or server-side vulnerability? Or does it matter? It can apply to either side. Matt > > Thanks, > > ScottN > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 > 583-2874|Fax 805 583-0124 | > > > > > -Original Message- > From: openssl-users On Behalf Of OpenSSL > Sent: Tuesday, February 26, 2019 6:59 AM > To: openssl-proj...@openssl.org; OpenSSL User Support ML > ; OpenSSL Announce ML > > Subject: OpenSSL Security Advisory > > 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 >
Re: OpenSSL Security Advisory
On 27/02/2019 18:43, Scott Neugroschl wrote: > Is this a client-side or server-side vulnerability? Or does it matter? It can apply to either side. Matt > > Thanks, > > ScottN > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 > 583-2874|Fax 805 583-0124 | > > > > > -Original Message- > From: openssl-users On Behalf Of OpenSSL > Sent: Tuesday, February 26, 2019 6:59 AM > To: openssl-proj...@openssl.org; OpenSSL User Support ML > ; OpenSSL Announce ML > > Subject: OpenSSL Security Advisory > > 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 >
RE: OpenSSL Security Advisory
Is this a client-side or server-side vulnerability? Or does it matter? Thanks, ScottN --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -Original Message- From: openssl-users On Behalf Of OpenSSL Sent: Tuesday, February 26, 2019 6:59 AM To: openssl-proj...@openssl.org; OpenSSL User Support ML ; OpenSSL Announce ML Subject: 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 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-users] 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-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL Security Advisory [12 June 2018] Client DoS due to large DH parameter (CVE-2018-0732) Severity: Low During key agreement in a TLS handshake using a DH(E) based ciphersuite a malicious server can send a very large prime value to the client. This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i and OpenSSL 1.0.2p when they become available. The fix is also available in commit ea7abeeab (for 1.1.0) and commit 3984ef0b7 (for 1.0.2) in the OpenSSL git repository. This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken who also developed the fix. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20180612.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsfnTgACgkQ2cTSbQ5g RJE9Twf/VSgXaFPlW+JyA2BAiwGREMr/oMQe8mhmka3WQgNb7oMQRxk4ZqwRvLi2 ggPVOQilJ+tkXgeifEQ3SDRxDnnmcUvxbWB8Lt+7tjhM6O+GYGbGbzupnkBs2IIY 72vll4l7ySMQ8/fcdU/uuNyObfigLC9XndH3tEewxffs6uvDxMyGhZmNQpq1aZNj rGj3dETUuO/Ln8siAD7nkv9xodRINViMP76fSKAtdaikvZa3uhLBMhX5tOzpR/ta tc2+6uthdU9JjSRZZpfDlzzhsOFqMrLfOLrJQIIXshxUNeOZyJCkmT9ED8XZRDMB twb1kOxCKz8Ky+Xm/Rki9uRVoZFjBg== =kKic -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] 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-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [27 Mar 2018] Constructed ASN.1 types with a recursive definition could exceed the stack (CVE-2018-0739) == Severity: Moderate Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe. OpenSSL 1.1.0 users should upgrade to 1.1.0h OpenSSL 1.0.2 users should upgrade to 1.0.2o This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz project. The fix was developed by Matt Caswell of the OpenSSL development team. Incorrect CRYPTO_memcmp on HP-UX PA-RISC (CVE-2018-0733) Severity: Moderate Because of an implementation bug the PA-RISC CRYPTO_memcmp function is effectively reduced to only comparing the least significant bit of each byte. This allows an attacker to forge messages that would be considered as authenticated in an amount of tries lower than that guaranteed by the security claims of the scheme. The module can only be compiled by the HP-UX assembler, so that only HP-UX PA-RISC targets are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0h This issue was reported to OpenSSL on 2nd March 2018 by Peter Waltenberg (IBM). The fix was developed by Andy Polyakov of the OpenSSL development team. rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738) = Severity: Low This issue has been reported in a previous OpenSSL security advisory and a fix was provided for OpenSSL 1.0.2. Due to the low severity no fix was released at that time for OpenSSL 1.1.0. The fix is now available in OpenSSL 1.1.0h. There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL 1.1.0 users should upgrade to 1.1.0h OpenSSL 1.0.2 users should upgrade to 1.0.2n This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin (Google). The issue was originally found via the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20180327.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJaulEjAAoJENnE0m0OYESRc2oH/2E5ya4GF745SK7VB7ZjCWu6 tN5q3CNr1gUiZKcsvK4nl/OdP5h+KToHYQR1RBy0tusk1cFHYRuztsZhtb/mm0DD Z3adXvnz8VFeCyNC/aptwOO0OoPbUHgqhf1L5deNaXMZJDqEjz/6WlVfFQezSeVf h0Sy72SmX2h+Jt1Zh+VYjfX/xMTnX6CWrbyC78KKZ88s4dSYbMsYdJuJSqpar/C1 zQpgCD6Stk0L9J4DB4DYr3MAInMJXRIMyFOZlrOm4oTbZqSdcFxIglCMVPlXpES2 Ke1Gse5bab+O0sr+Ue4Vk0zsi3wv7zaUk8d7YchMpUlqJWKeY3N3i40jnacx1fU= =ATWc -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Dec 2017] Read/write after SSL object in error state (CVE-2017-3737) == Severity: Moderate OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. This issue does not affect OpenSSL 1.1.0. OpenSSL 1.0.2 users should upgrade to 1.0.2n This issue was reported to OpenSSL on 10th November 2017 by David Benjamin (Google). The fix was proposed by David Benjamin and implemented by Matt Caswell of the OpenSSL development team. rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738) = Severity: Low There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. Due to the low severity of this issue we are not issuing a new release of OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it becomes available. The fix is also available in commit e502cc86d in the OpenSSL git repository. OpenSSL 1.0.2 users should upgrade to 1.0.2n This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin (Google). The issue was originally found via the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Note Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20171207.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJaKUFJAAoJENnE0m0OYESRp1UH/1Z8hBb1dM82Lnn3b0pQ1LjF xBqs0cBFax6z8gelZzUI3CEJe78n3YB6jJiyCDOvrsrb9dx4kGvt97R9x9Np6glh /cL98I1mVwLdLciE1WeBPBFDijp5Bii4pz3q4StFGmh9g9cQ70onz8OO0RB9GSS5 dpbRcbOZLcyt3Lnqmnx86SLAdGgF635SO0EE10txDXjgEUK3Zo+gT+/jelwoNLXT mtYfqgXp6+Eqa08Qq3Nmrgqz4azhFLD5szixmnXQwbP+OpiT+zpNXsV5qqemWFn9 aV2qzDJJtrpObaPXSqKCBUA7C1qYmj9OmeaDUVJ29vS1mm09hs18if954ib6nbw= =MmWs -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [02 Nov 2017] bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736) == Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen. Note: This issue is very similar to CVE-2017-3732 and CVE-2015-3193 but must be treated as a separate problem. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m This issue was reported to OpenSSL on 10th August 2017 by the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735) Severity: Low This issue was previously announced in security advisory https://www.openssl.org/news/secadv/20170828.txt, but the fix has not previously been included in a release due to its low severity. OpenSSL 1.1.0 users should upgrade to 1.1.0g OpenSSL 1.0.2 users should upgrade to 1.0.2m Note Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20171102.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJZ+y3yAAoJENnE0m0OYESRWooH/2cS+HkzBCCdnJ/CWuhKomTe hshdBbYw/eYeZgrUYZX6CYosvhLX1Hkwef3vVMxHDXsnBnnZfGfwCS2EfXJ96xXK KiXVchBwlpmovrOuAvrGtPqLkiVOZZpGMfopP30WCKc6tkdqjw/NvruMbg7Iz+Sy ki5AM7Vw7kAEa18KAGjSN4jSrCHMIKkOeGkmay5hHlYLwQRQDAAo5EmWmVOJpUXF ddvQ6h+NKqlWAMF+2/U3PhUFa4V7xqlKR3GMdRawVSaoKQUsPXvRGAhLnvqfOonx y0yl7y9a7EJrcRl8HWf7qqZf0B/m3YapCHNNcBYWry+qk7LJgGjIHDF8VFkEABg= =k+bJ -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [16 Feb 2017] Encrypt-Then-Mac renegotiation crash (CVE-2017-3733) Severity: High During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0e This issue does not affect OpenSSL version 1.0.2. This issue was reported to OpenSSL on 31st January 2017 by Joe Orton (Red Hat). The fix was developed by Matt Caswell of the OpenSSL development team. Note Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20170216.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJYpZMiAAoJENnE0m0OYESRMUgH/0UN9sxxgyDewSCMeTOYPauK cSPqyw1pndQI6Lu+d3OCdWd01rdLcm+HxlbW5FOUjGZ4G9YefE0+JcvKkIuLGIpQ 1EE0g/ZuBzWDh7/MkFWcmjHceYVXi5sKewtWcQvO9uePzlPhlSZoNIL1G66n1HAo of3ZlSL5BmibaTiz1WmpDG//0W1pgYP5OdvQ8/AVrJJf8pUnU9Oyubm1yCyK2RHi jfJWLbMx0ENgW4G1sW4s8bPaj4GwLjIrZl8ocqoyAHhghkBv/UXUhv6i62bKHmxW vfYwwiU0GlRVwPXzFKbbE3qqCRyDsq+XLAe/09NZZWA+BtscWuUhUpyEODBqzeY= =zqNG -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [26 Jan 2017] Truncated packet could crash via OOB read (CVE-2017-3731) = Severity: Moderate If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash. For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305; users should upgrade to 1.1.0d For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k This issue was reported to OpenSSL on 13th November 2016 by Robert Święcki of Google. The fix was developed by Andy Polyakov of the OpenSSL development team. Bad (EC)DHE parameters cause a client crash (CVE-2017-3730) === Severity: Moderate If a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this can result in the client attempting to dereference a NULL pointer leading to a client crash. This could be exploited in a Denial of Service attack. OpenSSL 1.1.0 users should upgrade to 1.1.0d This issue does not affect OpenSSL version 1.0.2. Note that this issue was fixed prior to it being recognised as a security concern. This means the git commit with the fix does not contain the CVE identifier. The relevant fix commit can be identified by commit hash efbe126e3. This issue was reported to OpenSSL on 14th January 2017 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. BN_mod_exp may produce incorrect results on x86_64 (CVE-2017-3732) == Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very similar to CVE-2015-3193 but must be treated as a separate problem. OpenSSL 1.1.0 users should upgrade to 1.1.0d OpenSSL 1.0.2 users should upgrade to 1.0.2k This issue was reported to OpenSSL on 15th January 2017 by the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. Montgomery multiplication may produce incorrect results (CVE-2016-7055) === Severity: Low This issue was previously fixed in 1.1.0c and covered in security advisory https://www.openssl.org/news/secadv/20161110.txt OpenSSL 1.0.2k users should upgrade to 1.0.2k Note Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20170126.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJYifonAAoJENnE0m0OYESRnhYH/1ldFYDEZ894DleZfjRrZulX OQkEH7w6v+D6YFp8i2v6rJaDq8caOPEhzupQCxPcqYitBUnww9UzUvYJ77aBV0CG DQ3UvE9XeEn5D7MGAGq/ut5Z5WpvlYL7n7PaciX751vpTsWTBKfGecQ8YV0aT6y+ 7V7vHz6NVFnuTQDMUYs9C9aTsCDTNy3Bl84d7gYyoDWXUXds5k008g9LFRI4YQ8l +4z+GXRVcvAFr6fKH94Yq1RMAp6cJi0RDkyuwcGhSOUwVfSLTN8+i2v4xqzKgsx1 q2qPo3+7uederE5ZaNZScl0xAzEilotxLQyy9XSVx/DDXHz0in1500qxgxNFELU= =12E/ -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [10 Nov 2016] ChaCha20/Poly1305 heap-buffer-overflow (CVE-2016-7054) == Severity: High TLS connections using *-CHACHA20-POLY1305 ciphersuites are susceptible to a DoS attack by corrupting larger payloads. This can result in an OpenSSL crash. This issue is not considered to be exploitable beyond a DoS. OpenSSL 1.1.0 users should upgrade to 1.1.0c This issue does not affect OpenSSL versions prior to 1.1.0 This issue was reported to OpenSSL on 25th September 2016 by Robert Święcki (Google Security Team), and was found using honggfuzz. The fix was developed by Richard Levitte of the OpenSSL development team. CMS Null dereference (CVE-2016-7053) Severity: Moderate Applications parsing invalid CMS structures can crash with a NULL pointer dereference. This is caused by a bug in the handling of the ASN.1 CHOICE type in OpenSSL 1.1.0 which can result in a NULL value being passed to the structure callback if an attempt is made to free certain invalid encodings. Only CHOICE structures using a callback which do not handle NULL value are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0c This issue does not affect OpenSSL versions prior to 1.1.0 This issue was reported to OpenSSL on 12th October 2016 by Tyler Nighswander of ForAllSecure. The fix was developed by Stephen Henson of the OpenSSL development team. Montgomery multiplication may produce incorrect results (CVE-2016-7055) === Severity: Low There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure that handles input lengths divisible by, but longer than 256 bits. Analysis suggests that attacks against RSA, DSA and DH private keys are impossible. This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input. Among EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation. Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behaviour. Even then only clients that chose the curve will be affected. OpenSSL 1.1.0 users should upgrade to 1.1.0c This issue does not affect OpenSSL versions prior to 1.0.2. Due to the low severity of this defect we are not issuing a new 1.0.2 release at this time. We recommend that 1.0.2 users wait for the next 1.0.2 release for the fix to become available. The fix is also available in the OpenSSL git repository in commit 57c4b9f6a2. This issue was publicly reported as transient failures and was not initially recognized as a security issue. Thanks to Richard Morgan for providing reproducible case. The fix was developed by Andy Polyakov of the OpenSSL development team. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20161110.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJYJH8JAAoJENnE0m0OYESRaZwH/1S6sjqemFtHXVk77xMMbUmY kKGJoo5/7wJQWdw9LMPoxjXDyW0fWTKI+Ly2qfP8ZwVizONndN1HCDdWPSbT9EvN 1OG6gr0BQBmlcENCBrSuGwojAtQuMd47q3IAR3ZSx5yvYby4Lg9tXk1FjvnQ600O Z19r1lvc6efeO1fXPBqIUUPJ4y2XN7P1DDlE5UWxacN5Xn+a6cqrieuj0g1aoZ0h rw4fEI7o3EEufYTtodos61xLqZWq8quaMuerWEq0HfEOyMGGyDkmnQkXdU0X7o4g U17vgzM7CvN7+weBz8hVHd0RARAl21vBjYV/G1kruBxD+cYjdavzGGAf/Z1o15w= =MmoX -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [26 Sep 2016] This security update addresses issues that were caused by patches included in our previous security update, released on 22nd September 2016. Given the Critical severity of one of these flaws we have chosen to release this advisory immediately to prevent upgrades to the affected version, rather than delaying in order to provide our usual public pre-notification. Fix Use After Free for large message sizes (CVE-2016-6309) == Severity: Critical This issue only affects OpenSSL 1.1.0a, released on 22nd September 2016. The patch applied to address CVE-2016-6307 resulted in an issue where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved. Unfortunately a dangling pointer to the old location is left which results in an attempt to write to the previously freed location. This is likely to result in a crash, however it could potentially lead to execution of arbitrary code. OpenSSL 1.1.0 users should upgrade to 1.1.0b This issue was reported to OpenSSL on 23rd September 2016 by Robert ÅwiÄcki (Google Security Team), and was found using honggfuzz. The fix was developed by Matt Caswell of the OpenSSL development team. Missing CRL sanity check (CVE-2016-7052) Severity: Moderate This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016. A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0 but was omitted from OpenSSL 1.0.2i. As a result any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception. OpenSSL 1.0.2i users should upgrade to 1.0.2j The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and Thomas Jakobi. The fix was developed by Matt Caswell of the OpenSSL development team. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20160926.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJX6PBJAAoJENnE0m0OYESRGacIALa7/Vg0SQzqjhD/KphCdKos BjkDcEO00y3JDyYqqQxfcrM9jSwBbrNzmHdEzBcPlvvDq9qhGwsODKbGylI2St5r zVHw1qA60/+Hu9PjaGT24a8MX+fPjA4RObB/BGZ7ViucZzCxqqtJob73InKwM8+9 OyjTmrphbyFa/Hk/OUWVzjatzQjEN+a5QplRTR2Sd4fBZDWowrtOdPGmbBQfRRgm AbEO5ZPaVKBoRuMk6JsR3LFymZ2FpHjLs9HNBtSmLLdzfIXxVE+uOb9b5wdAMP/3 4cTMkhfeS3RF0GuMT3EyH/EuZS6KkjuE8y/aVTq5s3yhK3ah5kT85IO1ps0yDx0= =WJwY -END PGP SIGNATURE- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [22 Sep 2016] OCSP Status Request extension unbounded memory growth (CVE-2016-6304) = Severity: High A malicious client can send an excessively large OCSP Status Request extension. If that client continually requests renegotiation, sending a large OCSP Status Request extension each time, then there will be unbounded memory growth on the server. This will eventually lead to a Denial Of Service attack through memory exhaustion. Servers with a default configuration are vulnerable even if they do not support OCSP. Builds using the "no-ocsp" build time option are not affected. Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default configuration, instead only if an application explicitly enables OCSP stapling support. OpenSSL 1.1.0 users should upgrade to 1.1.0a OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 29th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. SSL_peek() hang on empty record (CVE-2016-6305) === Severity: Moderate OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an empty record. This could be exploited by a malicious peer in a Denial Of Service attack. OpenSSL 1.1.0 users should upgrade to 1.1.0a This issue was reported to OpenSSL on 10th September 2016 by Alex Gaynor. The fix was developed by Matt Caswell of the OpenSSL development team. SWEET32 Mitigation (CVE-2016-2183) == Severity: Low SWEET32 (https://sweet32.info) is an attack on older block cipher algorithms that use a block size of 64 bits. In mitigation for the SWEET32 attack DES based ciphersuites have been moved from the HIGH cipherstring group to MEDIUM in OpenSSL 1.0.1 and OpenSSL 1.0.2. OpenSSL 1.1.0 since release has had these ciphersuites disabled by default. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 16th August 2016 by Karthikeyan Bhargavan and Gaetan Leurent (INRIA). The fix was developed by Rich Salz of the OpenSSL development team. OOB write in MDC2_Update() (CVE-2016-6303) == Severity: Low An overflow can occur in MDC2_Update() either if called directly or through the EVP_DigestUpdate() function using MDC2. If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate() with a partial block then a length check can overflow resulting in a heap corruption. The amount of data needed is comparable to SIZE_MAX which is impractical on most platforms. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 11th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Malformed SHA512 ticket DoS (CVE-2016-6302) === Severity: Low If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a DoS attack where a malformed ticket will result in an OOB read which will ultimately crash. The use of SHA512 in TLS session tickets is comparatively rare as it requires a custom server callback and ticket lookup mechanism. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 19th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. OOB write in BN_bn2dec() (CVE-2016-2182) Severity: Low The function BN_bn2dec() does not check the return value of BN_div_word(). This can cause an OOB write if an application uses this function with an overly large BIGNUM. This could be a problem if an overly large certificate or CRL is printed out from an untrusted source. TLS is not affected because record limits will reject an oversized certificate before it is parsed. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 2nd August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. OOB read in TS_OBJ_print_bio() (CVE-2016-2180) == Severity: Low The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is the total length the OID text representation would use and not the amount of data written. This will result in OOB reads when large OIDs are presented. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 us
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [3rd May 2016] Memory corruption in the ASN.1 encoder (CVE-2016-2108) == Severity: High This issue affected versions of OpenSSL prior to April 2015. The bug causing the vulnerability was fixed on April 18th 2015, and released as part of the June 11th 2015 security releases. The security impact of the bug was not known at the time. In previous versions of OpenSSL, ASN.1 encoding the value zero represented as a negative integer can cause a buffer underflow with an out-of-bounds write in i2c_ASN1_INTEGER. The ASN.1 parser does not normally create "negative zeroes" when parsing ASN.1 input, and therefore, an attacker cannot trigger this bug. However, a second, independent bug revealed that the ASN.1 parser (specifically, d2i_ASN1_TYPE) can misinterpret a large universal tag as a negative zero value. Large universal tags are not present in any common ASN.1 structures (such as X509) but are accepted as part of ANY structures. Therefore, if an application deserializes untrusted ASN.1 structures containing an ANY field, and later reserializes them, an attacker may be able to trigger an out-of-bounds write. This has been shown to cause memory corruption that is potentially exploitable with some malloc implementations. Applications that parse and re-encode X509 certificates are known to be vulnerable. Applications that verify RSA signatures on X509 certificates may also be vulnerable; however, only certificates with valid signatures trigger ASN.1 re-encoding and hence the bug. Specifically, since OpenSSL's default TLS X509 chain verification code verifies the certificate chain from root to leaf, TLS handshakes could only be targeted with valid certificates issued by trusted Certification Authorities. OpenSSL 1.0.2 users should upgrade to 1.0.2c OpenSSL 1.0.1 users should upgrade to 1.0.1o This vulnerability is a combination of two bugs, neither of which individually has security impact. The first bug (mishandling of negative zero integers) was reported to OpenSSL by Huzaifa Sidhpurwala (Red Hat) and independently by Hanno Böck in April 2015. The second issue (mishandling of large universal tags) was found using libFuzzer, and reported on the public issue tracker on March 1st 2016. The fact that these two issues combined present a security vulnerability was reported by David Benjamin (Google) on March 31st 2016. The fixes were developed by Steve Henson of the OpenSSL development team, and David Benjamin. The OpenSSL team would also like to thank Mark Brand and Ian Beer from the Google Project Zero team for their careful analysis of the impact. The fix for the "negative zero" memory corruption bug can be identified by commits 3661bb4e7934668bd99ca777ea8b30eedfafa871 (1.0.2) and 32d3b0f52f77ce86d53f38685336668d47c5bdfe (1.0.1) Padding oracle in AES-NI CBC MAC check (CVE-2016-2107) == Severity: High A MITM attacker can use a padding oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server support AES-NI. This issue was introduced as part of the fix for Lucky 13 padding attack (CVE-2013-0169). The padding check was rewritten to be in constant time by making sure that always the same bytes are read and compared against either the MAC or padding bytes. But it no longer checked that there was enough data to have both the MAC and padding bytes. OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 13th of April 2016 by Juraj Somorovsky using TLS-Attacker. The fix was developed by Kurt Roeckx of the OpenSSL development team. EVP_EncodeUpdate overflow (CVE-2016-2105) = Severity: Low An overflow can occur in the EVP_EncodeUpdate() function which is used for Base64 encoding of binary data. If an attacker is able to supply very large amounts of input data then a length check can overflow resulting in a heap corruption. Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by the PEM_write_bio* family of functions. These are mainly used within the OpenSSL command line applications. These internal uses are not considered vulnerable because all calls are bounded with length checks so no overflow is possible. User applications that call these APIs directly with large amounts of untrusted data may be vulnerable. (Note: Initial analysis suggested that the PEM_write_bio* were vulnerable, and this is reflected in the patch commit message. This is no longer believed to be the case). OpenSSL 1.0.2 users should upgrade to 1.0.2h OpenSSL 1.0.1 users should upgrade to 1.0.1t This issue was reported to OpenSSL on 3rd March 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. EVP_En
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [1st March 2016] = NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by default, as well as removing SSLv2 EXPORT ciphers. We strongly advise against the use of SSLv2 due not only to the issues described below, but to the other known deficiencies in the protocol as described at https://tools.ietf.org/html/rfc6176 Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800) Severity: High A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and EXPORT cipher suites as a Bleichenbacher RSA padding oracle. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server. This vulnerability is known as DROWN (CVE-2016-0800). Recovering one session key requires the attacker to perform approximately 2^50 computation, as well as thousands of connections to the affected server. A more efficient variant of the DROWN attack exists against unpatched OpenSSL servers using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on 19/Mar/2015 (see CVE-2016-0703 below). Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they've not done so already. Disabling all SSLv2 ciphers is also sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers. OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN: SSLv2 is now by default disabled at build-time. Builds that are not configured with "enable-ssl2" will not support SSLv2. Even if "enable-ssl2" is used, users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will need to explicitly call either of: SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2); or SSL_clear_options(ssl, SSL_OP_NO_SSLv2); as appropriate. Even if either of those is used, or the application explicitly uses the version-specific SSLv2_method() or its client or server variants, SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed. Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no longer available. In addition, weak ciphers in SSLv3 and up are now disabled in default builds of OpenSSL. Builds that are not configured with "enable-weak-ssl-ciphers" will not provide any "EXPORT" or "LOW" strength ciphers. OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s This issue was reported to OpenSSL on December 29th 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Viktor Dukhovni and Matt Caswell of OpenSSL. Double-free in DSA code (CVE-2016-0705) === Severity: Low A double free bug was discovered when OpenSSL parses malformed DSA private keys and could lead to a DoS attack or memory corruption for applications that receive DSA private keys from untrusted sources. This scenario is considered rare. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s This issue was reported to OpenSSL on February 7th 2016 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen Henson of OpenSSL. Memory leak in SRP database lookups (CVE-2016-0798) === Severity: Low The SRP user database lookup method SRP_VBASE_get_by_user had confusing memory management semantics; the returned pointer was sometimes newly allocated, and sometimes owned by the callee. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around 300 bytes per connection. Servers that do not configure SRP, or configure SRP but do not configure a seed are not vulnerable. In Apache, the seed directive is known as SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [28th Jan 2016] = NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME SECURITY FIXES ONLY ARE BEING APPLIED. DH small subgroups (CVE-2016-0701) == Severity: High Historically OpenSSL usually only ever generated DH parameters based on "safe" primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server's private DH exponent if it's reusing the private DH exponent or it's using a static DH ciphersuite. OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk. OpenSSL before 1.0.2f will reuse the key if: - - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not set. - - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is an undocumted feature and parameter files don't contain the key. - - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. It will not reuse the key for DHE ciphers suites if: - - SSL_OP_SINGLE_DH_USE is set - - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the callback does not provide the key, only the parameters. The callback is almost always used like this. Non-safe primes are generated by OpenSSL when using: - - genpkey with the dh_rfc5114 option. This will write an X9.42 style file including the prime-order subgroup size "q". This is supported since the 1.0.2 version. Older versions can't read files generated in this way. - - dhparam with the -dsaparam option. This has always been documented as requiring the single use. The fix for this issue adds an additional check where a "q" parameter is available (as is the case in X9.42 based parameters). This detects the only known attack, and is the only possible defense for static DH ciphersuites. This could have some performance impact. Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default and cannot be disabled. This could have some performance impact. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 is not affected by this CVE because it does not support X9.42 based parameters. It is possible to generate parameters using non "safe" primes, but this option has always been documented as requiring single use and is not the default or believed to be common. However, as a precaution, the SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r. This issue was reported to OpenSSL on 12 January 2016 by Antonio Sanso (Adobe). The fix was developed by Matt Caswell of the OpenSSL development team (incorporating some work originally written by Stephen Henson of the OpenSSL core team). SSLv2 doesn't block disabled ciphers (CVE-2015-3197) Severity: Low A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 users should upgrade to 1.0.1r This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Nimrod Aviram with further development by Viktor Dukhovni of the OpenSSL development team. An update on DHE man-in-the-middle protection (Logjam) A previously published vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by rejecting handshakes
[openssl-users] Updated OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [3 Dec 2015] - Updated [4 Dec 2015] = [Updated 4 Dec 2015]: This advisory has been updated to include the details of CVE-2015-1794, a Low severity issue affecting OpenSSL 1.0.2 which had a fix included in the released packages but was missed from the advisory text. NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) == Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno Böck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) === Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) == Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) = Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Anon DH ServerKeyExchange with 0 p parameter (CVE-2015-1794) Severity: Low If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with the value of p set to 0 then a seg fault can occur leading to a possible denial of service attack. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [3 Dec 2015] === NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) == Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno Böck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) === Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) == Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) = Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20151203.txt Note: the online version of the advisory may be updated with additional details over time
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 10/07/2015 23:03, Jeffrey Walton wrote: During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2 or 1.0.3 . I *think* improved chain building should have present in the library earlier. The methods always exited. See, for example, 4158, https://www.ietf.org/rfc/rfc4158.txt. Here's a real world failure due to previous, naive path building: https://groups.google.com/d/msg/mailing.openssl.users/72_VQJmCmCU/hUMtemRNvRoJ. The CA re-issued a root by changing the hash and serial number, but recertifying the same public key and DN. Then, the server sent the old root too as an intermediate. So there were two roots available, each with the same DN. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. It almost sound like you are complaining you did not have to wait ages :) It's the inconsistency of first insisting this cannot go into a patch and then pushing out a broken implementation inside a patch which was only supposed to fix security and build issues. This is the kind of event which has caused many dists to cherry pickindividual changes rather than just following the official releases. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. It almost sound like you are complaining you did not have to wait ages :) It's the inconsistency of first insisting this cannot go into a patch and then pushing out a broken implementation inside a patch which was only supposed to fix security and build issues. OK.. so that's a legitimate gripe. OpenSSL has opportunities for improvements in their testing and release process. There is ***absolutely no reason a patch should not be tested before being released. Its been a chronic problem with the project. For what its worth, I've given up on the Testing Group (https://groups.google.com/forum/#!forum/openssl-testing). No meaningful change came from it. The devs are still undisciplined in this area, and they still do what they want. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
How deep does the certificate chain have to be? It does not matter. If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? I think you are confused. The bug is not about CA's. It's about a non-CA fooling the runtime into treating it as if it were a CA and being able to issue a certificate. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 10/07/15 13:09, R C Delgado wrote: Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. Under normal circumstances things work as follows: We are provided with a certificate to verify from a remote peer. Lets call the certificate we are trying to verify Leaf. As well as Leaf that has been provided from the remote peer, they also supply us with a set of untrusted certs. Finally we also have a store of trusted certs. OpenSSL will first attempt to build a certificate chain. The chain building works as follows (much simplified): 1. Set Leaf as the top of the chain 2. Look for the issuer of the cert at the top of the chain from within the untrusted set. If we find it add it to the top of the chain 3. Repeat (2) until we can't find any more certs from the untrusted set 4. Look for the issuer of the top of the chain from the set of trusted certs 5. Repeat (4) until we can't find any more certs from the trusted set If we've found a valid chain with a trusted self signed cert at the top, then we stop there. If not, then we continue to look to see if there is an alternative chain that can be built. This works as follows: Pop all the trusted certs off the top of the chain, then start popping the untrusted certs off. Each time we pop an untrusted cert off start the chain building again from step 4. The bug occurs when during the initial chain building: 1) We have added at least one cert from the untrusted set 2) We have added at least one cert from the trusted store For 1.0.2 there is the additional condition: 3) After doing (1) and (2) above we do not have a valid chain Finally (for both 1.0.1 and 1.0.2) 4) After popping off at least one untrusted cert from the chain we can build an alternative valid chain Under the above conditions the end entity cert Leaf could issue a new certificate even though it is not supposed to (I'll call that invalid certificate Bad). So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? Many thanks for your help. RCD ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Thank you very much. It really helps. On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell m...@openssl.org wrote: On 10/07/15 13:09, R C Delgado wrote: Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. Under normal circumstances things work as follows: We are provided with a certificate to verify from a remote peer. Lets call the certificate we are trying to verify Leaf. As well as Leaf that has been provided from the remote peer, they also supply us with a set of untrusted certs. Finally we also have a store of trusted certs. OpenSSL will first attempt to build a certificate chain. The chain building works as follows (much simplified): 1. Set Leaf as the top of the chain 2. Look for the issuer of the cert at the top of the chain from within the untrusted set. If we find it add it to the top of the chain 3. Repeat (2) until we can't find any more certs from the untrusted set 4. Look for the issuer of the top of the chain from the set of trusted certs 5. Repeat (4) until we can't find any more certs from the trusted set If we've found a valid chain with a trusted self signed cert at the top, then we stop there. If not, then we continue to look to see if there is an alternative chain that can be built. This works as follows: Pop all the trusted certs off the top of the chain, then start popping the untrusted certs off. Each time we pop an untrusted cert off start the chain building again from step 4. The bug occurs when during the initial chain building: 1) We have added at least one cert from the untrusted set 2) We have added at least one cert from the trusted store For 1.0.2 there is the additional condition: 3) After doing (1) and (2) above we do not have a valid chain Finally (for both 1.0.1 and 1.0.2) 4) After popping off at least one untrusted cert from the chain we can build an alternative valid chain Under the above conditions the end entity cert Leaf could issue a new certificate even though it is not supposed to (I'll call that invalid certificate Bad). So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 07/10/2015 09:32 AM, Matt Caswell wrote: On 10/07/15 13:09, R C Delgado wrote: Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. snip So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Thanks, Matt. This is the most cogent explanation I've seen to date. Cheers -- Lewis - Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal Rosenthal, LLCwww.2rosenthals.com visit my IT blogwww.2rosenthals.net/wordpress IRS Circular 230 Disclosure applies see www.2rosenthals.com - ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
Hello, One further question. Can you please confirm that the alternative certificate chain feature is enabled by default? It seems to be implied in all emails regarding this matter, and I'm assuming the Advisory email would have mentioned it otherwise. I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS exists but is not set in the flags member by default when a new X509 context is initialised. And my code does not modify the context to include this flag. Please let me know if I'm missing something. (I'm using OpenSSL 1.0.1o) Many thanks, RCD ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793
On 10/07/15 19:34, R C Delgado wrote: Hello, One further question. Can you please confirm that the alternative certificate chain feature is enabled by default? It seems to be implied in all emails regarding this matter, and I'm assuming the Advisory email would have mentioned it otherwise. Yes, it is enabled by default. Matt I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS exists but is not set in the flags member by default when a new X509 context is initialised. And my code does not modify the context to include this flag. Please let me know if I'm missing something. (I'm using OpenSSL 1.0.1o) Many thanks, RCD ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2 or 1.0.3 . I *think* improved chain building should have present in the library earlier. The methods always exited. See, for example, 4158, https://www.ietf.org/rfc/rfc4158.txt. Here's a real world failure due to previous, naive path building: https://groups.google.com/d/msg/mailing.openssl.users/72_VQJmCmCU/hUMtemRNvRoJ. The CA re-issued a root by changing the hash and serial number, but recertifying the same public key and DN. Then, the server sent the old root too as an intermediate. So there were two roots available, each with the same DN. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. It almost sound like you are complaining you did not have to wait ages :) Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] OpenSSL Security Advisory
On Thu, Jul 09, 2015 at 01:13:30PM +, Salz, Rich wrote: This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. In other words, if you are not using those specific releases -- i.e., the ones that came out less than 30 days ago -- you do not need to upgrade. More accurately, you should upgrade anyway, to address the issues resolved by those earlier releases, even though the specific issue in the most recent release applies only to its immediate predecessors. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVnml8AAoJENnE0m0OYESRlcYH/iUe62/m2oZiuBHkKQvLBUbH VrLDp7xEXEg6ozByLyxughAFwY9XD2r9WkXehxw66af2pmNHphXH3Gbfpcebki0r HuZJ3CbGD/RSomWdAqkzRfV8MjNxmN4Pyi+sTsf7F+nKv80Ts51iUN1pPjkddAR8 ooKw0VMIENeMboWQ9SyQ3r7TYYywK+lXUG71Ekva9ByzABBwC/1CzZeSLJmuewnJ +9TjwQ4otH/mUJ/klvw+G2eTSn64AnA6UEFR+sBL4aNpIgdrtjonJRt2ko05Z92N HN/ibu5okd3iUbtkM0dTMGAr2NCrNYPr2dYLMPemwkAq1cRlhjGouRDDeb6TUYk= =oUAa -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] OpenSSL Security Advisory
This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. In other words, if you are not using those specific releases -- i.e., the ones that came out less than 30 days ago -- you do not need to upgrade. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 09/07/15 22:46, Jakob Bohm wrote: On 09/07/2015 15:10, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2or 1.0.3. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. Is it a new feature or a defect fix? On the one hand OpenSSL has never been able to handle alternative certificate chains. If the first chain attempted fails to verify then we stop. Its always been done that way and from that point of view the ability to handle alternative cert chains is a new feature. On the other hand, from a users perspective, if you present OpenSSL with a perfectly valid certificate, and a perfectly valid trust store, then you expect it to successfully verify the certificate no matter what. OpenSSL was failing to do that, and therefore this would suggest it is a defect. My initial view was the former. This issue was raised a number of times within RT and on the openssl-dev list and also via other routes. It was clearly causing real problems for end users (and increasingly so). There was much discussion on this topic, but ultimately the decision was taken to change our mind, and treat it as a defect. For that reason it was included in a patch release. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. Does this vulnerability also affect applications that use OpenSSL or the openssl command line to handle S/MIME or other CMS messages? Yes. Ultimately it affects all applications that verify certificates. That includes the openssl command line applications. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Security Advisory
On 09/07/2015 15:10, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] === Alternative chains certificate forgery (CVE-2015-1793) == Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and issue an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2or 1.0.3. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. Does this vulnerability also affect applications that use OpenSSL or the openssl command line to handle S/MIME or other CMS messages? For example, the mail client mutt handles S/MIME by invoking the openssl command line via macros in the default configuration file. P.S. Sorry for first trying to send to -announce, MUA must have ignored the Reply-To. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S.http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [11 Jun 2015] === DHE man-in-the-middle protection (Logjam) A vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL has added protection for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits. This limit will be increased to 1024 bits in a future release. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n Fixes for this issue were developed by Emilia Käsper and Kurt Roeckx of the OpenSSL development team. Malformed ECParameters causes infinite loop (CVE-2015-1788) === Severity: Moderate When processing an ECParameters structure OpenSSL enters an infinite loop if the curve specified is over a specially malformed binary polynomial field. This can be used to perform denial of service against any system which processes public keys, certificate requests or certificates. This includes TLS clients and TLS servers with client authentication enabled. This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent 1.0.0 and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are affected. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0d (and below) users should upgrade to 1.0.0s OpenSSL 0.9.8r (and below) users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 6th April 2015 by Joseph Birr-Pixton. The fix was developed by Andy Polyakov of the OpenSSL development team. Exploitable out-of-bounds read in X509_cmp_time (CVE-2015-1789) === Severity: Moderate X509_cmp_time does not properly check the length of the ASN1_TIME string and can read a few bytes out of bounds. In addition, X509_cmp_time accepts an arbitrary number of fractional seconds in the time string. An attacker can use this to craft malformed certificates and CRLs of various sizes and potentially cause a segmentation fault, resulting in a DoS on applications that verify certificates or CRLs. TLS clients that verify CRLs are affected. TLS clients and servers with client authentication enabled may be affected if they use custom verification callbacks. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 8th April 2015 by Robert Swiecki (Google), and independently on 11th April 2015 by Hanno Böck. The fix was developed by Emilia Käsper of the OpenSSL development team. PKCS7 crash with missing EnvelopedContent (CVE-2015-1790) = Severity: Moderate The PKCS#7 parsing code does not handle missing inner EncryptedContent correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing. Applications that decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 18th April 2015 by Michal Zalewski (Google). The fix was developed by Emilia Käsper of the OpenSSL development team. CMS verify infinite loop with unknown hash function (CVE-2015-1792) === Severity: Moderate When verifying a signedData message the CMS code can enter an infinite loop if presented with an unknown hash function OID. This can be used to perform denial of service against any system which verifies signedData messages using the CMS code. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 31st March 2015 by Johannes Bauer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling NewSessionTicket (CVE-2015-1791) Severity: Low If a NewSessionTicket is received by a multi-threaded client
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [19 Mar 2015] === OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291) = Severity: High If a client connects to an OpenSSL 1.0.2 server and renegotiates with an invalid signature algorithms extension a NULL pointer dereference will occur. This can be exploited in a DoS attack against the server. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a. This issue was was reported to OpenSSL on 26th February 2015 by David Ramos of Stanford University. The fix was developed by Stephen Henson and Matt Caswell of the OpenSSL development team. Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) Severity: High This security issue was previously announced by the OpenSSL project and classified as low severity. This severity rating has now been changed to high. This was classified low because it was originally thought that server RSA export ciphersuite support was rare: a client was only vulnerable to a MITM attack against a server which supports an RSA export ciphersuite. Recent studies have shown that RSA export ciphersuites support is far more common. This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. It was previously announced in the OpenSSL security advisory on 8th January 2015. Multiblock corrupted pointer (CVE-2015-0290) Severity: Moderate OpenSSL 1.0.2 introduced the multiblock performance improvement. This feature only applies on 64 bit x86 architecture platforms that support AES NI instructions. A defect in the implementation of multiblock can cause OpenSSL's internal write buffer to become incorrectly set to NULL when using non-blocking IO. Typically, when the user application is using a socket BIO for writing, this will only result in a failed connection. However if some other BIO is used then it is likely that a segmentation fault will be triggered, thus enabling a potential DoS attack. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a. This issue was reported to OpenSSL on 13th February 2015 by Daniel Danner and Rainer Mueller. The fix was developed by Matt Caswell of the OpenSSL development team. Segmentation fault in DTLSv1_listen (CVE-2015-0207) === Severity: Moderate The DTLSv1_listen function is intended to be stateless and processes the initial ClientHello from many peers. It is common for user code to loop over the call to DTLSv1_listen until a valid ClientHello is received with an associated cookie. A defect in the implementation of DTLSv1_listen means that state is preserved in the SSL object from one invocation to the next that can lead to a segmentation fault. Errors processing the initial ClientHello can trigger this scenario. An example of such an error could be that a DTLS1.0 only client is attempting to connect to a DTLS1.2 only server. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2a. This issue was reported to OpenSSL on 27th January 2015 by Per Allansson. The fix was developed by Matt Caswell of the OpenSSL development team. Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) === Severity: Moderate The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check certificate signature algorithm consistency this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was discovered and fixed by Stephen Henson of the OpenSSL development team. Segmentation fault for invalid PSS parameters (CVE-2015-0208) = Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and invalid parameters. Since these routines are used to verify
[openssl-users] OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [08 Jan 2015] === DTLS segmentation fault in dtls1_get_record (CVE-2014-3571) === Severity: Moderate A carefully crafted DTLS message can cause a segmentation fault in OpenSSL due to a NULL pointer dereference. This could lead to a Denial Of Service attack. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Markus Stenberg of Cisco Systems, Inc. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) === Severity: Moderate A memory leak can occur in the dtls1_buffer_record function under certain conditions. In particular this could occur if an attacker sent repeated DTLS records with the same sequence number but for the next epoch. The memory leak could be exploited by an attacker in a Denial of Service attack through memory exhaustion. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 7th January 2015 by Chris Mueller who also provided an initial patch. Further analysis was performed by Matt Caswell of the OpenSSL development team, who also developed the final patch. no-ssl3 configuration sets method to NULL (CVE-2014-3569) = Severity: Low When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is received the ssl method would be set to NULL which could later result in a NULL pointer dereference. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 17th October 2014 by Frank Schmirler. The fix was developed by Kurt Roeckx. ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572) == Severity: Low An OpenSSL client will accept a handshake using an ephemeral ECDH ciphersuite using an ECDSA certificate if the server key exchange message is omitted. This effectively removes forward secrecy from the ciphersuite. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) == Severity: Low An OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. DH client certificates accepted without verification [Server] (CVE-2015-0205) = Severity: Low An OpenSSL server will accept a DH certificate for client authentication without the certificate verify message. This effectively allows a client to authenticate without the use of a private key. This only affects servers which trust a client certificate authority which issues certificates containing DH keys: these are extremely rare and hardly ever encountered. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. Certificate fingerprints can be modified (CVE-2014-8275) Severity: Low OpenSSL accepts several non-DER-variations of certificate signature algorithm and signature encodings. OpenSSL also does not enforce a match between the signature algorithm between the signed and unsigned portions
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [15 Oct 2014] === SRTP Memory Leak (CVE-2014-3513) Severity: High A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected. OpenSSL 1.0.1 users should upgrade to 1.0.1j. This issue was reported to OpenSSL on 26th September 2014, based on an original issue and patch developed by the LibreSSL project. Further analysis of the issue was performed by the OpenSSL team. The fix was developed by the OpenSSL team. Session Ticket Memory Leak (CVE-2014-3567) == Severity: Medium When an OpenSSL SSL/TLS/DTLS server receives a session ticket the integrity of that ticket is first verified. In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak. By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack. OpenSSL 1.0.1 users should upgrade to 1.0.1j. OpenSSL 1.0.0 users should upgrade to 1.0.0o. OpenSSL 0.9.8 users should upgrade to 0.9.8zc. This issue was reported to OpenSSL on 8th October 2014. The fix was developed by Stephen Henson of the OpenSSL core team. SSL 3.0 Fallback protection === Severity: Medium OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications to block the ability for a MITM attacker to force a protocol downgrade. Some client applications (such as browsers) will reconnect using a downgraded protocol to work around interoperability bugs in older servers. This could be exploited by an active man-in-the-middle to downgrade connections to SSL 3.0 even if both sides of the connection support higher protocols. SSL 3.0 contains a number of weaknesses including POODLE (CVE-2014-3566). OpenSSL 1.0.1 users should upgrade to 1.0.1j. OpenSSL 1.0.0 users should upgrade to 1.0.0o. OpenSSL 0.9.8 users should upgrade to 0.9.8zc. https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 https://www.openssl.org/~bodo/ssl-poodle.pdf Support for TLS_FALLBACK_SCSV was developed by Adam Langley and Bodo Moeller. Build option no-ssl3 is incomplete (CVE-2014-3568) == Severity: Low When OpenSSL is configured with no-ssl3 as a build option, servers could accept and complete a SSL 3.0 handshake, and clients could be configured to send them. OpenSSL 1.0.1 users should upgrade to 1.0.1j. OpenSSL 1.0.0 users should upgrade to 1.0.0o. OpenSSL 0.9.8 users should upgrade to 0.9.8zc. This issue was reported to OpenSSL by Akamai Technologies on 14th October 2014. The fix was developed by Akamai and the OpenSSL team. References == URL for this Security Advisory: https://www.openssl.org/news/secadv_20141015.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUPnPYAAoJENnE0m0OYESRaBsH/Au+URgDVRsG/LJT89adeBnA jPEdxf2CV2M4aH5bs2FRES43iWQNQUtDHkmSfOfyICLHYN8no2/78QqMhPr1/euA bRGB7+P+Epac8LRjXGR9+CJx46Oc0LqDgXdU/7nGe2qB8qo0oR6S3M+ZUsuSB6IU XbQC0wTeDRXZKJ0dLXLj1ro7JaFd2F692XKilUVdg4cLUuK5IbxdXWzp2ttgoQGB EbBNHSbbSbbNODUyr/oyna+c+FImAbcTOee0PuGOukEmsDQh/wofbRDb9tn0JdZw /ZJDJtU1VVeIl+j+uU9fQ0aG/TTjPBMeT5uelA9P/t4SPh+7JDneHbuhY5GCfnI= =ic92 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL Security Advisory - CVE-2014-3508
Hi, Please can I enquire what the actual vulnerability is with... Information leak in pretty printing functions (CVE-2014-3508) = A flaw in OBJ_obj2txt may cause pretty printing functions such as X509_name_oneline, X509_name_print_ex et al. to leak some information from the stack. Applications may be affected if they echo pretty printing output to the attacker. OpenSSL SSL/TLS clients and servers themselves are not affected. OpenSSL 0.9.8 users should upgrade to 0.9.8zb OpenSSL 1.0.0 users should upgrade to 1.0.0n. OpenSSL 1.0.1 users should upgrade to 1.0.1i. Thanks to Ivan Fratric (Google) for discovering this issue. This issue was reported to OpenSSL on 19th June 2014. The fix was developed by Emilia Käsper and Stephen Henson of the OpenSSL development team. I have tried to look up CVE-2014-3508 and found it is not there yet. What is meant by echo pretty printing output to the attacker? Thank you for your assistance and look forward to your response. Thanks.. John [Unify: Harmonize your enterprise] John Simner BSc(Hons) MSc CEng. MIET Software Engineer, Devices Development Unify Enterprise Communications Ltd. Tel.: +44 (1908) 817378 (One Number Service) Email: john.sim...@unify.com mailto:vorname.n...@unify.com www.unify.co.ukhttp://www.unify.co.uk/ Follow us: [Social_media_icons] http://www.unify.com/social-media Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ Registered No: 5903714, England. This email contains confidential information and is for the exclusive use of the addressee. If you are not the addressee then any distribution, copying, or use of this email is prohibited. If received in error, please advise the sender and delete immediately. We accept no liability for any loss or damage suffered by any person arising from use of this email.
Re: OpenSSL Security Advisory
The redhat podcast with Mark (Cox) probably answers this best; http://bit.ly/Th64oP On Thu, Jun 5, 2014 at 12:04 PM, Juha Saarinen j...@saarinen.org wrote: Hi Steve, That’s quite a few in one go - is this due to greater testing of OpenSSL and more scrutiny of the code by the community? Of the flaws listed, which is the one of most concern? This kind of begs the question what to do with all those embedded systems that run older versions of OpenSSL. Thanks — Juha On 5/06/2014, at 11:54 pm, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert
Re: OpenSSL Security Advisory
On 6/5/2014 11:31 PM, Green, Gatewood wrote: Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems to be missing the symbol BN_consttime_swap. By the way, the BN_consttime_swap implementation in 1.0.1g (still downloading 1.0.1h) doesn't seem to completely match its description: - If nwords is 0, the code will overflow the input buffers by pretending that nwords is 10. Adding case 0 to the bottom of the switch should fix that. - If BN_ULONG is not exactly BN_BITS2 in size, the condition may also bit mishandled, is this property guaranteed by the type definitions on all platforms? - Other than the assert checking the power-of-2 assumption, the code should work with any condition in the range 0 to (1 (BN_BITS32-1)) inclusive, but not for larger values. - The only thing that needs a and b to be different variables is the assert checking that condition. At least this is how I read the code. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
In 0.9.8za, there is a missing compiler directive to include limits.h in ssl/s3_pkt.c. Without it, compiling fails on SPARC Solaris 10 with INT_MAX being undefined on line 536, which looks like: OPENSSL_assert(s-s3-wnum INT_MAX); It appears that 1.0.0m has the same problem. I haven't looked at 1.0.1h as yet. OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Jüri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Gröbert and Ivan FratriÄ at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTkEfyAAoJENNXdQf6QOnimvkP/0J12wcv/wq6NDfLCu8X
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20140605.txt Note: the online version of the advisory may be updated with additional details over time. -BEGIN PGP SIGNATURE- Version: GnuPG
Re: OpenSSL Security Advisory
In 0.9.8za at least, there is a missing directive to include limits.h. Without it, compilation fails on SPARC Solaris 10 with INT_MAXbeing undefined on line 536, which looks like: OPENSSL_assert(s-s3-wnum INT_MAX); It appears that 1.0.0m has the same problem. I haven't looked at 1.0.1h as yet. OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za also contain a fix for CVE-2014-0076: Fix for the attack described in the paper Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack Reported by Yuval
Re: OpenSSL Security Advisory
Hi Steve, That’s quite a few in one go - is this due to greater testing of OpenSSL and more scrutiny of the code by the community? Of the flaws listed, which is the one of most concern? This kind of begs the question what to do with all those embedded systems that run older versions of OpenSSL. Thanks — Juha On 5/06/2014, at 11:54 pm, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. Other issues OpenSSL 1.0.0m and OpenSSL 0.9.8za
RE: OpenSSL Security Advisory
Openssl-0.9.8za will not build in FIPS mode. The openssl-fips-1.2(.4) seems to be missing the symbol BN_consttime_swap. Woody Gatewood C Green Jr (Woody) Principal Software Engineer, Product Security Champion SIEM Engineering McAfee. Part of Intel Security. Direct: 208.552.8269 Mobile: 208.206.7455 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of OpenSSL Sent: Thursday, June 05, 2014 5:54 AM To: openssl-...@openssl.org; openssl-users@openssl.org; openssl-annou...@openssl.org Subject: OpenSSL Security Advisory -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [05 Jun 2014] Resend: first version contained characters which could cause signature failure. SSL/TLS MITM vulnerability (CVE-2014-0224) === An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server. The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution. OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za. OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m. OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h. Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for discovering and researching this issue. This issue was reported to OpenSSL on 1st May 2014 via JPCERT/CC. The fix was developed by Stephen Henson of the OpenSSL core team partly based on an original patch from KIKUCHI Masashi. DTLS recursion flaw (CVE-2014-0221) By sending an invalid DTLS handshake to an OpenSSL DTLS client the code can be made to recurse eventually crashing in a DoS attack. Only applications using OpenSSL as a DTLS client are affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue. This issue was reported to OpenSSL on 9th May 2014. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS invalid fragment vulnerability (CVE-2014-0195) A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Only applications using OpenSSL as a DTLS client or server affected. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. Thanks to Juri Aedla for reporting this issue. This issue was reported to OpenSSL on 23rd April 2014 via HP ZDI. The fix was developed by Stephen Henson of the OpenSSL core team. SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198) = A flaw in the do_ssl3_write function can allow remote attackers to cause a denial of service via a NULL pointer dereference. This flaw only affects OpenSSL 1.0.0 and 1.0.1 where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. The fix was developed by Matt Caswell of the OpenSSL development team. SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298) === A race condition in the ssl3_read_bytes function can allow remote attackers to inject data across sessions or cause a denial of service. This flaw only affects multithreaded applications using OpenSSL 1.0.0 and 1.0.1, where SSL_MODE_RELEASE_BUFFERS is enabled, which is not the default and not common. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. This issue was reported in public. Anonymous ECDH denial of service (CVE-2014-3470) OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a denial of service attack. OpenSSL 0.9.8 users should upgrade to 0.9.8za OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 1.0.1 users should upgrade to 1.0.1h. Thanks to Felix Grobert and Ivan Fratric at Google for discovering this issue. This issue was reported to OpenSSL on 28th May 2014. The fix
Re: OpenSSL Security Advisory
Ah, of course! I was so focused on not accessing that routine and not being able to just link in the obj files that the obvious solution of using the library properly escaped me! Thanks. After a Visual Studio 2012 build in directory: E:\usr_local\src\openssl-1.0.1f_32 I then was able put that change in and to compile and link very easily: cl -IE:\usr_local\src\openssl-1.0.1f_32\inc32 heartbleed.c /c link heartbleed.obj E:\usr_local\src\openssl-1.0.1f_32\out32dll\libeay32.lib E:\usr_local\src\openssl-1.0.1f_32\out32dll\ssleay32.lib I put those two dll files (ssleay32.dll and libeay32.dll) in my directory with the new exe from the build and it worked just fine. Thanks again to Tim Hudson, and of course to Rob Stradling for sharing the utility, Steve... On Fri, Apr 11, 2014 at 10:58 PM, Tim Hudson t...@cryptsoft.com wrote: On 11/04/2014 10:38 PM, Steven Kneizys wrote: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. The work around is trivial if you wanted to do that. Change to use the SSL_get_ssl_method function. This line: if (ssl3_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Simply becomes: if (SSL_get_ssl_method(v_ssl)-ssl_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Tim. -- Steve Kneizys Senior Business Process Engineer Voice: (610) 256-1396 [For Emergency Service (888)864-3282] Ferrilli Information Group -- Quality Service and Solutions for Higher Education web: http://www.ferrilli.com/ http://www.figsolutions.com/ Making you a success while exceeding your expectations.
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
some nice pictures how the bug works: http://www.xkcd.com/1354/ HIH matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 11/04/2014 12:58 AM, Viktor Dukhovni wrote: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 If you are using s_client for testing then you should add the -msg option and see what is being sent. Responding to a correctly formed heartbeat request is not an error - it is an indication that the server remains configured with heartbeat support. For example repeating that command as: (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 -msg And you can see the decoded heartbeat request and response - all with legal length values - 0x12 indicating 18 bytes of payload followed by the required 16 bytes of padding all exactly adding up to match the record size (3+18+16=37 which is the 0x0025 length field). HEARTBEATING ??? [length 0005] 18 03 03 00 3d TLS 1.2 [length 0025], HeartbeatRequest 01 00 12 00 00 c5 3c e4 48 f7 55 a8 83 62 df 03 a7 6b c2 48 05 60 e9 48 9e c1 6e 69 f4 fd 48 60 a9 35 bd 0c c3 ??? [length 0005] 18 03 03 00 3d TLS 1.2 [length 0025], HeartbeatResponse 02 00 12 00 00 c5 3c e4 48 f7 55 a8 83 62 df 03 a7 6b c2 48 05 75 07 79 df 92 dd b2 3c a6 9d 73 12 54 9c 66 57 read R BLOCK A number of users have provided various tools for testing whether or not an exploit is present. None of these tools are officially supported or blessed so are all use-at-your-own-risk. A couple of the tools others have mentioned already on this list are: https://github.com/noxxi/p5-scripts/blob/master/check-ssl-heartbleed.pl https://gist.github.com/robstradling/10363389 There are a whole range of checking tools that have varying approaches to how they test. Understanding what each tool does is important to understanding the effectiveness of their results in terms of claiming vulnerable or not vulnerable to the issue. Most people I've interacted with are using a combination of tools. The appropriate response to the issue is to follow the advice in the advisory - either move to a version with the patch for the defect applied or move to a version where the heartbeat code has been removed completely via compilation of the library with -DOPENSSL_NO_HEARTBEATS. If you connect to a site which does not support heartbeat (compiled out) then you will get something like this: HEARTBEATING 140153106511512:error:1413B16D:SSL routines:tls1_heartbeat:peer does not accept heartbearts:t1_lib.c:4049: ??? [length 0005] 15 03 01 00 20 TLS 1.0Alert [length 0002], warning close_notify 01 00 It is also possible to use the message callback function to block the response to heartbeat in application code if your library hasn't been patched. However the right solution is to fix the library via either of the methods mentioned in the advisory at https://www.openssl.org/news/secadv_20140407.txt Tim. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El dÃa Wednesday, April 09, 2014 a las 01:05:22AM -0700, monloi perez escribió: True. Thanks for the quick reply. On Wednesday, April 9, 2014 3:33 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan Hello, As you can read in the above change log, heartbeat support was introduced in version 1.0.1 of openssl. Does this mean that also the bug was introduced with this version in March 2012, or was it later? What is the exact bug, can someone show a svn/git diff of the first source version having the bug? Is it possible that the bug was introduced with intention (to make use of it later)? Here in Germany in the news we have rumor, that the bug was used by NSA, of course the American Goverment says no. Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 17:43, Matthias Apitz g...@unixarea.de wrote: El dÃa Wednesday, April 09, 2014 a las 01:05:22AM -0700, monloi perez escribió: True. Thanks for the quick reply. On Wednesday, April 9, 2014 3:33 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan Hello, As you can read in the above change log, heartbeat support was introduced in version 1.0.1 of openssl. Does this mean that also the bug was introduced with this version in March 2012, or was it later? As the security advisory states, the bug showed up in version 1.0.1 released in March 2012. What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Is it possible that the bug was introduced with intention (to make use of it later)? Here in Germany in the news we have rumor, that the bug was used by NSA, of course the American Goverment says no. I have read the rumor. It is wrong. I was Robins boss at the time he did the work, he worked in my lab. Neither me personally nor my lab at the university had any cooperations with any security agency (from any country). Robin worked on the OpenSSL code for multiple years. During his work with the DTLS code, he fixed a lot of bugs in that code and implemented some features, like the support of RFC 6520. He worked in the public, all his patches were submitted with his name. The intention was to improve OpenSSL, not to introduce bugs. Unfortunately, the patch above contained a bug which wasn't catched, neither by Robin, nor by the reviewers, nor by the people using the stack. It is a bug. A bug with a huge impact. Nothing more. Nothing less. Best regards Michael Tüxen Thanks matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X- No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 21:30, Matthias Apitz g...@unixarea.de wrote: El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks Here is the commit of the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=731f431497f463f3a2a97236fe0187b11c44aead Best regards Michael matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 09:30:22PM +0200, Matthias Apitz escribió: El día Saturday, April 12, 2014 a las 09:08:15PM +0200, Michael Tuexen escribió: What is the exact bug, can someone show a svn/git diff of the first source version having the bug? http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Hi, Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks ah, I see it in ssl/d1_both.c, the memcpy for the payload is done regardless if payload length and payload fit; forget my request. Thx matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12/04/14 21:30, Matthias Apitz wrote: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1 Thanks for the git diff (and the other statements). Could you please be so kind and point to the exact place of the offending statement (or missing boundary check) in the 19 *.[ch] files? I only want (as a C programmer) to get my own impression of the nature of the issue. Thanks Check ssl/d1_both.c /Jan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 03:43:29PM -0400, Michael Smith escribió: On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. agreed; and this bug wasn't hard to see (even for me, sitting in a restaurant with a netbook); in my company we do code review face to face, i.e. two persons (the coder and the reviewer) wade through the new code; one target of always questioning are copies in memory: do the amount of data fit into target location and is the source amount a valid space... matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
El día Saturday, April 12, 2014 a las 03:43:29PM -0400, Michael Smith escribió: On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. and one comment more: the bug works in both directions; when a client with an openssl lib/DLL with this bug connects to a well prepared SSL server, the server can fetch up to 64 kbyte of memory from the client, for example the stored saved passwords in your browser... matthias -- Sent from my FreeBSD netbook Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ f: +49-170-4527211 UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On 12 Apr 2014, at 21:43, Michael Smith m...@smithbowen.net wrote: On Apr 12, 2014, at 3:08 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I have read the rumor. It is wrong. Introduced with intent vs. known to the NSA -- two different things, right? My statement was referring to the Introduced with intend. I personally don't know anything about known to the NSA. Best regards Michael I don't have any direct knowledge of what goes on in the NSA, but if they don't have a whole cubicle farm full of people looking for vulnerabilities, I'd be surprised. OpenSSL would be an obvious high-value target for scrutiny just because of its ubiquity. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the nature of the heartbeat issue (was Re: OpenSSL Security Advisory)
On Apr 12, 2014, at 5:40 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: Introduced with intent vs. known to the NSA -- two different things, right? My statement was referring to the Introduced with intend. Understood. I'm personally quite sure it *wasn't* introduced with intent, which is why I thought it was important to note the distinction. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenSSL Security Advisory
The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. Steve... On Fri, Apr 11, 2014 at 7:40 AM, Walter H. walte...@mathemainzel.infowrote: On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ -- Steve Kneizys Senior Business Process Engineer Voice: (610) 256-1396 [For Emergency Service (888)864-3282] Ferrilli Information Group -- Quality Service and Solutions for Higher Education web: http://www.ferrilli.com/ http://www.figsolutions.com/ Making you a success while exceeding your expectations.
RE: OpenSSL Security Advisory
Also try your range here https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp Hth jaa -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Walter H. Sent: Friday, April 11, 2014 7:40 AM To: openssl-users@openssl.org Subject: Re: OpenSSL Security Advisory On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
In debian I solved linking directly static library. gcc -ansi -pedantic -o heartbleed heartbleed.c -lcrypto \ /usr/lib/x86_64-linux-gnu/libssl.a Regards In data venerdì 11 aprile 2014 08:38:07, Steven Kneizys ha scritto: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. Steve... On Fri, Apr 11, 2014 at 7:40 AM, Walter H. walte...@mathemainzel.infowrote: On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ -- -- Leonardo Secci mailto:leonardo.se...@unirel.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Thanks Leonardo! On 11/04/14 13:54, Leonardo Secci wrote: In debian I solved linking directly static library. gcc -ansi -pedantic -o heartbleed heartbleed.c -lcrypto \ /usr/lib/x86_64-linux-gnu/libssl.a Regards In data venerdì 11 aprile 2014 08:38:07, Steven Kneizys ha scritto: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. Steve... On Fri, Apr 11, 2014 at 7:40 AM, Walter H. walte...@mathemainzel.infowrote: On 10.04.2014 13:16, Rob Stradling wrote: On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. Hello, I get a link error - the same es the 2nd comment mentions there; how can I fix this? Thanks, Walter -- Mit freundlichen Grüßen, Best regards, Mes salutations distinguées, Ing. Walter Höhlhubmer _/ _/ _/_/ _/ _/ _/_/ Lederergasse 47a/7 _/ _/ _/_/ A-4020 Linz a. d. Donau _/ _/ _/ _/_/_/_/ Austria/EUROPE _/_/_/_/_/ _/_/ _/_/ _/_/ _/_/ (+43 664 / 951 83 72)_/ _/ _/_/ -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 11/04/2014 10:38 PM, Steven Kneizys wrote: The same issue when I tried to port over to windows, the ssl3_write_bytes is not exposed in the library. There doesn't seem to be an easy workaround that I can see. The work around is trivial if you wanted to do that. Change to use the SSL_get_ssl_method function. This line: if (ssl3_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Simply becomes: if (SSL_get_ssl_method(v_ssl)-ssl_write_bytes(v_ssl, TLS1_RT_HEARTBEAT, buf, 3 + payload + padding) = 0) Tim.
Re: OpenSSL Security Advisory
-Original Message- From: Matthias Apitz [mailto:g...@unixarea.de] Sent: Thursday, April 10, 2014 6:41 AM To: Apitz,Matthias Subject: Fwd: RE: OpenSSL Security Advisory - Forwarded message from Salz, Rich rs...@akamai.com - Date: Wed, 9 Apr 2014 15:43:28 -0400 From: Salz, Rich rs...@akamai.com To: openssl-users@openssl.org openssl-users@openssl.org Subject: RE: OpenSSL Security Advisory Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. My example tests only for those who have disabled TLs heartbeats, which is the safest thing, but not necessarily the only thing, to do. Hello, I have instrumented an openssl 1.0.1f as posted by Victor: guru@hein:~/openssl-1.0.1f diff ssl/t1_lib.c.unpatched ssl/t1_lib.c 2671c2671 s2n(payload, p); --- s2n(0x4000, p); but I still see HEARTBEATING, for example even from www.openssl.org: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 ... HEARTBEATING DONE Do I something wrong? Thx matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On 09/04/14 20:43, Salz, Rich wrote: Can you please post a good and a bad server example. I have tested a lot of servers, including 'akamai.com', and they all show HEARTBEATING at the end: Look at Victor's recent post about how to patch openssl/s_client to make your own test. That's the simplest. Simpler still... https://gist.github.com/robstradling/10363389 It's based on what Viktor posted, but it works without patching the OpenSSL library code. To compile: $ gcc -ansi -pedantic -o heartbleed heartbleed.c -lssl -lcrypto Examples: $ ./heartbleed www.ibm.com:443 NOT VULNERABLE (TLS Heartbeat extension not supported by the server) $ ./heartbleed secure.comodo.net:443 NOT VULNERABLE (TLS Heartbeat extension supported by the server) $ ./heartbleed mail.visservansolkema.nl:443 VULNERABLE! -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
On Thu, Apr 10, 2014 at 10:57:35AM +0200, Matthias Apitz wrote: I have instrumented an openssl 1.0.1f as posted by Victor: guru@hein:~/openssl-1.0.1f diff ssl/t1_lib.c.unpatched ssl/t1_lib.c 2671c2671 s2n(payload, p); --- s2n(0x4000, p); but I still see HEARTBEATING, for example even from www.openssl.org: guru@hein:~/openssl-1.0.1f/apps (sleep 3 ; echo B ; sleep 3) | ./openssl s_client -connect www.openssl.org:443 ... HEARTBEATING DONE Do I something wrong? That logs the request, you also need to see the reply... With servers that reply to the hearbeat you should see: ... HEARTBEATING read R BLOCK DONE -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan
Re: OpenSSL Security Advisory
True. Thanks for the quick reply. On Wednesday, April 9, 2014 3:33 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: https://www.openssl.org/news/changelog.html 1.0.1 introduced the heartbeat support. 1.0.0 and earlier are fortunate in that they didnt have it.but then they didnt have things to stop you from being BEASTed so some you win, some you lose. ;) alan
Re: OpenSSL Security Advisory
How do I determine whether or not the web servers I run are affected? They are Apache 2.4, built for 64 bit Windows and downloaded from Apachelounge. I have no idea what version of openssl it was built with. Does anyone here know if the feature that introduces the risk can be turned off, without introducing other risks? If so, how? Also, could the security keys we bought have been compromised? Any advice on how I can protect my servers better would be appreciated. Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. On Mon, Apr 7, 2014 at 4:31 PM, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/ QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/ OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd J37YgDNuefzrsA+B5/o7 =szjb -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
http://filippo.io/Heartbleed/#www.unlocator.com On Wed, Apr 9, 2014 at 2:05 PM, Ted Byers r.ted.by...@gmail.com wrote: How do I determine whether or not the web servers I run are affected? They are Apache 2.4, built for 64 bit Windows and downloaded from Apachelounge. I have no idea what version of openssl it was built with. Does anyone here know if the feature that introduces the risk can be turned off, without introducing other risks? If so, how? Also, could the security keys we bought have been compromised? Any advice on how I can protect my servers better would be appreciated. Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. On Mon, Apr 7, 2014 at 4:31 PM, OpenSSL open...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL Security Advisory [07 Apr 2014] TLS heartbeat read overrun (CVE-2014-0160) == A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley a...@chromium.org and Bodo Moeller bmoel...@acm.org for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJTQt1bAAoJENNXdQf6QOniGhkP/AjjZgV+g7ZyxnxdnvA2+sdV sxNso208Cod8DKnDONtXHuPTkTFfyHl72FM1ea99woe3X6JWj3PyiZGvSfeo4Jj/ QiDJvvcHc5Xq00gAr6MIarhMJbRtYkM+Th6PPXyqODYcb/pDoqy5VWo/R9QkZTPn zaiXPyapJB/qSYo4UqXWerT9YTLdYmiro//kQN0U/SedF/fNz4CEBcMyz6z7YJAC LFoE6Vf54PAkNvxjcX9ugIKluBMk5YONRG8PB0X/UDwf9Kj4L6OTT51x1yeFw3Sg GzTqvKD+2JWzFDCcfJULRCSCEwHhKbjR7n3sI1RPaaEWp5E63+9HSMRYjVOFIwt/ OTrMPbW1BEiX0A7NB7HSrrvddnYd3sz8A44v00oesr+XaW5nyu79IndQwLhPkKYF Dkb67quw/tfV6Y1r4sETqSd2FrM7MpFzltywMKzVKWNpMSwOAWSBGUl7VH0m84Ty zAufUSEnYIA3dMC2DnHie+ot4WnjJlTErBmfUb/QNbNYDt0vjhS60oydP1NJ8AlG aoUK7mslOlVCauAIeGNbi4PzJ+LvWYmyFFGT+M1/UOBZFFvG7jsReBjTIu9dg3Za S7NE7CeMvRRpOEm1+T9L8a26/c6C9dwF7JPQvMpTR3BeT2jjkYe8rdTCkT91g1sd J37YgDNuefzrsA+B5/o7 =szjb -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
