关于
这里将发布我对公开漏洞的分析,以及我的一些 1day 漏洞。
[ 公开漏洞分析 ]
- 就我个人而言,学习一个公开漏洞的最佳方式就是逐行理解它,直到我能完全掌握这个漏洞。我会发布其中一些(过度注释的 ;) )漏洞分析,希望其他人也能从中学习,也算是我为社区做点贡献。同时也是为了记录,因为随着时间的推移,这些东西会逐渐从我脑海中淡去。
CVE-2016-8655
CVE-2016-5342
mp3 版本
tty 版本
- 这是 freener 的 Android LPE 漏洞利用 的注释版本。
- arm32
- 堆溢出
- 该漏洞利用覆盖另一个对象中的对象指针。它使用 ret2dir 攻击,使被破坏的指针指向内核中一个可预测的固定地址,该地址存放着漏洞利用载荷。该利用技术绕过了 PXN 与 PAN。
CVE-2016-2434
- 这是 Jianqiang Zhao 的 Android LPE 漏洞利用 的注释版本。
- arm64
- 在任意地址清零 16 字节
- 该漏洞利用会清除一个有用的全局对象中的 16 字节,该对象位于内核中的固定地址。
- 全局对象中被破坏的对象指针引用了来自用户态的漏洞利用载荷。这类攻击在带有 PAN(或 PAN 模拟)的设备/内核上不会生效。
- 我尝试理解 extra_recipe 越狱。
- 我尤其对 kpp 绕过部分感兴趣。虽然有一些关于该主题的幻灯片能让我对绕过方式有一个模糊的印象,但我真的很想深入细节,看看代码内部到底发生了什么。
- 我还想了解越狱的最后组成部分(安装 Cydia 等)。
yalu102 (ViewController.m)
- 我注释了与实际漏洞相关的部分,以及它是如何被利用的。
- 我查看 yalu102 而不是原始漏洞利用的原因是,它的 port-feng-shui 技术看起来更简洁、更易于理解。
- 分析在 kpp 绕过之前停止。
- 我跳到这里是这里有更多关于各种数值偏移的信息。
- 另外,与 yalu102 只有一个目标文件不同,这里的 patchfinder.c 是完整的。
- cydia 部分有点不完整,所以我在 kpp 之后跳到了 cydia 分支。
- 试图理解在 tfp0 和利用后阶段之后,一个越狱所需的各种要素。
empty_list (sploit.c)
- 对 Ian Beer 的 empty_list 内核漏洞利用 的详细剖析。
- 它使用了惊人的技术,从非常弱的原语出发,构建出更强的 AAR,最终打造出一个完整的 task port。漏洞利用代码背后的 port magic 令人难以置信。而这一切仅基于一个 8 个 NULL 字节的堆溢出。绝对令人叹为观止。
- 我潦草地写下了一些提高可靠性的朴素想法。希望将来有人能发布一个更可靠的漏洞利用版本。:)
- 感谢 Ian Beer 提供这个惊人的漏洞利用!
CVE-2018-4233
- 这是 @niklas_b 的 iOS Webkit 漏洞利用 的注释版本。
- 非常感谢 kudima(@begger_dd) 提供的清晰简洁、注释详尽的 writeup!:)
- 该 writeup 解释了 JIT 类型混淆漏洞、装箱/拆箱转换的一些限制(这可能导致不可靠性),以及如何构建早期/后期 AAR/AAW 原语的详细演示。他还对最新一轮缓解措施(索引掩码、ArrayBuffer 后备存储投毒、W^X JIT 机制的一些变更、JSObject 结构的变化等)之后利用技术的变化提供了见解。
jsc_ConcatMemcpy_infoleak
- 这是 kudima 的 WebKit 信息泄露漏洞利用(于 2018.8.27 修复)的注释版本。
- 它源于 lokihardt 报告的某个漏洞的不完整修复。lokihardt 报告中的补丁修复了 Double -> Object 类型混淆原语,但没有反过来修复;即 Object -> Double。
- 它用包含单个对象和标记的 butterfly 喷射 WebKit 堆,随后触发 concat 漏洞,并用未初始化的堆数据填充多个 double 数组的大部分区域。它遍历这些由有漏洞的 concat 产生的未初始化 double 数组,直到找到之前喷射的对象的地址并将其泄露。
- 再次感谢 kudima(@begger_dd) 提供的优秀漏洞利用和 writeup!:)
jsc_prop_enum_uaf
- 这是来自 kudima 的另一贡献。这是 kudima 的 WebKit 远程代码执行漏洞利用(在此提交中修复)的注释版本。它在 iOS 12.1 中被修复,并适用于 iOS 12.0.1 及更早版本。
- 问题在于,在 baseline-jitted 的 forin 循环中执行代码时,你可以引入代码来释放支撑 JSObject 的 StructureID 对象并触发垃圾回收器,但垃圾回收器不会标记 "JSPropertyNameEnumerator->m_cachedStructureID" 成员,因此 "JSPropertyNameEnumerator->m_cachedStructureID" 所指向的 StructureID 对象会在清除阶段被释放,从而导致悬空指针。
- 在 StructureID 对象被 GC 释放后,你可以引入代码创建一个新的 StructureID 对象,该对象会占用之前被释放的 "StructureID 对象" 槽位。
- 通过释放对象 A 的 StructureID,然后让对象 B 创建一个新的 StructureID 来取而代之,就可能造成类型混淆的情况,因为 "JSPropertyNameEnumerator->m_cachedInlineCapacity" 被设置为对象 A 的内联属性大小,而 "JSPropertyNameEnumerator->m_cachedStructureID" 却指向代表对象 B 的新 Structure ID 对象。这会使 'op_get_direct_pname' 中的检查通过,并让对象 B 越界访问其内联属性。
- 这可以被滥用来构建更强的原语,如 AAR/AAW,并进一步用于执行任意代码。
- 感谢 kudima(@begger_dd) 提供的酷炫漏洞利用和非常详细的 writeup!:)
[ 1Day ]
CVE-2017-2547
- 有一天,在 singi 的漏洞利用 于 Zer0con 2018 上展示后,我看了看它,并决定改进它。
- 这是在我将其集成到 pwnjs 之前的一个独立版本漏洞利用。
- 改进包括:
- 提高了可靠性(在内存被污染的大量浏览会话后仍能完美运行)
- 移除了所有硬编码偏移,使其兼容各种浏览器版本
- 使用了不同的利用技术(标准的 misalign 技术)
- 最终通过创建一个 webkit 原型将其集成到 pwnjs 框架中
- 使代码可读性大大提高,并添加了大量注释
- 特别感谢
- qwertyoruiop & Samuel Grob 提供的惊人 phrack 文章和公开漏洞利用
- Brian Pak & Andrew Wesie 提供的出色 pwnjs 框架!