Xstream Deserializable Vulnerablity And Groovy（CVE-2 0 1 5-3 2 5 3-a vulnerability warning-the black bar safety net

The sequence of issues looks like in the recent outbreak of very frequently, recently there are friends asking me about this two-day outbreak of Xstream build deserialization vulnerabilities, the company recently very busy, but catch up on the weekend just take the time to see, in fact, this time of vulnerability, and before the JRE that deserialization vulnerability trigger conditions are substantially the same, but on the JRE that serialization nobody seems to attention, interested students can go to find about the JRE serialization, influence as much as 1 1 months I analyzed the Apache CommonsCollection of vulnerability. Well, back to the body. In the analysis of the Xstream vulnerabilities when found,XStream vulnerability lies at the root of the Groovy components of the problem, in fact, in 1 5 years when someone gives Groovy a a CVE-2 0 1 5-3 2 5 3 Bugs, but the online seems to not have too much detail, why this analysis XStream vulnerability when you mentioned Groovy that CVE as the vulnerability of the root from the CVE’s.
First to tell that Groovy CVE-2 0 1 5-3 2 5 3 vulnerability.
0x01 Groovy-CVE-2 0 1 5-3 2 5 3 vulnerability(impact range 1. 7. 0-2. 4. 3)
Online seemingly not for the vulnerability analysis, it is only through the cve connection to see specifically what the problem is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3253 the official DESCRIPTION is as follows:
The MethodClosure class in runtime/MethodClosure.java in Apache Groovy 1.7.0 through 2.4.3 allows remote attackers to execute arbitrary code or cause a denial of service via a crafted serialized object.
By the vulnerability described information, we know the problem probably appeared in the MethodClosure class,the class definition and the method of the following figure
!
The class description Represents a method on an object using a closure which can be invoked at any time,probably the meaning is constructed by a specified object and call methods of the Closure of instances and can at any time make the call. On the figure the red lines mark the method is the trigger to build a good object and the specified method of the function, we follow up to see if the method is ultimately how to perform.
!
By this method the comments can know the method of action is to call the specified object of the specified method, so the MethodClosure class in the constructor of two parameters of meaning for the owner representative to invoke a method object, method calls the method name, so we can construct a specific object in order to achieve to perform a specific function, our own custom objects and methods will eventually call the above Figure, the Red boxes mark a function for execution.
For example, for example, we want to MethodClosure to achieve the execution of the command function, then the code is as follows
MethodClosure mc = new MethodClosure(new java. lang. ProcessBuilder(“open”,“/Applications/Calculator. app”), “start”);
mc. call();
Note:here Call of call method will eventually call the doCall function, are interested can go to debugging.
So the above code can achieve code execution on the function of the function we basically got it worked out, then we come back to think, is this CVE is to say the following this function can be implementation specific code?
Now that we know how to build and trigger the related function resulting in the execution of the code, then we might as well go and find see what those function call the flawed function, by eclipse, we can easily see those places call a MethodClosure#call()function
!
As shown in the above figure, we can see the groovy. util. Expando class, hashcode and toString methods such as call. MethodClosure#call()function, and here engaged in the java guys should be more excited, here’s the hashCode()method to call the flawed function, the hashCode function is this CVE to compare the core of the place, first we need to know the hashCode function of the action, when two objects compared are equal, it will call the object’s hashCode and equals method for comparison, if the two methods returned consistent results, so that the two objects are equal, if the called object is not overridden hashCode and equals method, then calling the parent class of the default implementation.
Here understand the hashCode of the role, and then to talk about the HashMap’s put method,the method is defined as follows
!
Because Map is a key-value type data structure, so the Map collection does not allow duplicate key, so each in to collection to add the key-value pair will be to determine whether the key is equal, then in determining whether equal time would call the key of the hashCode method, if we carefully construct a groovy. util. The Expando object as the Map collection of the key, then the object is added into the set when it will trigger groovy. util. Expando hashCode method, thereby triggering our malicious code.
Understand the above knowledge, we then follow-up groovy. util. Expando#hashCode method to see how carefully constructed a moment to execute malicious code objects,as in the following figure
!
Here from the figure it can be seen that calling getProperties(). get(“hashCode”)method to implement custom hashCode, we only need to call setProperties(“hashCode”,Expando instance)to bind hashCode attribute for the achieve on the line, there hashCode must be a Closure or its sub-class will ultimately call the call function, the MethodClosure class is exactly the Closure of sub-class, so the combination of these two places, the malicious code will successfully trigger.
Says to by call Map#put method can trigger us to construct a good code, then someone might ask, and those scenarios will trigger the Map’s put method on deserialization when such a scene is still there, except this time the Xstream deserialization with java other deserialization class is likely to also have such a scene.
Given below using the code
!
0x02 XStream deserialization vulnerability

[1] [2] next