55

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议-InfoQ

 4 years ago
source link: https://www.infoq.cn/article/gc3*ZGs49Tj5fHkh9frM
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Linux 内核被曝 TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

发布于:2019 年 6 月 21 日 09:24

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

近日,Linux 内核发现三个 TCP 网络处理相关软件缺陷,最严重的漏洞可触发内核崩溃,从而影响系统可用性,多家云服务商给出紧急修复建议。

近日, Red Hat 在官网给出通知称在 Linux 内核中发现了三个关于 TCP 网络处理的软件缺陷,这最初是由 Netflix 工程师所发现。该漏洞可导致服务器宕机。如果远程攻击者运行受漏洞影响的软件系统,其中最严重的漏洞可触发内核崩溃,从而影响系统的可用性。

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

现在这些软件缺陷已经指派给了多个 CVE(公开漏洞和暴露问题,Common Vulnerabilities & Exposures)。其中, CVE-2019-11477 的严重性被指派为“严重”(Important), CVE-2019-11478 CVE-2019-11479 的严重性被指派为“中等”(Moderate)。

前两个 CVE 是关于 SACK(选择性确认,Selective Acknowledgement)数据包及 MSS(最大段大小,Maximum Segment Size)问题,第三个 CVE 仅与 MSS 相关。

上述问题是通过应用修复(Mitigation)或内核补丁得以修正的。修复细节和与 RHSA 建议的关联,可查看原文的“RESOVLE”选项卡内容

问题详情和背景

Red Hat 在 Linux 内核中发现了三个软件缺陷,涉及处理低 MSS 的 TCP SACK 网络包。据悉,上述缺陷影响程度仅局限于拒绝服务(DoS)。目前尚未出现漏洞权限升级问题,或导致信息泄露。

尽管可以使用原文提供的应用修复措施解决问题,但这些错误可能对合法来源的流量造成影响。合法来源流量的正确传输,需要较低的 MSS 值,这样传输性能才能表现正常。在应用解决措施之前,请先评估适合系统环境的应用修复措施。

什么是 SACK(选择性确认)?

TCP 选择性确认(SACK)提供了一种机制,用于告知数据接收方已成功接收发送方的所有数据段。该机制允许发送方从“已知正确”数据集中,重新传输数据流中丢失的数据段。一旦禁用 TCP SACK,那么传输完整的数据流需重传更大的数据集。

什么是 MSS(最大段大小)?

最大段大小(MSS)是在 TCP 网络包报头中设置的一个参数,指定重构 TCP 数据段中所包含的数据总量。

由于在跨不同路由传输时数据包可能会产生碎片,因此必须指定 MSS 为主机可处理的最大 IP 数据报的有效负载规模。如果 MSS 非常大,那么意味着在到达目的地的传输路径上,数据包流可能最终会产生碎片化。而如果数据包较小,则可确保产生较少的碎片,但最终会导致一些开销未使用。

MSS 大小可由操作系统和传输类型默认确定。获取了特殊访问权限的攻击者可创建原始数据包,并通过精心选择 MSS 选项发起此类攻击。

TCP SACK

TCP 是面向连接的协议。如果通信双方希望通过 TCP 连接进行通信时,那么双方通过特定信息交换建立连接。例如,请求发起连接(SYN)、初始序列号、确认序列号、此连接使用的最大段大小(MSS)、权限发送和处理 SACK 等。建立该连接的过程称为“三次握手”。

TCP 通过称为“数据段”(Segment)的单元发送和接收用户数据。TCP 数据段包括 TCP 报头、选项和用户数据。

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

每个 TCP 数据段具有一个序列号(SEQ,Sequence Number)和确认号(ACK,Acknowledgement Number)。

SEQ 和 ACK 用于追踪数据段是否被接收者成功接收。ACK 指示了接收者期待接收到下一个数据段。

例如,用户 A 通过 13 个 100 字节大小的数据段发送 1KB 数据,其中每个数据段具有 20 个字节的 TCP 头部。在接收端,用户 B 接收到数据段 1、2、4、6 和 8 到 13,2、5 和 7 数据段丢失,并未被用户 B 接收。

如果使用 ACK,用户 B 给出希望接收数据段 3,那么用户 A 则会视为用户 B 在数据段 2 之后并未接收到任何数据段。这样,尽管数据段 4、6 和 8 到 13 被用户 B 已被成功接收,用户 A 仍然会重传数据段 3 之后的所有数据段。用户 B 没有办法指示用户 A,这导致对网络低效利用。

SACK(选择性确认)

为解决上述问题,RFC-2018 设计并定义了 SACK 机制。如果使用 SACK,用户 B 通过 TCP 选项域告知用户 A 所有已被成功接收的数据段(即 1、2、4、6、8 到 13)。这样,用户 A 仅需要重新传输数据段 3、5 和 7。SACK 可很大程度上节省网络带宽,避免了进一步网络拥堵。

CVE-2019-11477 SACK Panic:

套接字缓存(Socket Buffers, SKB )。

套接字缓存(SKB)是 Linux TCP/IP 实现中使用的一个最核心数据结构。它是一个由缓存组成的链接列表,用于保存网络数据包。该列表可以用做传输队列、接收队列、SACK 队列、重传队列等。SKB 支持以数据段方式保存分组数据。Linux SKB 最多可以保存 17 个数据段。

