2018-06-15

该文无参考价值，仅供自己阅读记录

DTLS buffered message DoS (CVE-2016-2179)

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.
在握手消息乱序递送的DTLS连接中，那些OpenSSL尚未准备好处理的消息将被缓冲以备后用。 在某些情况下，逻辑上的缺陷意味着即使握手已完成，这些消息也不会从缓冲区中移除。 攻击者可以强制达到约。 当消息不再需要时，15条消息保留在缓冲区中。 这些消息将在DTLS连接关闭时清除。 消息的默认最大大小为100k。 因此，攻击者可以强制每个连接消耗额外的1500k。 通过打开许多同时连接，攻击者可以通过内存耗尽导致DoS攻击。
OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u

DTLS replay protection DoS (CVE-2016-2181)

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.
DTLS重放攻击保护机制中的一个缺陷意味着记录到达未来时期的记录会在记录的MAC验证通过之前更新重播保护“窗口”。 攻击者可以通过发送下一个记录（不必解密或具有有效的MAC）的记录来利用这个记录，并且具有非常大的序列号。 这意味着所有后续的合法数据包都将被丢弃，从而导致针对特定DTLS连接的拒绝服务。
OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i
OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u

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

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.
函数BN_bn2dec()不会检查BN_div_word()的返回值，如果应用程序使用此函数且BIGNUM过大，则可能会导致OOB写入。 如果从不受信任的源打印出过大的证书或CRL，这可能会成为问题。 TLS不受影响，因为记录限制会在分析之前拒绝超大型证书。

Malformed SHA512 ticket DoS (CVE-2016-6302)

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.

如果服务器对TLS会话票据HMAC使用SHA512，则它容易受到DoS攻击，其中格式错误的票证将导致OOB读取，最终会导致崩溃。

在TLS会话票据中使用SHA512相对较少，因为它需要自定义服务器回调和故障单查找机制。

OOB write in MDC2_Update() (CVE-2016-6303)

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.
如果直接调用或通过使用MDC2的EVP_DigestUpdate()函数，MDC2_Update()中可能会发生溢出。 如果攻击者能够在先前调用带有部分块的EVP_EncryptUpdate()之后提供大量输入数据，则长度检查可能会溢出，从而导致堆损坏。

所需数据量与SIZE_MAX相当，在大多数平台上这是不切实际的。
https://www.openssl.org/news/secadv/20160922.txt