CVE-2019-11477 SACK Panic漏洞利用分析

一到下大雨天就想做点什么有意思的。皮鞋不会进水，因为根本就没有皮鞋，自然也就不会湿…

疯子带着小小去旅游了，家里就剩我一个，所以自然也就回来继续工作咯，不然还能干什么。当然，这也不是工作，算自娱自乐吧。当我工作的时候，我感到充实，我将休息，又觉得空虚，不工作也不休息，只能随便玩玩了。

前面写了几篇关于CVE-2019-11477漏洞的利用手段，但是都不够直接，为什么说不够直接呢？因为这些过程往往过于复杂，序列中的每一个步骤都把人搞得晕头转向，但其实这些让人眼花缭乱的东西是可以分离出去的。

本文提供一个干净清爽的方法。不再注入ICMP Need Frag，而是直接将mss协商成48。

先说下这些眼花缭乱的东西包括：

如何诱导被攻击侧增窗并发送18个分散/聚集的整32KB的frag page。
如何中途将mss改成最小值48字节。
如何将raw data的mss凑成8字节。

其中，第一个还是相对容易的，现如今下载服务器发送大文件都是这种方式发送的，你可以试下sendfile系统调用。

第二个前面的文章分散讲过，参见：
CVE-2019-11478 Sack Slowness&Excess Resource Usage漏洞解析与利用
链接是：https://blog.csdn.net/dog250/article/details/94654620
当然，这个条件只是可选，你完全可以一开始建连握手时的SYN报文就把mss协商成48字节，只是需要更大的拥塞窗口罢了，当然这个和SACK Panic本身无关，这是另一个话题，所以本文的假设也就是直接将mss在握手时就协商成48字节。

第三点，也容易，攻击者发送三个空洞数据即可让被攻击者发包时携带3个SACK段，然后加上时间戳和nop对齐，正好占据40字节options，剩余raw data的mss，不多不少，8字节。

好了，我们假设上述三点均已经满足(虽然它们不是那么容易满足，但是请试试看，并不难)，这样一来实施漏洞利用就超级简单了。

情况1：发送缓冲区存在一个17个frags组成的大skb的情况

现在，被攻击侧的发送缓冲区为：

接下来，攻击者构造SACK段：

此时，一个包含17个frag总长17×3276817\times 3276817×32768字节的skb被一次性SACK。

关键是第三步，攻击者再构造一个SACK段：

其中m1m_1m1，m2m_2m2，m3m_3m3满足下面的条件时，被攻击侧将gg：

m28>65535\dfrac{m_2}{8}>655358m2>65535。
m3>0m_3>0m3>0，m1>0m_1>0m1>0。
m1m_1m1，m2m_2m2合在一起小于17个frags。

这是因为内核将尝试将长度m2m_2m2的大skb的一部分和长度为m1m_1m1的skb进行合并，在合并过程中，在tcp_shift_skb_data中：

具体调到tcp_shifted_skb内部后，由于pconut参数已经大于了u16所能表示的最大值，就会在u16类型的gso_segs和pcount比较时BUG_ON。

非常清晰的一个过程，现在我们再回过头来反向推敲。

有几个问题：

如何满足17个32KB的frags拼接成一个大的skb？
如何保证大的skb前面有一个小的skb？

其实，上面的条件很难直接被满足，为什么呢？

如果我们看tcp_write_xmit这个正规的TCP发送函数，会发现几乎很难会让一个拥有17×327688\dfrac{17\times 32768}{8}817×32768个segs的skb一次被GSO发送出去，拥有各种限制，最终可能会调用tso_fragment将系统调用送来的满足攻击条件的大skb拆分成小的。我们看到，这个还和计算出来的pacing rate有关。

当然了，如果恰好有个服务器参数正好满足攻击条件，那太好不过了，如果不呢？

于是，我们可以换一种思路来间接满足。请问，我有说上面第一幅图的理想发送队列是被攻击侧自己形成的吗？没有啊！其实它也是被诱导形成的啊。

换句话说，即便诸多个skb是被拆分成小skb后一个个发出去的，我也能想办法将其合并成一个大的，就用SACK段合并的原理呗。

那就好办了，我们假设skb都是通过tso_fragment发送出去的，那又如何？注意到tso_fragment函数里只是split了一个skb，移动了frag page的position，offset指针而已，并没有拷贝数据到线性区域：

这意味着，分散聚集的frag page组成的skb是可以被重新合并起来的。

现在，我补上上文第一幅图之前的图。首先是初始，当拥塞窗口cwnd满足了攻击条件，即inflight字节至少为(17+2)×32768(17+2)\times 32768(17+2)×32768字节时的情景。

之所以要+2，是因为一个skb作为una，憋住发送队列，另一个用来做最后的合并，见前文。

接下来先来一波SACK，让从第三个开始的skb合并成一个：
在合并的过程中，gso_segs字段就已经溢出了，但这个方法中，我们不关注它的溢出，我只需要知道它不会超过65535即可，后面的BUG_ON来自于最后一个合并时，tcp_shifted_skb的参数pcount的值大于65535。注意pcount可是个int型哦，这是关键！

OK，这便和第一幅图接上了。

现在，我要吐槽下我自己几天前的方法了。简直太复杂了。简直就是炫技：

中间半途中塞入ICMP Need Frag后超时二分递减mss到达48。
为了重传重新SACK，竟然构建SACK reneg以便超时后全部Mark lost。
两次利用tcp_fragment来重新计算gso_segs，第一次溢出，第二次BUG。

本文的方法超级清爽，并没有直接让gso_segs溢出，而是让len8\dfrac{len}{8}8len超过65535字节，这办法好。

浙江温州皮鞋湿，下雨进水不会胖。

CVE-2019-11477 SACK Panic漏洞利用分析相关推荐

安装squid_CVE-2019-12527：Squid缓冲区溢出漏洞利用分析
报告编号:B6-2019-110702 报告来源:360-CERT 报告作者:360-CERT 更新日期:2019-11-07 0x00 背景描述 2019年8月22日,趋势科技研究团队发布了编号为C ...
TCP SACK panic漏洞的解释和思考
最近几天一直在和CVE-2019-11477 SACK panic漏洞进行纠缠,挺有意思的. 细节就不多说了,给出几个链接自己看吧: https://access.redhat.com/securit ...
php命令执行漏洞利用,ThinkPHP 5.0 5.1远程命令执行漏洞利用分析
1漏洞利用方式 5.0版本POC(不唯一) 命令执行:? s=index/thinkapp/invokefunction&function=call_user_func_array&v ...
Sack Panic漏洞TCP MSS机制(二)(together with myself)
没有一,哪有二? 其实已经有一了,不过不是我写的: Linux 内核 TCP MSS 机制详细分析 https://paper.seebug.org/966/ 作者原文几经update,终于上了点道, ...
CVE-2022-0185 价值$3w的 File System Context 内核整数溢出漏洞利用分析
文章目录 1. 漏洞发现 2. 漏洞分析 3. 漏洞利用方法1-任意写篡改 `modprobe_path` 3-1 泄露内核基址 3-2 任意地址写思路 3-3 FUSE 页错误处理 3-4 完整利用 ...
护卫神mysql提权_护卫神主机大师提权漏洞利用分析
*本文原创作者:Freedom,本文属FreeBuf原创奖励计划,未经许可禁止转载 0x01 前言护卫神·主机大师支持一键安装网站运行环境(IIS+ASP+ASP.net+PHP5.2-5.6+My ...
锐捷网管系统漏洞利用分析
利用此漏洞可获取后台密码现在复现 1.fofa搜索 title="RG-UAC登录页面" && body="admin" 2. 现在.查看源代 ...
攻击者对 Exploit-DB平台的利用分析
引言 **观点 4:截至 2020 年 11 月,NVD 平台公布的物联网相关漏洞数量已达 1541 个,有望创历史新高. 总体而言,相关漏洞具有攻击复杂度低.危害评级高的特点.从我们观察到的漏洞利 ...
Android提权漏洞CVE-2014-7920CVE-2014-7921分析
作者:没羽@阿里移动安全,更多技术干货,请访问阿里聚安全博客这是Android mediaserver的提权漏洞,利用CVE-2014-7920和CVE-2014-7921实现提权,从0权限提到me ...

CVE-2019-11477 SACK Panic漏洞利用分析

CVE-2019-11477 SACK Panic漏洞利用分析相关推荐

最新文章

热门文章