Debugging CVE-2018-1160 and Writing a 1-Day Exploit
原文英文，约900词，阅读约需3分钟。
📝
内容提要
本文讨论了CVE-2018-1160漏洞的调试与利用过程，分享了环境搭建的挑战、漏洞分析及利用策略，强调通过fork获取有效地址的重要性，最终实现了远程代码执行。
🔎
延伸解读
环境搭建的难点与取舍
文章指出环境搭建耗时约半天，最终采用基于libc版本的docker环境。作者提到内核版本难以解决，但认为内核仅影响mmap分配chunk的偏移，本地调试可忽略。这提示读者在复现漏洞时，应优先保证libc版本一致，而非纠结内核细节，以节省时间。
漏洞利用中的地址爆破思路
在ASLR启用环境下，作者利用fork子进程内存布局不变的特点，通过侧信道判断地址是否合法，从而暴力破解libc基地址。这种方法降低了ASLR的影响，但需要程序使用fork模型。读者可借鉴此思路，在类似场景中尝试侧信道爆破。
单次任意写实现RCE的策略
文章提到在已知libc版本和偏移后，利用一次任意写操作覆盖ld.so中的_rtld_global表，将_dl_load_lock覆盖为system，并控制rdi指向_dl_rtld_lock_recursive，两者相距0x600字节，可在一次写中完成。这展示了在限制条件下通过关键结构体实现代码执行的技巧。
❓
Q&A
CVE-2018-1160漏洞的调试过程耗时多久？
调试过程耗时约1.5天。
在调试CVE-2018-1160时遇到了哪些环境搭建的挑战？
环境搭建非常困难，特别是在解决内核版本和使用docker环境方面。
如何在启用ASLR的环境中获取libc基地址？
通过fork子进程获取libc基地址，并利用侧信道进行地址暴力破解。
CVE-2018-1160漏洞的利用策略是什么？
利用已知偏移量和gadget实现远程代码执行，通过覆盖特定内存地址获得控制权。
在CVE-2018-1160的漏洞分析中，如何确定可控的内存操作？
通过观察dsi->commands可以确定可控的内存操作，从而控制多个参数。
使用docker环境调试CVE-2018-1160的主要步骤是什么？
主要步骤包括基于libc版本修改docker环境，并在docker容器中运行调试。
🏷️
