OpenSSL安全公告高危漏洞 可以對預設配置的伺服器發動DDoS攻擊

OpenSSL專案組在今天釋出高威脅安全通告CVE-2016-6304，更新內容包括：修復了自2016年5月以來的安全漏洞，其中包括一個高危漏洞，一個為“中危”，其餘均評級為“低危”。OpenSSL安全公告 [22 Sep 2016]公告如下：

OCSP狀態請求擴充套件跨記憶體邊界增長(CVE-2016-6304)

安全等級: 高危

惡意的客戶端可以傳送過大的OCSP狀態請求延期。如果該客戶端不斷請求重新談判，傳送一個大的 OCSP 狀態請求每延長一次，那麼就會有無限的記憶體增長在伺服器上。這最終將導致通過記憶體耗盡的拒絕服務攻擊。這種攻擊在使用預設配置的伺服器上很容易執行，即使他們不支援 OCSP。建立使用"無 ocsp"生成時間選項不會受到影響。

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 應該升級到 1.1.0a 
OpenSSL 1.0.2 應該升級到 1.0.2i 
OpenSSL 1.0.1 應該升級到 1.0.1u

SSL_peek() hang on empty record (CVE-2016-6305) 
===============================================

安全等級：中

攻擊者可以通過傳送一個空記錄，從而在呼叫SSL_peek()函式時引起拒絕服務。

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) 
==================================

安全等級：低

該漏洞涉及SWEET32攻擊，一種針對64位分組密碼演算法的生日攻擊。

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) 
==========================================

安全等級：低

該漏洞是存在於函式MDC2_Update()中的一個整數溢位，導致記憶體破壞，進而允許拒絕服務攻擊

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

Malformed SHA512 ticket DoS (CVE-2016-6302) 
===========================================

安全等級：低

該漏洞是存在於函式MDC2_Update()中的一個整數溢位，導致記憶體破壞，進而允許拒絕服務攻擊

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

OOB write in BN_bn2dec() (CVE-2016-2182) 
========================================

安全等級：低

位於crypto/bn/bn_print.c的函式BN_bn2dec（）沒有檢驗BN_div_word()函式的返回值，允許記憶體越界寫入，從而引起拒絕服務

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

OOB read in TS_OBJ_print_bio() (CVE-2016-2180) 
==============================================

安全等級：低

位於crypto/ts/ts_lib.c中的函式TS_OBJ_print_bio()存在越界寫入問題，允許拒絕服務

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 users should upgrade to 1.0.1u

Pointer arithmetic undefined behaviour (CVE-2016-2177) 
======================================================

安全等級：低

在計算堆緩衝區的邊界時出錯，允許攻擊者發起拒絕服務攻擊

Avoid some undefined pointer arithmetic

A common idiom in the codebase is to check limits in the following manner: 
"p + len > limit"

Where "p" points to some malloc'd data of SIZE bytes and 
limit == p + SIZE

"len" here could be from some externally supplied data (e.g. from a TLS 
message).

The rules of C pointer arithmetic are such that "p + len" is only well 
defined where len <= SIZE. Therefore the above idiom is actually 
undefined behaviour.

For example this could cause problems if some malloc implementation 
provides an address for "p" such that "p + len" actually overflows for 
values of len that are too big and therefore p + len < limit.

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 4th May 2016 by Guido Vranken. The 
fix was developed by Matt Caswell of the OpenSSL development team.

Constant time flag not preserved in DSA signing (CVE-2016-2178) 
===============================================================

安全等級：低

位於crypto/dsa/dsa_ossl.c中的函式dsa_sign_setup()，沒有正確處理constant-time，允許攻擊者通過邊通道攻擊獲得DSA的私鑰

Operations in the DSA signing algorithm should run in constant time in order to 
avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that 
a non-constant time codepath is followed for certain operations. This has been 
demonstrated through a cache-timing attack to be sufficient for an attacker to 
recover the private DSA key.

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 23rd May 2016 by César Pereida (Aalto 
University), Billy Brumley (Tampere University of Technology), and Yuval Yarom 
(The University of Adelaide and NICTA). The fix was developed by César Pereida.

DTLS buffered message DoS (CVE-2016-2179) 
=========================================

安全等級：低

在DTLS的實現中，沒有正確處理未按序到達的握手訊息快取，允許攻擊者同時維護多個精心構造的DTLS會話，導致拒絕服務

In a DTLS connection where handshake messages are delivered out-of-order those 
messages that OpenSSL is not yet ready to process will be buffered for later 
use. Under certain circumstances, a flaw in the logic means that those messages 
do not get removed from the buffer even though the handshake has been completed. 
An attacker could force up to approx. 15 messages to remain in the buffer when 
they are no longer required. These messages will be cleared when the DTLS 
connection is closed. The default maximum size for a message is 100k. Therefore 
the attacker could force an additional 1500k to be consumed per connection. By 
opening many simulataneous connections an attacker could cause a DoS attack 
through memory exhaustion.

OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i 
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 22nd June 2016 by Quan Luo. The fix was 
developed by Matt Caswell of the OpenSSL development team.

DTLS replay protection DoS (CVE-2016-2181) 
==========================================

安全等級：低

在DTLS的實現中，沒有正確處理未按序到達的握手訊息快取，允許攻擊者同時維護多個精心構造的DTLS會話，導致拒絕服務

