Print this pagePrint this page

Email this topicEmail this topic

View PDFView PDF

Download EPUBDownload EPUB

Critical CVEs

The following section lists addressed/fixed vulnerabilities in ExtremeXOS 22.6.

SSHD in OpenSSH Potential Denial of Service (DoS) (CVE CVE-2016-10708)

Impact SSHD in OpenSSH before 7.4 is vulnerable to a DoS attack.
Attack Vector remote
CVS base score 7.5 High CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Description SSHD in OpenSSH before 7.4 allows remote attackers to cause DOS attack (NULL pointer dereference and daemon crash) using an out-of-sequence NEWKEYS message, as demonstrated by Honggfuzz, related to kex.c and packet.c.
Detail SSHD in OpenSSH before 7.4 allows remote attackers to cause DOS attack (NULL pointer dereference and daemon crash) using an out-of-sequence NEWKEYS message, as demonstrated by Honggfuzz, related to kex.c and packet.c.

OpenSSL Fatal Error May Not Be Handled Correctly (CVE-2017-3737)

Impact OpenSSL fatal error may not be handled correctly.
Attack Vector remote
CVS base score 5.9 Medium CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Description The OpenSSL error state works for 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, the handshake can fail, but data is passed without being decrypted/encrypted directly from the SSL/TLS record layer.
Detail 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. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
Published April 2019prev | next

Email this topicEmail this topic

Print this pagePrint this page