JDK 8u20反序列化漏洞利用分析<\/h1>

漏洞背景<\/h2>

JDK 8u20反序列化漏洞是对7u21漏洞的一种绕过利用方式，主要利用了Java序列化机制中的两个关键特性：<\/p>

双层try\/catch结构<\/li>

TC_REFERENCE机制<\/li> <\/ol>

核心利用原理<\/h2>

1. 双层try\/catch机制<\/h3>

基本原理<\/strong>：<\/p>

当内层try块抛出异常时，如果外层catch能够捕获该异常类型，程序不会立即终止<\/li>
外层catch如果没有再次throw，程序可以继续执行后续代码<\/li> <\/ul>
在漏洞中的利用<\/strong>：<\/p>

AnnotationInvocationHandler#readObject<\/code>中先执行s.defaultReadObject()<\/code>，然后才进行type判断<\/li>
利用双层try\/catch可以让AnnotationInvocationHandler<\/code>对象被还原，即使type判断后的代码无法执行也不影响利用<\/li> <\/ul> 2. TC_REFERENCE机制<\/h3> 基本原理<\/strong>：<\/p> Java序列化\/反序列化会为每个对象分配一个Handler值（类似索引）<\/li> 当同一个对象被多次引用时，后续引用会直接使用第一次生成的Handler值<\/li> <\/ul> 示例说明<\/strong>：<\/p> Foo f =<\/span> new<\/span> Foo();<\/span> <\/span><\/span>oos.<\/span>writeObject<\/span>(<\/span>f);<\/span> <\/span><\/span>oos.<\/span>writeObject<\/span>(<\/span>f);<\/span> \/\/ 这里第二个f会存储第一个f的Handler <\/span><\/span><\/span><\/code><\/pre>Handler值规则<\/strong>：<\/p> 第一个Handler值为0x7E0000<\/code>（十进制8257536）<\/li> 后续每个新Handler值递增1（第二个为8257537，以此类推）<\/li> <\/ul> 利用链构造<\/h2> 关键组件<\/h3> BeanContextSupport<\/strong>：<\/p> 其readObject()<\/code>调用了readChildren(ois)<\/code><\/li> 内部的catch块满足双层try\/catch条件<\/li> 可以包裹AnnotationInvocationHandler<\/code>对象<\/li> <\/ul> <\/li> TemplatesImpl<\/strong>：<\/p> 用于hash碰撞，与7u21利用方式相同<\/li> <\/ul> <\/li> Proxy对象<\/strong>：<\/p> 代理类与BeanContextSupport<\/code>包裹的是同一个对象<\/li> <\/ul> <\/li> <\/ol> 利用步骤<\/h3> 让BeanContextSupport<\/code>包裹AnnotationInvocationHandler<\/code>对象并放在第一位<\/li> TemplatesImpl<\/code>放在第二位，用于hash碰撞<\/li> Proxy<\/code>放在第三位，代理类与BeanContextSupport<\/code>包裹的是同一个对象<\/li> <\/ol> 执行流程<\/strong>：<\/p> 先反序列化BeanContextSupport<\/code>对象，还原AnnotationInvocationHandler<\/code><\/li> Proxy通过Handler调用已还原的AnnotationInvocationHandler<\/code>对象<\/li> 后续流程与7u21相同<\/li> <\/ol> 问题分析与解决<\/h2> 报错问题分析<\/h3> 报错现象<\/strong>：<\/p> 反序列化时出现readInt()<\/code>报错<\/li> 根源在于readBlockHeader()<\/code>返回-1导致in.read()<\/code>为-1<\/li> <\/ul> 深层原因<\/strong>：<\/p> defaultDataEnd<\/code>标志：<\/p> 当类没有writeObject()<\/code>方法时，defaultDataEnd = true<\/code><\/li> 但这不是根本原因，因为测试发现没有writeObject()<\/code>的类也能正常反序列化<\/li> <\/ul> <\/li> 关键问题：<\/p> AnnotationInvocationHandler<\/code>的readObject<\/code>报错导致退出<\/li> 未能执行defaultDataEnd = false<\/code>的重新赋值<\/li> 导致readInt()<\/code>报错<\/li> <\/ul> <\/li> <\/ol> 解决方案<\/strong>：<\/p> 修改flags<\/code>从0x02<\/code>改为0x03<\/code>（添加SC_WRITE_METHOD<\/code>标志）<\/li> 删除序列化数据中的null值，确保数据对齐<\/li> <\/ul> 数据对齐问题<\/h3> 为什么删除null值<\/strong>：<\/p> 序列化数据中： TC_NULL<\/code>对应null值<\/li> TC_BLOCKDATA<\/code>对应int值<\/li> <\/ul> <\/li> 需要让TC_BLOCKDATA<\/code>提前<\/li> 删除TC_NULL<\/code>不会影响后续反序列化，因为： readInt()<\/code>标志着BeanContextSupport<\/code>反序列化结束<\/li> 紧接着要反序列化下一个对象（TemplatesImpl<\/code>）<\/li> <\/ul> <\/li> <\/ol> 完整POC构造<\/h2> 关键点<\/strong>：<\/p> 使用BeanContextSupport<\/code>包裹AnnotationInvocationHandler<\/code><\/li> 设置TemplatesImpl<\/code>用于hash碰撞<\/li> 使用Proxy代理同一个对象<\/li> 修改flags添加SC_WRITE_METHOD<\/code><\/li> 删除序列化数据中的null值确保对齐<\/li> <\/ol> JDK 8u20修复<\/h2> 修复方式：<\/p> 限制反射调用的方法，只允许以下三种： equals<\/code><\/li> hashCode<\/code><\/li> toString<\/code><\/li> <\/ol> <\/li> 这样就不能调用危险的sink点方法<\/li> <\/ul> 调试技巧<\/h2> 序列化数据分析<\/strong>：<\/p> 使用工具如zkar或SerializationDumper<\/li> 关注@ObjectAnnotation<\/code>和@ClassDescFlags<\/code><\/li> <\/ul> <\/li> 定位问题<\/strong>：<\/p> 通过前后pos<\/code>值的变化定位序列化数据中的位置<\/li> 关注defaultDataEnd<\/code>标志的变化<\/li> <\/ul> <\/li> 异常跟踪<\/strong>：<\/p> 注意异常抛出后是否会进入catch块<\/li> 确保外层catch能捕获内层抛出的异常类型<\/li> <\/ul> <\/li> <\/ol> 总结<\/h2> JDK 8u20反序列化漏洞利用了两个关键机制：<\/p> 通过双层try\/catch绕过AnnotationInvocationHandler<\/code>的type检查<\/li> 利用TC_REFERENCE机制复用已反序列化的对象<\/li> <\/ol> 成功利用需要：<\/p> 精心构造的序列化数据<\/li> 正确处理数据对齐问题<\/li> 理解Java序列化\/反序列化的内部机制<\/li> <\/ul> 通过深入分析序列化数据和调试，可以完全理解漏洞利用的每个细节，包括为什么需要删除某些数据以及如何确保利用链的完整执行。<\/p>