<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Garamond,Georgia,serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Hi,</p>
<p><br>
</p>
<p>My name is Aman and I am a PhD student at KTH Royal Institute of Technology, Stockholm, Sweden. I research as part of
<a href="https://chains.proj.kth.se/" class="OWAAutoLink">CHAINS</a> project to strengthen the software supply chain of multiple ecosystem. I particularly focus on runtime integrity in Java. In this email, I want to write about an issue I have discovered with
<i>dynamic generation of `java.lang.reflect.Proxy`classes</i>. I will propose a solution and would love to hear the feedback from the community. Let me know if this is the correct mailing-list for such discussions. It seemed the most relevant from
<a href="https://mail.openjdk.org/mailman/listinfo" class="OWAAutoLink">this list</a>.</p>
<p><br>
</p>
<p><b>My research</b></p>
<p><b><br>
</b></p>
<p>Java has features to load class on the fly - it can either download or generate a class at runtime. These features are useful for inner workings of JDK. For example, implementing annotations, reflective access, etc. However, these features have also contributed
to critical vulnerabilities in the past - CVE-2021-44228 (log4shell), CVE-2022-33980, CVE-2022-42392. All of these vulnerabilities have one thing in common -
<i>a class that was not known during build time was downloaded/generated at runtime and loaded into JVM.</i></p>
<p><br>
</p>
<p>To defend against such vulnerabilities, we propose a solution to <i>allowlist classes for runtime</i>. This allowlist will contain an exhaustive list of classes that can be loaded by the JVM and it will be enforced at runtime. We build this allowlist from
three sources:</p>
<ol style="margin-bottom:0px; margin-top:0px">
<li>All classes of all modules provided by the Java Standard Library. We use <a href="https://github.com/classgraph/classgraph" class="OWAAutoLink">
ClassGraph</a> to scan the JDK. </li><li>We can take the source code and all dependencies of an application. We use a software bill of materials to get all the data.</li><li>Finally, we use run the test suite to include any runtime downloaded/generated classes.</li></ol>
<div>Such a list is able to prevent the above 3 CVEs because it does not let the "unknown" bytecode to be loaded.</div>
<div><br>
</div>
<div><b>Problem with generating such an allowlist</b></div>
<div><b><br>
</b></div>
<div>The first two parts of the allowlist are easy to get. The problem is with the third step where we want to allowlist all the classes that could be downloaded or generated. Upon running the test suite and hooking to the classes it loads, we observer that
the list consists of classes that are called "<span>com/sun/proxy/$Proxy2</span>", "<span>jdk/internal/reflect/GeneratedConstructorAccessor3</span>" among many more. The purpose of these classes can be identifed. The proxy class is created for to implement
an annotation. The accessor gives access to constructor of a class to the JVM.</div>
<div><br>
</div>
<div>When enforcing this allowlist at runtime, we see that the bytecode content for "<span>com/sun/proxy/$Proxy2</span>" differs in the allowlist and at runtime. In our case, we we are experimenting with
<a href="https://github.com/apache/pdfbox" class="OWAAutoLink">pdfbox</a> so we created the allowlist using its test suite. Then we enforced this allowlist while running some of its subcommands. However, there was some other proxy class say
<span>"com/sun/proxy/$Proxy5" at runtime that implemented the same interfaces and had the same methods as "<span>com/sun/proxy/$Proxy2" in the allowlist. They only differed in the name of the class, order of fields, and types for fields references. This could
happen because the order of the loading of class is workload dependent, but it causes problem to generate such an allowlist.</span></span></div>
<div><span><span><br>
</span></span></div>
<div><span><span><b>Solution <br>
</b></span></span></div>
<p><br>
We propose that naming of subclasses of "<span>java/lang/reflect/Proxy</span>" should not be dependent upon the order of loading. In order to do so, two issues can be fixed:</p>
<ol style="margin-bottom:0px; margin-top:0px">
<li><span style=""><a href="https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531" class="OWAAutoLink">The naming of the class should not be based on AtomicLong</a></span><a href="https://github.com/openjdk/jdk/blob/4083255440cfbf39b9683ea88a433d71ec6111e7/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531" class="OWAAutoLink"></a>.
Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.</li><li>Methods of the interfaces must be in a particular order. Right now, <span style="">
</span><span style=""><span style=""></span></span><a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178" class="OWAAutoLink"><span style=""><span style="">they are not sorted in any particular orde</span>r</span></a>.<br>
</li></ol>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div id="m_4935352394101912768Signature">
<div name="divtagdefaultwrapper"><font size="2" color="#808080"><span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)"><span id="divtagdefaultwrapper" style="font-size:12pt">
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif">These fixes will make proxy class generation deterministic with respect to order of loading and won't be flagged at runtime since the test suite would
already detect them.</span></div>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif"><br>
</span></div>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif">I would love to hear from the community about these ideas. If in agreement, I would be happy to produce a patch. I have discovered this issue with
subclasses of <a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java" class="OWAAutoLink">
GeneratedConstructorAccessor</a> as well and I imagine it will also apply to some other runtime generated classes. If you disagree, please let me know also. It helps with my research.</span></div>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif"><br>
</span></div>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif">I also have
<a href="https://github.com/chains-project/exploits-for-sbom.exe" class="OWAAutoLink">
PoCs for the above CVEs</a> and a proof concept tool is being developed under the name
<a href="https://github.com/chains-project/sbom.exe" class="OWAAutoLink">sbom.exe</a> in case any one wonders about the implementation. I would also be happy to explain more.<br>
</span></div>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif"><br>
</span></div>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif">Regards,</span></div>
<span style="font-family:Garamond,Georgia,serif"></span><span style="font-family:Garamond,Georgia,serif"></span><span style="color:rgb(0,0,0)"></span><span style="font-family:Garamond,Georgia,serif"></span><span style="font-family:Garamond,Georgia,serif"></span>
<div style="margin-top:0; margin-bottom:0"><span style="color:rgb(0,0,0); font-family:Garamond,Georgia,serif">Aman Sharma</span></div>
</span><br>
</span></font></div>
<div name="divtagdefaultwrapper"><font size="2" color="#808080"><span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)"></span><span class="im">PhD Student<br style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif">
<span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)">KTH Royal Institute of Technology</span><br style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif">
</span><span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)">School of Electrical Engineering and Computer Science (EECS)</span><br style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif">
<span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)">Department of Theoretical Computer Science (TCS)</span><br style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif">
<span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)"><a href="http://www.kth.se" target="_blank" id="LPNoLP"></a><a href="https://www.kth.se/profile/amansha" class="OWAAutoLink" id="LPNoLP"></a><a href="https://www.kth.se/profile/amansha" class="OWAAutoLink" id="LPNoLP"></a></span></font></div>
</div>
<a href="https://www.kth.se/profile/amansha" class="OWAAutoLink" id="LPNoLP"><span style="font-size:10pt"></span></a><a href="https://algomaster99.github.io/" class="OWAAutoLink" id="LPNoLP">https://algomaster99.github.io/</a><br>
</div>
</div>
</div>
</body>
</html>