[原创]X浪的缓冲区溢出漏洞

X浪在处理本地图片时存在缓冲区溢出的漏洞，问题出现在Java_com_sina_filter_JpegExifExtractor_nativeExifExtrator函数，具体功能是解析JPEG格式的EXIF的信息。vsprintf 未做任何的过滤和校验，直接处理了传来的三个参数。printf_的调用方式s的大小为固定的65536，v5为图片的路径。这个漏洞似乎很好利用，直接设置超过65536大小的路径信息就可以了，但是设置路径时出现了问题，Linux查看文件名的默认的最大长度是255，路径的默认的最大长度是4096，远远没有达到我们需要的65536的长度。EXIF格式解析的地方，也大量调用了printf_函数。调用printf_的地方非常的多，随便找一个字段的值，将其设置为超过65536的长度就可以了。以Description的字段信息为例，使用Python生成包含EXIF信息的图片,发现EXIF头的最大大小是0xFFFF,正好位于s字段的最大长度限制内。 因为szSection只占2个字节，所以最大长度是0xFFFF,ImageDescription的长度可以设置为64993，但是仍然小于s[65536]的长度。这里也解释了为什么要设置s的最大长度为65536，这个正是EXIF信息的最大长度。继续分析发现了真正出现漏洞的地方是如下的代码：将Make (271) 和 Model (272) 的字段值进行了合并，正常的逻辑是EXIF内容的所有值加起来的最大长度是0xFFFF，似乎make加model的最大长度也不会超过0xFFFF。 Make的值可以设置为64995(0xFDE3)，这时Model值的正常长度是13(0xD)，合并后的长度是65008(0xFDF0)，显然是在0xFFFF的长度范围内。如果将Model的偏移地址和长度设置为与Make的偏移地址和长度一致，就可以突破0xFFFF的限制，长度可达129990(0x1FBC6)，同时可以控制Model的长度，来设置溢出的范围。同时s的地址是0x0005C05C,程序的最大地址是0x00072268,差值是0x1620C,可以向程序外溢出0x99BA。查看程序的segment表，可以向下溢出到bss段。 查看程序的防护，防护全开。首先覆盖的是位于其下方的DATA段的导出函数：EXPORT _ZN10__cxxabiv119__terminate_handlerE 与s值的结束地址相差0x8D，对内存破坏的影响最小，但是这是一个被动调用的函数，只有程序出现异常才有可能触发，另外即使触发也需要处理传递参数的问题。继续向下溢出到bss段，JNI调用出现了异常。出现异常的是以下的代码：dword_6C184和dword_6C188对应的参数是jclass和jmethodID:调用代码是：原始的逻辑是调用ExifInfo的构造函数创建Object对象，理论上可以替换jclass和jmethodID来构造指定的对象。然后是三个CallVoidMethod进行了对象函数的调用:CallVoidMethod函数的原始类型是:dword_6C18C dword_6C190 dword_6C194 对应的参数是jmethodID。对应的函数逻辑是:对应的JAVA代码是:至此，已经可以控制的参数是dword_6C184 dword_6C188，对应的是NewObject的jclass和jmethodID参数；
dword_6C18C dword_6C190 dword_6C194 对应的是三个CallVoidMethod的jmethodID参数。可以支持调用函数的参数类型为:仅在Unidbg的调试环境测试，与真机和系统版本有差异。int printf_(char *s, const char *format, ...)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-288734.htm

大佬 牛逼

谢谢分享

最后于 2025-10-17 17:12
被chenai2019编辑

，原因：

看看

又是不检验长度 哎

学习一下

可以的

好强

学习一下

学习一下

nb

nb

大佬牛逼