X-Git-Url: https://git.openssl.org/?a=blobdiff_plain;f=news%2Fvulnerabilities.xml;h=b5fcb272c1e1ea04d908dc887b4a9725c98b9784;hb=8e91dc9cffe8bd60e52b5eacffe5a24341533a72;hp=668e9874ec249607b3f1a5b1f363f0658a06c0f6;hpb=9e202bb48ed00656e8af83e6cd654a4e2209948a;p=openssl-web.git diff --git a/news/vulnerabilities.xml b/news/vulnerabilities.xml index 668e987..b5fcb27 100644 --- a/news/vulnerabilities.xml +++ b/news/vulnerabilities.xml @@ -5,7 +5,183 @@ 1.0.0 on 20100329 --> - + + + + + + + + + + + + + + + + + + + Unauthenticated read/unencrypted write + Read/write after SSL object in error state + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + carry-propagating bug + bn_sqrx8x_internal carry bug on x86_64 + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + carry-propagating bug + bn_sqrx8x_internal carry bug on x86_64 + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + out-of-bounds read + Possible Overread in parsing X.509 IPAdressFamily + + While parsing an IPAdressFamily extension in an X.509 certificate, + it is possible to do a one-byte overread. This would result in + an incorrect text display of the certificate. + + + + @@ -195,7 +371,6 @@ 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.ctures using a callback which do not handle NULL value are affected. @@ -4181,6 +4356,8 @@ large session ID in SSL3. + + A buffer overflow when Kerberos is enabled allowed attackers @@ -4191,6 +4368,7 @@ flaw did not affect any released version of 0.9.6 or 0.9.7 + @@ -4202,10 +4380,12 @@ service by sending invalid encodings. - + - + + + The use of assertions when detecting buffer overflow attacks allowed remote attackers to cause a denial of service (crash) by @@ -4463,7 +4643,9 @@ use Kerberos ciphersuites and will therefore be unaffected. - + + + @@ -4769,7 +4951,8 @@ only when applications are compiled for debugging. - + + The PRNG implementation for the OpenSSL FIPS Object Module 1.1.1 does not perform auto-seeding during the FIPS self-test, which generates @@ -4916,7 +5099,9 @@ read, for example RSA public keys. - + + + Fix a NULL pointer dereference if a DTLS server recieved @@ -4949,6 +5134,7 @@ Implement RFC5746 to address vulnerabilities in SSL/TLS renegotiation. + @@ -4972,8 +5158,67 @@ remote attacker could use this flaw to cause a DTLS server to crash. + + + + + + + + + + + + + + + + + + + +Fix a denial of service flaw in the DTLS implementation. +Records are buffered if they arrive with a future epoch to be +processed after finishing the corresponding handshake. There is +currently no limitation to this buffer allowing an attacker to perform +a DOS attack to a DTLS server by sending records with future epochs until there is no +memory left. + + + + + + + + + + + + + + + + + + + + + + + + Fix a denial of service flaw in the DTLS implementation. +In dtls1_process_out_of_seq_message() the check if the current message +is already buffered was missing. For every new message was memory +allocated, allowing an attacker to perform an denial of service attack +against a DTLS server by sending out of seq handshake messages until there is no memory +left. + + + + + @@ -4987,12 +5232,14 @@ remote attacker could use this flaw to cause a DTLS server to crash. - + + + -Fix denial of service flaws in the DTLS implementation. A -remote attacker could use these flaws to cause a DTLS server to use -excessive amounts of memory, or crash. + Use-after-free vulnerability in the dtls1_retrieve_buffered_fragment + function could cause a client accessing a malicious DTLS server to + crash. @@ -5011,7 +5258,9 @@ excessive amounts of memory, or crash. - + + + A memory leak in the zlib_stateful_finish function in crypto/comp/c_zlib.c @@ -5036,7 +5285,9 @@ function. - + + + It was discovered that OpenSSL did not always check the return value of the @@ -5062,7 +5313,9 @@ or, possibly, execute arbitrary code - + + + A missing return value check flaw was discovered in OpenSSL, that could @@ -5852,7 +6105,7 @@ This issue only affected OpenSSL 1.0.1 versions. - + @@ -5871,6 +6124,7 @@ server could use this flaw to crash a connecting client. This issue only affect +