A flaw in the DTLS replay attack protection mechanism means that records that 
arrive for future epochs update the replay protection "window" before the MAC 
for the record has been validated. This could be exploited by an attacker by 
sending a record for the next epoch (which does not have to decrypt or have a 
valid MAC), with a very large sequence number. This means that all subsequent 
legitimate packets are dropped causing a denial of service for a specific 
DTLS connection.

OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i 
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u

This issue was reported to OpenSSL on 21st November 2015 by the OCAP audit team. 
The fix was developed by Matt Caswell of the OpenSSL development team.

Certificate message OOB reads (CVE-2016-6306) 
=============================================

安全等級：低

在OpenSSL的1.0.2及更早版本中，缺少對一些訊息長度的校驗，導致記憶體越界讀取，在理論上允許拒絕服務攻擊

In OpenSSL 1.0.2 and earlier some missing message length checks can result in 
OOB reads of up to 2 bytes beyond an allocated buffer. There is a theoretical 
DoS risk but this has not been observed in practice on common platforms.

The messages affected are client certificate, client certificate request and 
server certificate. As a result the attack can only be performed against 
a client or a server which enables client authentication.

OpenSSL 1.1.0 is not affected.

OpenSSL 1.0.2 users should upgrade to 1.0.2i 
OpenSSL 1.0.1 users should upgrade to 1.0.1u

Excessive allocation of memory in tls_get_message_header() (CVE-2016-6307) 
==========================================================================

安全等級：低

tls_get_message_header()函式存在檢查缺陷，導致攻擊者可以通過精心構造的資料包，使記憶體過度分配，進而藉此大量消耗伺服器的記憶體導致拒絕服務

A TLS message includes 3 bytes for its length in the header for the message. 
This would allow for messages up to 16Mb in length. Messages of this length are 
excessive and OpenSSL includes a check to ensure that a peer is sending 
reasonably sized messages in order to avoid too much memory being consumed to 
service a connection. A flaw in the logic of version 1.1.0 means that memory for 
the message is allocated too early, prior to the excessive message length 
check. Due to way memory is allocated in OpenSSL this could mean an attacker 
could force up to 21Mb to be allocated to service a connection. This could lead 
to a Denial of Service through memory exhaustion. However, the excessive message 
length check still takes place, and this would cause the connection to 
immediately fail. Assuming that the application calls SSL_free() on the failed 
conneciton in a timely manner then the 21Mb of allocated memory will then be 
immediately freed again. Therefore the excessive memory allocation will be 
transitory in nature. This then means that there is only a security impact if:

1) The application does not call SSL_free() in a timely manner in the 
event that the connection fails 
or 
2) The application is working in a constrained environment where there 
is very little free memory 
or 
3) The attacker initiates multiple connection attempts such that there 
are multiple connections in a state where memory has been allocated for 
the connection; SSL_free() has not yet been called; and there is 
insufficient memory to service the multiple requests.

Except in the instance of (1) above any Denial Of Service is likely to 
be transitory because as soon as the connection fails the memory is 
subsequently freed again in the SSL_free() call. However there is an 
increased risk during this period of application crashes due to the lack 
of memory - which would then mean a more serious Denial of Service.

This issue does not affect DTLS users.

OpenSSL 1.1.0 TLS users should upgrade to 1.1.0a

Excessive allocation of memory in dtls1_preprocess_fragment() (CVE-2016-6308) 
=============================================================================

安全等級：低

dtls1_preprocess_fragment()存在檢查缺陷，導致伺服器的記憶體可以過度分配，進而以前拒絕服務攻擊

This issue is very similar to CVE-2016-6307. The underlying defect is different 
but the security analysis and impacts are the same except that it impacts DTLS.

A DTLS message includes 3 bytes for its length in the header for the message. 
This would allow for messages up to 16Mb in length. Messages of this length are 
excessive and OpenSSL includes a check to ensure that a peer is sending 
reasonably sized messages in order to avoid too much memory being consumed to 
service a connection. A flaw in the logic of version 1.1.0 means that memory for 
the message is allocated too early, prior to the excessive message length 
check. Due to way memory is allocated in OpenSSL this could mean an attacker 
could force up to 21Mb to be allocated to service a connection. This could lead 
to a Denial of Service through memory exhaustion. However, the excessive message 
length check still takes place, and this would cause the connection to 
immediately fail. Assuming that the application calls SSL_free() on the failed 
conneciton in a timely manner then the 21Mb of allocated memory will then be 
immediately freed again. Therefore the excessive memory allocation will be 
transitory in nature. This then means that there is only a security impact if:

1) The application does not call SSL_free() in a timely manner in the event that the connection fails 
2) The application is working in a constrained environment where there is very little free memory 
3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests.

Except in the instance of (1) above any Denial Of Service is likely to 
be transitory because as soon as the connection fails the memory is 
subsequently freed again in the SSL_free() call. However there is an 
increased risk during this period of application crashes due to the lack 
of memory - which would then mean a more serious Denial of Service.

This issue does not affect TLS users.

OpenSSL 1.1.0 DTLS users should upgrade to 1.1.0a

宣告

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.

參考資訊

URL for this Security Advisory: 
https://www.openssl.org/news/secadv/20160922.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

原文釋出時間：2017年3月24日

本文由：安全加 釋出，版權歸屬於原作者

原文連結：http://toutiao.secjia.com/openssl-security-advisory-cve-2016-6304

本文來自雲棲社群合作伙伴安全加，瞭解相關資訊可以關注安全加網站