4个月前写了一篇文章叫《从代码层面理解java的00截断漏洞》，由于当时出差新疆没时间深入，便在文末立了个有空继续深入的flag。今天我们通过跟踪jdk代码， 彻底搞清楚java中00截断的原理，以及它之后版本是如何修复的？
一、漏洞测试代码改进
看了一些java web系统文件上传代码，基本都是使用FileOutputStream来实现对上传内容的保存。于是将上篇文章的测试代码修改如下，简单模拟java的文件上传。
通过在漏洞版本和非漏洞版本运行以上代码，可知如果00截断成功，则会在系统的c盘根目录新建一个内容为Test by c0ny1的shell.jsp，如果没有截断成功，则抛出Invalid file path异常。
二、漏洞是如何产生的?
我选择使用JDK1.7.0（JDK1.7第一个版本），来跟踪漏洞测试代码从运行到触发。
将传进来的name参数作为路径，新建了File对象，再次传入到FileOutputStream对象新的构造函数。根据传入的两个参数的类型，我们可以确定会进入到以下这个构造函数。
FileOutputStream对象的构造方法又调用了open函数，打开了name参数传进来的文件路径，我们继续跟进open函数。
发现open函数是一个native method。它的实现体是由非java语言（c语言）实现的。只能去OpenJDK官网下载jdk源码来查看它的实现。无奈没有找到jdk7u1的源码，只找到了jdk7u75的源码。其实在小版本上源码应该区别不大。
openjdkjdksrcwindowsnativejavaioFileOutputStream_md.c找到了FileOutputStream类的open方法的JNI实现。open方法又调用了fileOpen方法，继续跟进fileOpen方法。
在io_util_md.c中找到了fileOpen方法的定义。
fileOpen方法调用了winFileHandleOpen函数，继续跟进。由于winFileHandleOpen函数代码比较多，这里精简出了关键代码。
通过阅读以上代码，可知如果在Windows NT/Windows 2000平台下会调用pathToNTPath函数将原始文件路径转化为Windows NT系统合法路径。然而通过阅读该方法源码，发现它并没有对 0字符串进行过滤。如果在其他Window操作系统版本下，则直接使用原始文件路径。
按照winFileHandleOpen方法的逻辑，无论如何最终都是调用了CreateFileW这个Windows API函数来创建文件。由于这个过程中均未对 0字符串进行过滤，如果传入的文件路径带有 0字符，则CreateFileW函数在创建文件时，路径会被截断。这没什么好说的。
这里我们没法继续跟进CreateFileW函数，毕竟Windows不开源。为了文章的严谨性，这里我用C语言写一个demo，来证明该函数可以截断。
代码运行演示如下：
三、漏洞是如何修复的？
这里选择使用jdk1.7.0_80（JDK1.7最新版本），来观察漏洞如果被修复的。
我们继续按照原来漏洞触发的调用链重新跟踪一遍，跟踪到第二构造函数时，发现多了一个针对文件路径的检查，若检查结果为非法，则抛出异常Invalid file path.
继续跟进，来到java.io.File类的isInvalid方法,发现该检查函数判断了路径中是否包含00字符串。（注意：java默认编码为Unicode，00字符串的Unicode编码为u0000）。
四、漏洞影响的版本范围
我们知道jdk1.7版本是部分版本存在漏洞的。但这里我们需要确定是哪个版本修复了这个漏洞。翻阅了JDK1.7多个版本代码，发现在JDK1.7.0_40（7u40）开始加上了对文件名是否存在 0字符的检查。也就是说 JDK1.7.0_40之前java是存在00截断的，而之后的版本就不存在了！
后面在官网的JDK 7u40的更新日志中也找到了关于00截断问题Bug ID，分别为JDK-8003992和JDK-8011539，具体链接放在了文末的参考文章里了。其实这两个是同一个Bug，官网也说明了它们重复了。
五、参考文章
-
JAVA /00文件路径截断漏洞与分析for windows并对.NET比较
-
JDK-8003992: File and other classes in java.io do not handle embeddednulls properly
-
JDK-8011539: File APIs Should Not Allow Null Bytes
本文始发于微信公众号（回忆飘如雪）：【第1周】从代码层面理解java的00截断漏洞深入篇
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论