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

本文来自云栖社区合作伙伴安全加,了解相关信息可以关注安全加网站

相关文章
|
4天前
|
人工智能 运维 监控
2025年阿里云服务器配置选择全攻略:CPU、内存、带宽与系统盘详解
在2025年,阿里云服务器以高性能、灵活扩展和稳定服务助力数字化转型,提供轻量应用服务器、通用型g8i实例等多样化配置,满足个人博客至企业级业务需求。针对不同场景(如计算密集型、内存密集型),推荐相应实例类型与带宽规划,强调成本优化策略,包括包年包月节省成本、ESSD云盘选择及地域部署建议。文中还提及安全设置、监控备份的重要性,并指出未来可关注第九代实例g9i支持的新技术。整体而言,阿里云致力于帮助用户实现性能与成本的最优平衡。 以上简介共计238个字符。
|
4天前
|
存储 人工智能 缓存
怎么根据自己的业务选择阿里云服务器配置大小?
本文指导如何根据业务需求精准选择阿里云服务器配置,涵盖个人轻量级至企业级、计算密集型等场景,推荐不同实例类型、存储与带宽方案,并提供成本优化策略,如包年包月节省成本、按需升级配置及选用性价比高的自研ARM架构实例。帮助用户在数字化转型中实现性能与成本的平衡。 注:以上配置与价格基于阿里云2025年官方数据,实际信息可能有所调整,请以官网实时页面为准。
|
4天前
|
存储 人工智能 监控
新手小白购买阿里云服务器省钱策略、配置选型与注意事项
针对初次使用阿里云服务器的用户,本文提供系统化的指导方案以优化成本并满足业务需求。首先介绍配置选型,包括实例类型(通用型、计算型、内存型)与基础配置建议;其次阐述省钱策略,如企业认证、合理选择计费模式及批量购买;最后提醒注意事项,涵盖带宽存储规划、地域网络优化及安全管理。新手可通过明确需求、选择配置、优化购买和持续监控四步快速上手,实现高效稳定的云端部署。 注:推荐配置基于2025年阿里云产品体系,具体信息请参考官网。
|
5天前
|
存储 弹性计算 人工智能
2025年阿里云企业云服务器ECS选购与配置全攻略
本文介绍了阿里云服务器的核心配置选择方法论,涵盖算力需求分析、网络与存储设计、地域部署策略三大维度。针对不同业务场景,如初创企业官网和AI模型训练平台,提供了具体配置方案。同时,详细讲解了购买操作指南及长期运维优化建议,帮助用户快速实现业务上云并确保高效运行。访问阿里云官方资源聚合平台可获取更多最新产品动态和技术支持。
|
6天前
|
存储 人工智能 并行计算
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
|
10天前
|
存储 弹性计算 安全
阿里云服务器购买后设置密码、安全组、基础安全服务、挂载云盘等流程简介
对于初次选购阿里云服务器的用户来说,通过阿里云推出的各类活动买到心仪的云服务器仅仅是第一步。为了确保云服务器能够正常运行并承载您的应用,购买之后还需要给云服务器设置远程登录密码、设置安全组规则、设置基础安全、购买并挂载云盘等操作之后,我们才能使用并部署自己的应用到云服务器上。本文将详细介绍在阿里云的活动中购买云服务器后,您必须完成的几个关键步骤,助您快速上手并充分利用云服务器的强大功能。
|
12天前
|
存储 人工智能 安全
实时拦截攻击并响应威胁,聊聊服务器DDoS防御软件
实时拦截攻击并响应威胁,聊聊服务器DDoS防御软件
51 16
|
1月前
|
云安全 监控 安全
服务器的使用安全如何保障
德迅卫士主机安全软件,采用自适应安全架构,有效解决传统专注防御手段的被动处境,精准捕捉每一个安全隐患,为您的主机筑起坚不可摧的安全防线
|
1月前
|
弹性计算 安全 搜索推荐
阿里云国际站注册教程:阿里云服务器安全设置
阿里云国际站注册教程:阿里云服务器安全设置 在云计算领域,阿里云是一个备受推崇的品牌,因其强大的技术支持和优质的服务而受到众多用户的青睐。本文将为您介绍阿里云国际站的注册过程,并重点讲解如何进行阿里云服务器的安全设置。
|
2月前
|
存储 弹性计算 运维
端到端的ECS可观测性方案,助力云上业务安全稳定
本文介绍了云原生时代保障业务系统可靠性的方法和挑战,重点探讨了阿里云ECS在提升业务稳定性、性能监控及自动化恢复方面的能力。文章分为以下几个部分:首先,阐述了业务可靠性的三个阶段(事前预防、事中处理、事后跟进);其次,分析了云上业务系统面临的困难与挑战,并提出了通过更实时的监测和自动化工具有效规避风险;接着,详细描述了ECS实例稳定性和性能问题的解决方案;然后,介绍了即将发布的ECS Lens产品,它将全面提升云上业务的洞察能力和异常感知能力;最后,通过具体案例展示了如何利用OS自动重启和公网带宽自适应调节等功能确保业务连续性。总结部分强调了ECS致力于增强性能和稳定性的目标。

热门文章

最新文章