Abstract
Invalid object initialization vulnerabilities have been identified since the 1990s by a research group at Princeton University. These vulnerabilities are critical since they can be used to totally compromise the security of a Java virtual machine (JVM). Recently, such a vulnerability identified as CVE-2017-3289 has been found again in the bytecode verifier of the JVM and affects more than 40 versions of the JVM. In this paper, we present a runtime solution called MUSTI to detect and prevent attacks leveraging this kind of critical vulnerabilities. We optimize MUSTI to have a runtime overhead below 0.5% and a memory overhead below 0.42%. Compared with state of the art, MUSTI is completely automated and does not require to manually annotate the code.
Highlights
W HEN the Java language was introduced in the mid1990’s, it was thought that the language is more secure than C/C++ because it does not allow to directly manipulate the memory – it uses a garbage collector instead – and because array bounds are automatically checked at runtime
As far as we know, this kind of vulnerability currently mainly affects all implementations of the Java virtual machine such as Oracle’s OpenJDK, IBM’s J9 [4] or Excelsior JET [3] as well as all applications running on top of the VM allowing “untrusted code” to run in the sandbox
The main goal of MUSTI is to prevent attacks based on invalid object initialization
Summary
W HEN the Java language was introduced in the mid1990’s, it was thought that the language is more secure than C/C++ because it does not allow to directly manipulate the memory – it uses a garbage collector instead – and because array bounds are automatically checked at runtime. Our approach aims at improving the Java virtual machine to prevent invalid object initialization vulnerabilities from being exploited at runtime. The approach makes sure that objects created by the security sensitive operation do not flow back to the user context This prevents, in our example, an analyst from using a class loaded by a security sensitive operation. 3289 – an invalid object initialization vulnerability – is studied in this paper This kind of vulnerability is critical as it allows an analyst to completely bypass the Java sandbox. Researchers have already developed an approach to tackle this kind of vulnerability [29] It requires to manually annotate the code which makes it difficult to use when the code is in constant evolution as is the case for the JCL and the JVM.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
