The security vulnerability in the Java reflection library was fixed 30 months later.

The security vulnerability in the Java reflection library was fixed 30 months later.

On June 25, July 2013, Security organization Security Events discovered a Security vulnerability in Java 7u25, which allows attackers to completely get rid of the Java sandbox. Oracle included a patch in the updated 7u40, but according to Security submissions earlier this year, the patch was only conceptually corrected. After slightly modifying the code, this vulnerability can still be exploited. In addition, subsequent studies showed that the vulnerability was even more serious than originally reported. After the issue was made public, Oracle released a patch as part of the 8u77.

This vulnerability can be found in the new reflection library, which can be used after Java 7. More specifically, it is used to dynamically access and call methods using the new MethodHandle class. It depends on how different ClassLoader load classes. To understand this problem, some basic knowledge is required. This knowledge involves the Java ClassLoader working method, because class loading is one of the fields that everyone knows at least in Java, therefore, before explaining this issue, we will first outline this concept.

Java ClassLoader

Java can dynamically load code from various sources at runtime. This function is implemented through a series of special classes named ClassLoader. The standard Java implementation provides multiple ClassLoader to load classes, which can be loaded from a file system, URL, or compressed file, however, Java also provides developers with the ability to create custom ClassLoader to meet Personalized Requirements. A common way to interact with ClassLoader is to call its loadClass (String) method. This method will accept the Class name. If it can be found, it will return the relevant Class object, if no exception is found, the ClassNotFoundException exception will be thrown. Every class in a Java application is loaded using a ClassLoader in this way.

By setting the parent ClassLoader, these different ClassLoader can be connected to each other to form a hierarchical structure. If the parent ClassLoader is not set, the parent ClassLoader will be set to the class loader that loads the ClassLoader by default (the ClassLoader itself is also a class, so you also need to load it through a ClassLoader ). If the parent ClassLoader is provided, the default behavior of the ClassLoader is to delegate the task of loading the requested class to its parent loader, only the parent loader (or grandfather loader) when the class cannot be loaded, the ClassLoader will attempt to load the requested class. However, the creator of the custom loader does not have to follow this default behavior. They can choose to implement different behaviors.

When a Java application is started, the following ClassLoader will play a role in order:

1. Bootstrap ClassLoader: A Part Of The JVM itself. Therefore, its implementation is unique in every JVM. This ClassLoader does not have a parent ClassLoader. It is used to load the core classes under the java. lang package.
2. Extension ClassLoader: loads classes in the Extension library, which may vary in each Java installation environment. Extension ClassLoader loads all content in the path specified by the java. ext. dirs variable.
3. Application ClassLoader: loads the main class of the Application and all classes located in the Application class path.
4. Custom ClassLoader: All other ClassLoader used in the application. It is optional and may not exist depending on the application.

During runtime, using a custom ClassLoader to dynamically load classes creates the possibility for many applications. Otherwise, some functions may not be implemented, but unfortunately, it also causes many security problems, especially in class impersonation. Theoretically, developers can create a custom ClassLoader to load a simulation implementation of the original class java. lang. Object and use this custom Object in the application. This may cause security problems in two aspects: This custom object can access java. class content visible within the range of all packages in the lang package. Secondly, this custom Object will be treated as a standard Object by JVM, therefore, it will be used as a trusted class implemented by Java.

To protect Java against these security issues, Java classes must identify three attributes: Class Name, package, and ClassLoader reference. If two different classes have the same class name and package name but are loaded by different ClassLoader, Java considers them to be unequal and assigns values between them, classCastException will occur. In this way, the environment will be protected from Counterfeited attacks.

Partially repaired and the resulting vulnerabilities

Security configurations first reported this vulnerability and categorized it as a CVE-2013-5838, which can be described as the class of the called Method when calling the Method through Method Handle, its ClassLoader is not checked, which means that attackers can perform class counterfeiting according to the method described above.

Shows the sample code of the original vulnerability. The ClassLoader of the target class is not checked. Source: Security events.

Oracle provided an amendment in September 2013. As part of Java 7u40, it includes the class visibility check. It compares the expected type with the passed-in type ClassLoader. The comparison method is as follows:

• If the two ClassLoader are the same, the two types are fully compatible according to the definition;
• If one ClassLoader is the parent loader of another ClassLoader, it considers the two classes to be loaded through the normal ClassLoader hierarchy, so it is considered safe to regard them as equal.

In the second check, Security configurations found that a slight modification to exploit may continue to be valid. First, the custom ClassLoader used to simulate classes sets the target ClassLoader as its parent class loader, which can be set through the API as a parameter:

URLClassLoader lookup_CL = URLClassLoader.newInstance(urlArray, member_CL);

This mechanism uses the custom ClassLoader as a part of the hierarchical structure. Source: Security configurations.

Then, because the default behavior of ClassLoader is to delegate the class loading task to its parent loader, attackers need to ensure that the parent ClassLoader cannot be loaded to this class, in this way, their custom ClassLoader can play a role. Using Java to load classes through network methods, this attack mode is confirmed: If this class is defined by URL location, the parent ClassLoader tries to connect to the relevant server and obtain the code of this class. At this time, the pre-built HTTP server can return the 404 not found error, causing the parent ClassLoader to fail to load this class, therefore, the control is transferred to the custom ClassLoader.

Use a custom HTTP server to force the parent ClassLoader to load the code stream after the class fails. Source: Security events.

When this vulnerability was reported again in March 2016, the latest available version was 8u74, which proved to be vulnerable and was corrected by Oracle in 8u77. However, in the 8u77 release notes, this vulnerability is still described as "it will affect the desktop device. The JavaSE [and] running in the Web browser will not affect the Java deployment environment, for example, a typical server or independently deployed desktop application ", but it turns out that it still affects server configuration and the Java environment of Google App Engine.

Amendment: December 1, April 29, 2016

This article mistakenly believes that this vulnerability still exists in versions 8u77, 8u91, and 8u92. In fact, it has been corrected in 8u77. In the 8u77 release notes, it is described as a fix to the CVE-2016-0636, specifically described as "unspecified vulnerabilities [...] with the unknown infected content in the Hotspot child component "and does not include a clear reference to the CVE-2013-5838 mentioned in this article. However, Security configurations points out that the CVE-2016-0636 is a CVE number for Issue 69, and Issue 69 is a way for them to represent their original CVE-2013-5838. (In the comment area of the original English text, this article discusses the process of solving the problem. Interested readers can view the problem in the original text. -- Translator's note)

Vulnerability in Java Reflection Library Fixed after 30 Months

This article permanently updates the link address: