XStream CVE-2019-10173 vulnerability analysis

Preface

First NOSEC

This vulnerability is "bypassed" by the patch of CVE-2013-7285.

This is a very fascinating hole. The POC is the same as CVE-2013-7285. The Poc is available on XStream <=1.4.6 and 1.4.10, which means that the vulnerability that began to be repaired later appeared.

**Tucao:** The version of the bug fix was released in October 2018 for 1.4.11, and the CVE number is 2019 ==

Official vulnerabilities such written (thanks Badcode master to remind, or still looking to bypass it):

This maintenance release addresses again the security vulnerability CVE-2013-7285, an arbitrary execution of commands when unmarshalling for XStream instances with uninitialized security framework. Only 1.4.10 uninitialized security framework was affected.

emm, 1.4.10 the vulnerability will take effect when the security framework is not initialized.

It can be seen from the ChangeLog of XStream :

1.4.7 added a security framework based on black and white lists, but did not provide default security configuration.

1.4.10 added the setupDefaultSecurity method to configure the default security configuration, but if you want to take effect, you have to call it ┓( ´∀` )┏.

Debugged code

Java code:

import com.thoughtworks.xstream.XStream;
import java.io.File;
public class main {
    
    
    public  static void main(String args[]){
    
    
        XStream xStream = new XStream();
        //XStream.setupDefaultSecurity(xStream);//1.4.10后可用，启用默认安全配置，此处先不使用
        xStream.fromXML(new File("1.xml"));
    }
}

1.xml file (POC of CVE-2013-7285):

<sorted-set>
    <dynamic-proxy>
        <interface>java.lang.Comparable</interface>
        <handler class="java.beans.EventHandler">
            <target class="java.lang.ProcessBuilder">
                <command>
                    <string>calc</string>
                </command>
            </target>
            <action>start</action>
        </handler>
    </dynamic-proxy>
</sorted-set>

analysis

In the XStream parsing process, each class that can be parsed needs to find a corresponding Converter. These Converters are defined during the construction of the XStream object (the following figure is a screenshot of version 1.4.6):

All Converters implement the Converter interface:

During the deserialization process, XStream calls canConvert in turn to find the corresponding Converter.

What handles java.beans.EventHandler in 1.4.6 is ReflectionConverter:

---

There is such a sentence in the Changelog of 1.4.7 :

java.bean.EventHandler no longer handled automatically because of severe security vulnerability.

java.bean.EventHandler will no longer be automatically processed due to security issues.

So when the version is switched to 1.4.7, Poc becomes invalid and the following prompt will appear:

There is no Converter specified by java.beans.EventHandler. Look at the 1.4.7 version of ReflectionConverter:

It can be seen that when the processed Class is java.beans.EventHandler, ReflectionConverter no longer considers it to be processed.

---

1.4.10 , we can find that when the setupDefaultSecurity is not used, Poc can play the calculator again , and the judgment about EventHandler in ReflectionConverter is missing:

Look at the content of setupDefaultSecurity here:

Added a bunch of whitelists, when calling setupDefaultSecurity, you can intercept this POC:

Unfortunately, it is not called by default, ┓( ´∀` )┏.

---

After 1.4.11, a new Converter class InternalBlackList has been added, which is in the same file as the XStream class. Both marshal and unmarshal will report errors directly (marshal is called during serialization and unmarshal is called during deserialization):

When registering Converters, the priority LOW of InternalBlackList is higher than VERY_LOW of ReflectionConverter, and it will be judged first.

So it can be seen that when the class name is java.beans.EventHandler, it will be assigned to the Converter for processing:

Finally, an exception was reported directly (security alert, deserialization refused):

Conclusion

The XStream hole is very fascinating. It is estimated that most people will not notice the call to setupDefaultSecurity when upgrading the library. After all, for a build tool like Maven, you can upgrade by simply changing the version number.

Personal feeling is such a process:

A new safety function was developed and it felt very awesome, so the old one was given.

However, the new security function is not turned on by default, causing the old hole to come out again. . .

After analyzing the feeling: