G.O.S.S.I.P 阅读推荐 2023-01-06 UACatcher

#四大安全会议2023 8 个 #每日阅读推荐 181 个 #安全学术论文每日推荐 474 个 #S&P2023 2 个 #漏洞利用 4 个

进入到2023年，四大安全会议中的NDSS、IEEE S&P和USENIX Security都已经陆续录用了一批论文，我们今天就要为大家推荐一篇由浙大和CMU研究人员完成并发表在2023年IEEE S&P会议上的论文When Top-down Meets Bottom-up: Detecting and Exploiting Use-After-Cleanup Bugs in Linux Kernel

我们都很熟悉Use-After-Free（UAF）这种内存破坏型bug，可是你了解Use-After-Cleanup （UAC）类型的bug吗？本文关注的正是UAC bug在Linux内核中的存在与检测。我们通过上图来看看UAC bug的基本原理。首先，UAC bug和系统中特定的设备（device）的卸载（例如一个USB设备被用户拔出）相关，当一个特定的设备释放后，原来和这个设备相关的内存对象应该就不再有效了。然而，如果攻击者能抓住特定的时间窗口（race window），在设备释放前就开始启动相关内存对象访问，并能让这个操作“慢一点”，在设备释放后（相关内存对象也不再有效）再执行内存访问，就会产生和UAF漏洞攻击类似的效果。

注意到设备的卸载是从硬件层自底向上通知直至用户层，而用户态代码对设备资源的访问则需要透过syscall从上往下访问（这种访问模型见下图）。这两类（并发）事件如果撞到一起，就很容易产生concurrency bug，从而导致UAC相关问题的发生。

作者在本文中主要的工作，就是设计并实现了一个名为UACatcher的分析工具，用它自动化寻找代码（特别是Linux内核代码）中的UAC问题。下图中就是作者利用UACatcher发现的一个真实的UAC bug：

UACatcher在现实中针对Linux 5.11 (git commit 7289e26f395b) 内核版本进行了分析，发现了346个UAC bug，其中有277个得到了社区确认和修复，并拿到了15个CVE。

更重要的是，作者能够成功利用其中13个bug实施安全攻击，感兴趣的读者可以看看作者目前在他们的项目主页上放出的一个gif动画：

https://github.com/uacatcher/uacatcher-repo/blob/main/demo.gif

下面让我们仔细看看UACatcher究竟是怎么工作的。首先，UACatcher要借助Linux内核驱动的一些领域知识帮忙，分析和收集那些与设备相关的代码（下图中的Layer Preparing）；然后，UACatcher会寻找那些和特定设备相关的内存对象，并确定一个对象的 deallocation site 和 dereference site （作者称其为dPair），而定位这种dPair（下图中的dPairs Locating）对于寻找UAC bug是至关重要的；最后就是利用静态分析算法来确认某个dPair是否会导致UAC行为的发生。这部分工作的细节非常丰富，读者可以在论文的第四章中找到更多的有意思的内容。

可能有些读者会问，一个UAC bug的触发需要系统设备的卸载和释放作为前提，那么对于攻击者来说，这种利用条件是否就很苛刻呢？作者在第五章回答了这类疑问——通过一个真实的用户态可构造的“pseudoterminal device”，攻击者可以在无需真实物理设备且无需高权限的情况下，触发设备的释放（从而可能触发UAC bug）！