CVE-2016-1000031 Apache Commons FileUpload 反序列化漏洞深入分析

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/raintungli/article/details/56008382

反序列化漏洞最近一直不得安宁,先有Apache Commons Collections通过反序列化实现远程代码执行,再有Spring RMI 反序列化漏洞,最新又有了common upload file的反序列化漏洞CVE-2016-1000031(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1000031)

漏洞原因

先来看DiskFileItem.java 代码
    /**
     * Reads the state of this object during deserialization.
     *
     * @param in The stream from which the state should be read.
     *
     * @throws IOException if an error occurs.
     * @throws ClassNotFoundException if class cannot be found.
     */
    private void readObject(ObjectInputStream in)
            throws IOException, ClassNotFoundException {
        // read values
        in.defaultReadObject();

        /* One expected use of serialization is to migrate HTTP sessions
         * containing a DiskFileItem between JVMs. Particularly if the JVMs are
         * on different machines It is possible that the repository location is
         * not valid so validate it.
         */
        if (repository != null) {
            if (repository.isDirectory()) {
                // Check path for nulls
                if (repository.getPath().contains("\0")) {
                    throw new IOException(format(
                            "The repository [%s] contains a null character",
                            repository.getPath()));
                }
            } else {
                throw new IOException(format(
                        "The repository [%s] is not a directory",
                        repository.getAbsolutePath()));
            }
        }

        OutputStream output = getOutputStream();
        if (cachedContent != null) {
            output.write(cachedContent);
        } else {
            FileInputStream input = new FileInputStream(dfosFile);
            IOUtils.copy(input, output);
            dfosFile.delete();
            dfosFile = null;
        }
        output.close();

        cachedContent = null;
    }
DiskFileItem里面封装了反序列的方法,在反序列化的方法里
1. 序列化中的数据可以保存在服务器的临时文件中
2. 复制服务器的文件到临时文件
3. 删除服务器的文件

   
    private transient DeferredFileOutputStream dfos; 
    public OutputStream getOutputStream()
        throws IOException {
        if (dfos == null) {
            File outputFile = getTempFile();
            dfos = new DeferredFileOutputStream(sizeThreshold, outputFile);
        }
        return dfos;
    }
dfos 是不可序列化的,反序列化中dfos为空,只能获取临时文件
    protected File getTempFile() {
        if (tempFile == null) {
            File tempDir = repository;
            if (tempDir == null) {
                tempDir = new File(System.getProperty("java.io.tmpdir"));
            }

            String tempFileName = format("upload_%s_%s.tmp", UID, getUniqueId());

            tempFile = new File(tempDir, tempFileName);
        }
        return tempFile;
    }

也就是基于设置的repository 目录的临时文件

从风险角度来考虑
1. 复制到临时文件upload_UID_UniqueID.tmp
2. 可以删除任意有删除权限的文件,问题的风险性并不高

CVE的描述

CVE所提示的风险感觉定义不清楚
Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution
DiskFileItem中注入执行代码,也无法在反序列化的时候被执行,这个和collection的反序列化的漏洞的风险是完全不同的,不清楚为何描述成可以操纵执行远端代码,是否是只要是反序列化的漏洞就是可以执行远端代码?

JDK6下的风险

JDK7以上在Java的file相关的基础类中都做了空字符的保护,这也是在针对java的string 和 c char的结束方式不一致,在Java中文件的操作中使用String这种char 数组,而C中的char 是以空字符为结束符,所以java操作的文件中很容易通过注入空字符来操作完全不同的文件
比如Java File file = new File("/test/test.txt\0.jsp") 看起来再操作 test.txt\0.jsp 实际上在底层调用的(本质还是c读写文件)是在操作test.txt
在JDK7以后的版本File 里面会有一个判断是否有空字符的函数
final boolean isInvalid() {
        if (status == null) {
            status = (this.path.indexOf('\u0000') < 0) ? PathStatus.CHECKED
                                                       : PathStatus.INVALID;
        }
        return status == PathStatus.INVALID;
    }

而在很多关键操作中都会有isInValid 函数的判断,避免被注入空字符绕过风险,但是JDK6并没有进行防护,在JDK6是可以通过输入空字符串进行文件名控制。
1. 我们先看目录的空字符是否有机会注入,在readObject的代码中,我们看到了在判断目录的时候,对路径进行了空字符保护
 if (repository != null) {
            if (repository.isDirectory()) {
                // Check path for nulls
                if (repository.getPath().contains("\0")) {
                    throw new IOException(format(
                            "The repository [%s] contains a null character",
                            repository.getPath()));
                }
            } else {
                throw new IOException(format(
                        "The repository [%s] is not a directory",
                        repository.getAbsolutePath()));
            }
        }

2. 在文件名中我们看是否有机会注入空字符
String tempFileName = format("upload_%s_%s.tmp", UID, getUniqueId());

UID, getUniqueId 都是可以构造的,但只能构造upload_为前缀的文件名

3. 通过相对路径构建任意文件名

构建 设置UID = /../../anyfile\0

只要有upload_为前缀的目录存在,通过相对路径,可以生成任意文件,同时最后注入空字符,结束文件名。这样就可以在服务器端生产任意文件

生成任意文件前提
1. JDK6 以下的版本
2. 必须在系统里存在upload_为前缀的目录存在

显然形成这样的攻击,前提条件是苛刻的

其他的风险

Dos攻击

因为使用了 DeferredFileOutputStream ,可以设置一个超大的sizeThreshold(保存在内存里),设置一个系统里的超大文件dfosFile在反序列化时复制dfosFile 到DefferredFileOutputStream导致JVM OOM 

 删除任意可删除的文件

设置dfosFile 为任意文件,因为反序列化后,复制完后会删除dfosFile,这样达到删除任意文件的目的

通过上述分析,我们可以看到上传文件反序列化的问题,并没有什么高危操作,而且有些攻击还必须有场景配合。

APACHE的官方态度

Apache 目前给出几个方案
1. 不认为是问题
2. 去除DiskFileItem.java的反序列化功能,这显然遭到了反对
3. 和collection解决方案一样在添加个系统参数的开关,如果打开的话,才能进行反序列化,就好像如果你打开了开关,就必须自己校验当从外部非可信域传入的时候

目前还无选择结果

反序列化JVM的不作为

目前JVM在反序列化的时候,JVM无法通过沙箱设置反序列化的类的黑白名单,只确保的反序列化类是在class loader 能初始化的。
对反序列化的保护,目前常见的解决方案扩展ObjectInputStream,在resolveClass方法里进行类的黑白名单保护,但涉及到上层代码的改动。





阅读更多

没有更多推荐了,返回首页