Unsafe Unzip with spring-integration-zip 分析-【CVE-2018-1261 与 CVE-2018-1263】

漏洞公告

https://pivotal.io/security/cve-2018-1261

关于 CVE-2018-1263 ，见补丁浅析部分。

漏洞分析

从简单的测试代码开始：

public final class Main {

    private static ResourceLoader resourceLoader = new DefaultResourceLoader();
    private static File path =  new File("./here/");
    public static void main(final String... args) {
        final Resource evilResource = resourceLoader.getResource("classpath:zip-malicious-traversal.zip");
        try{
            InputStream evilIS = evilResource.getInputStream();
            Message<InputStream> evilMessage = MessageBuilder.withPayload(evilIS).build();
            UnZipTransformer unZipTransformer = new UnZipTransformer();
            unZipTransformer.setWorkDirectory(path);
            unZipTransformer.afterPropertiesSet();
            unZipTransformer.transform(evilMessage);
        }catch (Exception e){
            System.out.println(e);
        }
    }
}

其中 zip-malicious-traversal.zip 即恶意的压缩包，结构如下：

unZipTransformer.setWorkDirectory(path); 设置了正常情况下解压目录为当前目录下的here文件夹，如上gif所示，在here文件夹中生成了good.txt。而evil.txt却逃逸出了这个限制，在G://tmp下生成了。

环境相关源码见附件。为了复现漏洞，需要在硬盘根目录下先创建一个tmp目录， zip-malicious-traversal.zip 在CVE-2018-1261\src\main\resources中。

跟踪代码，在 unZipTransformer.transform(evilMessage); 处打上断点跟入。当控制流到达 org/springframework/integration/zip/transformer/UnZipTransformer.java:112

ZipUtil.iterate(inputStream, new ZipEntryCallback() { ... });

这里会将inputStream输入， ZipEntryCallback 作为回调函数。跟入 iterate 至org/zeroturnaround/zip/ZipUtil.java。

public static void iterate(InputStream is, ZipEntryCallback action, Charset charset) {
    try {
      ZipInputStream in = null;
      if (charset == null) {
          in = new ZipInputStream(new BufferedInputStream(is));
      }
      else { ... }
      ZipEntry entry;
      while ((entry = in.getNextEntry()) != null) {
        try {
          action.process(in, entry);
        }
        ...
      }
    }
    ...
  }

在iterate中，通过 in = new ZipInputStream(new BufferedInputStream(is)); 生成了ZipInputStream对象 in ，此后通过 in.getNextEntry() 来获取对象in中的一个个条目。对于 getNextEntry() 而已，它会直接把目录给打印出来，具体可以参见 stackoverflow: How does ZipInputStream.getNextEntry() work? 。所以对于 zip-malicious-traversal.zip 而言

回到UnZipTransformer.java：

可以看到 entry 的值即为 ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp/evil.txt 。

此后调用回调函数process:

public void process(InputStream zipEntryInputStream, ZipEntry zipEntry) throws IOException {

    final String zipEntryName = zipEntry.getName();
    ...
    if (ZipResultType.FILE.equals(zipResultType)) {
        final File tempDir = new File(workDirectory, message.getHeaders().getId().toString());
        tempDir.mkdirs(); //NOSONAR false positive
        final File destinationFile = new File(tempDir, zipEntryName);

        if (zipEntry.isDirectory()) { ...   }
        else {
            SpringZipUtils.copy(zipEntryInputStream, destinationFile);
            uncompressedData.put(zipEntryName, destinationFile);
        }
    }
    ...
}

tempDir 是临时生成的文件夹，而 zipEntryName 通过 zipEntry.getName() 得到，即为 ../../../ 那一串。接着通过 final File destinationFile = new File(tempDir, zipEntryName); 确定解压目录，也正是这里造成了跨越目录漏洞。接着就是调用 copy 把数据写到destinationFile处。

究其原因，对于getNextEntry而言, ../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../../tmp 仅仅是目录名字，而对于copy操作而言， ../../../ 等将被解释为目录穿越操作从而造成了任意解压。

补丁浅析

1.0.1.RELEASE中的补丁 Disallow traversal entity in zip ，主要是在进行copy操作前，对zipEntryName进行了检查

final File destinationFile = new File(tempDir, zipEntryName);

    if (zipEntryName.contains("..") && !destinationFile.getCanonicalPath().startsWith(workDirectory.getCanonicalPath())) {
        throw new ZipException("The file " + zipEntryName + " is trying to leave the target output directory of " + workDirectory);
    }

对于恶意的压缩包，在生成了 destinationFile 后，假设值为 .\here\e401f4b8-0ecb-3f3a-76ce-5318b14d6000\..\..\tmp\evil.txt 时，通过调用 destinationFile.getCanonicalPath() 把 . 和 .. 解析成对应的正确的路径，获得它规范化的绝对路径。之后再与工作目录 workDirectory.getCanonicalPath() 比较来确定是否存在目录穿越。

之后，2018年5月11日pivotal又再次放出公告：

原因在于：

While the framework itself now does not write such files, it does present the errant path to the user application, which could inadvertently write the file using that path.

也就是说，生成的 destinationFile 其实是错误的，尽管框架本身不会有问题不会出现目录遍历漏洞，但是对于应用而言，可能之后直接使用了 destinationFile 这个路径来进行操作从而导致错误。因此在1.0.2.RELEASE版本中的补丁中 [Dissallow traversal entry even for byte[] ，直接在生成 destinationFile 时做了检查：

final File destinationFile = checkPath(message, zipEntryName);

除此之外，在 Remove unnecessary check for the .. 中还将 zipEntryName.contains("..") 的判断删除，因为认为是不必要的。

漏洞考古

类似的压缩文件目录遍历漏洞以前也出现不少，列举几个。

• 安卓：三星默认输入法远程代码执行
  
• Python：Exploiting insecure file extraction in Python for code execution
  
• GNU tar 解压路径绕过漏洞