复制代码
linux/include/linux/skbuff.h
define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1) => 17

在 x86 上,每个数据段可保存最多 32KB 数据。而在 PowerPC 上为 64KB。数据包一旦被确认发送,就被置于“发送”队列中,数据包的详细信息则保存在一个缓存控制结构中,定义如下:

复制代码
linux/include/linux/skbuff.h
struct tcp_skb_cb {
__u32 seq; /* Starting sequence number */
__u32 end_seq; /* SEQ + FIN + SYN + datalen */
__u32 tcp_tw_isn;
struct {
u16 tcp_gso_segs;
u16 tcp_gso_size;
__u8 tcp_flags; /2* TCP header flags. (tcp[13]) */

该结构定义中,“tcp_gso_segs”和“tcp_gso_size”字段用于保存设备驱动程序相关负载数据分段信息。

一旦启用 Segmentation 负载和 SACK 机制,由于存在数据包丢失和某些数据包的选择性重传,SKB 最终可能会保存多个数据包,个数由“tcp_gso_segs”记录。列表中的多个此类 SKB 被合并为一个 SKB,以有效地处理不同的 SACK 数据块,其中包括将数据从一个 SKB 移动到列表中的另一个 SKB。在移动数据期间,SKB 结构可以达到其最大限制 17 个片段。这样“tcp_gso_segs”参数可溢出,并触发下游的 BUG_ON() 调用,从而导致所称的“内核恐慌”(kernel panic)问题。

复制代码
static bool tcp_shifted_skb (struct sock *sk, …, unsigned int pcount, ...)
tcp_skb_pcount_add(prev, pcount);
BUG_ON(tcp_skb_pcount(skb) < pcount); <= SACK panic
tcp_skb_pcount_add(skb, -pcount);

远程用户通过将 TCP 连接的 MSS 设置为最低限制 48 字节,并发送一系列特制的 SACK 数据包,就可能会触发此问题。最小 MSS 使得每个数据段仅余 8 个字节数据,由此增大了发送所有数据所需的 TCP 数据段个数。

多家云服务商紧急回应

与此同时,国内外多家云服务商发布公告,给予不同程度的建议和告警。

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

截图来自 AWS 官网

根据 AWS 的公告,Amazon ECS、AWS Elastic Beanstalk、Amazon Elastic Compute Cloud (EC2)、Amazon WorkSpaces (Linux) 等均进行了修复和升级,一直处于安全运行状态,用户可根据 AWS 建议的安全最佳实践(或需要操作系统修补程序以满足任何其他安全策略)进行操作。

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

截图来自阿里云官网

根据阿里云给出的公告,阿里云应急响应中心监控到国外某安全研究组织披露 Linux 内核 TCP SACK 机制存在缺陷,可导致远程拒绝服务。CVE 编号为 CVE-2019-11477(高危)、CVE-2019-11478(中危)和 CVE-2019-11479(中危),并给出安全修复建议(任意一种修复方式都有可能造成业务不可用),比如禁用 SACK 机制功能、升级 Linux 安全补丁 (需要重启服务器) 等(具体信息建议阅读官方公告)。

Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

截图来自腾讯云官网

根据腾讯云给出的公告腾讯云安全中心监测到 Linux 内核被曝存在 TCP “SACK PANIC” 远程拒绝服务漏洞(漏洞编号:CVE-2019-11477,CVE-2019-11478,CVE-2019-11479),攻击者可利用该漏洞远程攻击目标服务器,导致系统崩溃或无法提供服务。为避免业务受影响,腾讯云安全中心建议用户及时开展安全自查,如在受影响范围,请及时进行更新修复,避免被外部攻击者入侵。

腾讯云给出了目前的安全版本以及修复建议(建议阅读官网公告),各大 Linux 发行厂商已发布内核修复补丁,详细内核修复版本如下:

  • CentOS 6 :2.6.32-754.15.3
  • CentOS 7 :3.10.0-957.21.3
  • Ubuntu 18.04 LTS:4.15.0-52.56
  • Ubuntu 16.04 LTS:4.4.0-151.178
  • FreeBSD:腾讯云官方提供的 FreeBSD 镜像默认不受该漏洞影响,请放心使用。
Linux内核被曝TCP “SACK PANIC”漏洞,多家云服务商给出紧急修复建议

截图来自华为云官网

根据华为云给出的公告, 华为云提醒各位租户及时安排自检并做好安全加固。具体 处置方案如下:

  • 更新 Linux 安全补丁(修复后需重启):

    Ubuntu / Debian 版本:执行命令 sudo apt-get update && sudo apt-get install linux-image-generic,进行软件源更新并安装最新内核版本;

    Centos /RHEL 版本:执行命令 yum update kernel -y,更新当前内核版本。

  • 临时缓解措施:禁用 SACK 处理(会影响 TCP 连接处理效率),请在操作前评估对业务可用性的影响。

复制代码
sysctl -w net.ipv4.tcp_sack=0
echo "net.ipv4.tcp_sack=0" >> /etc/sysctl.conf

注意:修复漏洞前请将资料备份,并进行充分测试。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK