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.

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.

In OpenSSL 1.0.2 an "error state" mechanism was introduced. This "error state" mechanism does not work correctly if SSL_read() or SSL_write() is called directly by an application. This could result in data being sent out unencrypted by the SSL/TLS record layer. Successful exploitation requires an attacker to cause a fatal error in the victim's SSL/TLS handshake algorithm, and that the targeted application calls SSL_read() or SSL_write() after having already received a fatal error. No user interaction or privileges are required to exploit this security vulnerability. The vulnerability could allow to compromise confidentiality of data by transmitting it unencrypted over the network.

libopenssl-1_0_0-devel-1.0.2u-6.2 on GA media

openssl: Out-of-bounds write caused by unchecked errors in BN_bn2dec() httpd: CRLF injection allowing HTTP response splitting attacks for sites which use mod_userdir openssl: Insufficient TLS session ticket HMAC length checks openssl: certificate message OOB reads openssl: Carry propagating bug in Montgomery multiplication openssl: Truncated packet could crash via OOB read openssl: BN_mod_exp may produce incorrect results on x86_64 openssl: bn_sqrx8x_internal carry bug on x86_64 openssl: Read/write after SSL object in error state openssl: rsaz_1024_mul_avx2 overflow bug on x86_64

Security update for openssl

Affected: Ubuntu:16.04:LTS: openssl

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.

Multiple vulnerabilities have been identified in PHOENIX CONTACT AXC F 2152 with firmware versions 1.x

Ein entfernter, anonymer, authentisierter oder lokaler Angreifer kann mehrere Schwachstellen in IBM Tivoli Network Manager ausnutzen, um beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, vertrauliche Informationen offenzulegen, einen Denial-of-Service-Zustand herbeizuführen, seine Privilegien auszuweiten, Daten zu manipulieren, nicht spezifizierte Auswirkungen zu verursachen und einen Cross-Site-Scripting-Angriff durchzuführen.