<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Garamond,Georgia,serif">
<p>Hi David,</p>
<p><br>
</p>
<p>> <font size="2"><span style="font-size:10pt">How did you try to intercept them? Hidden classes are not "loaded" in
<br>
the normal sense so won't trigger class load events.</span></font></p>
<p><br>
</p>
<p>I could not intercept them. I only see them when I pass `-verbose:class` in the Java CLI.</p>
<p><br>
</p>
<p>I also couldn't intercept them using <a href="https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook" class="x_OWAAutoLink">
JVMTI Class File Load Hook</a> event. However JEP 371 suggests that it should be possible to intercept them using
<a href="https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad" class="x_OWAAutoLink">
JVMTI Class Load</a> event, but I won't have the bytecode at this stage. So is there no way to get its bytecode before it is linked and initialized in the JVM?<br>
</p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_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="x_m_4935352394101912768Signature">
<div name="x_divtagdefaultwrapper"><font size="2" color="#808080"><span style="font-family:Arial,"Helvetica Neue",helvetica,sans-serif; background-color:rgb(255,255,255)"><span id="x_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">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="x_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="x_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="x_OWAAutoLink" id="LPNoLP"></a><a href="https://www.kth.se/profile/amansha" class="x_OWAAutoLink" id="LPNoLP"></a></span></font></div>
</div>
<a href="https://www.kth.se/profile/amansha" class="x_OWAAutoLink" id="LPNoLP"><span style="font-size:10pt"></span></a><a href="https://algomaster99.github.io/" class="x_OWAAutoLink" id="LPNoLP">https://algomaster99.github.io/</a><br>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> David Holmes <david.holmes@oracle.com><br>
<b>Sent:</b> Monday, May 20, 2024 2:59:17 AM<br>
<b>To:</b> Aman Sharma; liangchenblue@gmail.com<br>
<b>Cc:</b> core-libs-dev@openjdk.org; leyden-dev@openjdk.org<br>
<b>Subject:</b> Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 17/05/2024 9:43 pm, Aman Sharma wrote:<br>
> Hi Chen,<br>
> <br>
> > java.lang.invoke.LambdaForm$MH/0x00000200cc000400<br>
> <br>
> I do see this as output when I pass -verbose:class. However, based on my <br>
> experiments, I have seen that neither an agent passed via 'javaagent' <br>
> nor an agent passed via 'agentpath' is able to intercept this hidden class.<br>
<br>
How did you try to intercept them? Hidden classes are not "loaded" in <br>
the normal sense so won't trigger class load events.<br>
<br>
> Also, I was a bit confused since I saw somewhere that the names of <br>
> hidden classes are null. But thanks for clarifying here.<br>
<br>
The JEP clearly defines the name format for hidden classes - though the <br>
final component is VM specific (and typically a hashcode).<br>
<br>
<a href="https://openjdk.org/jeps/371">https://openjdk.org/jeps/371</a><br>
<br>
Cheers,<br>
David<br>
-----<br>
<br>
> > avoid dynamic class loading<br>
> <br>
> I don't see dynamic class loading as a problem. I only mind some <br>
> unstable generation aspects of them which make it hard to verify them <br>
> based on an allowlist.<br>
> <br>
> For example, if this hidden class is generated with the exact same name <br>
> and the exact same bytecode during runtime as well, it would be easy to <br>
> verify it. However, I do see the names are based on some sort of memory <br>
> address so and I don't know what bytecode it has so I don't have <br>
> suggestions to make them stable as of now. For Proxy classes, I feel it <br>
> can be addressed unless you disagree or some involved in Project Leyden <br>
> does. :) Thank you for forwarding my mail there.<br>
> <br>
> Regards,<br>
> Aman Sharma<br>
> <br>
> PhD Student<br>
> KTH Royal Institute of Technology<br>
> <a href="https://algomaster99.github.io/">https://algomaster99.github.io/</a> <<a href="https://algomaster99.github.io/">https://algomaster99.github.io/</a>><br>
> <br>
> ------------------------------------------------------------------------<br>
> *From:* liangchenblue@gmail.com <liangchenblue@gmail.com><br>
> *Sent:* Friday, May 17, 2024 1:23:58 pm<br>
> *To:* Aman Sharma <amansha@kth.se><br>
> *Cc:* core-libs-dev@openjdk.org <core-libs-dev@openjdk.org>; <br>
> leyden-dev@openjdk.org <leyden-dev@openjdk.org><br>
> *Subject:* Re: Deterministic naming of subclasses of <br>
> `java/lang/reflect/Proxy`<br>
> <br>
> Hi Aman,<br>
> For `-verbose:class`, it's a JVM argument instead of a program argument; <br>
> so when you run a java program like `java Main`, you should call it as <br>
> `java -verbose:class Main`.<br>
> When done correctly, you should see hidden class outputs like:<br>
> [0.032s][info][class,load] <br>
> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source: <br>
> __JVM_LookupDefineClass__<br>
> The loading of java.lang.invoke hidden classes requires your program to <br>
> use MethodHandle features, like a lambda.<br>
> <br>
> I think the problem you are exploring, that to avoid dynamic class <br>
> loading and effectively turn Java Platform closed for security, is also <br>
> being accomplished by project Leyden (as I've shared initially); Thus, I <br>
> am forwarding this to leyden-dev instead, so you can see what approach <br>
> Leyden uses to accomplish the same goal as yours.<br>
> <br>
> Regards, Chen Liang<br>
> <br>
> On Fri, May 17, 2024 at 4:40 AM Aman Sharma <amansha@kth.se <br>
> <<a href="mailto:amansha@kth.se">mailto:amansha@kth.se</a>>> wrote:<br>
> <br>
> __<br>
> <br>
> Hi Roger,<br>
> <br>
> <br>
> Do you have ideas on how to intercept them? My javaagent is not able<br>
> to nor a JVMTI agent passed using `agentpath` option. It also does<br>
> not seem to show up in logs when I pass `-verbose:class`.<br>
> <br>
> <br>
> Also, what do you think of renaming the proxy classes as suggested<br>
> below?<br>
> <br>
> <br>
> Regards,<br>
> Aman Sharma<br>
> <br>
> PhD Student<br>
> KTH Royal Institute of Technology<br>
> School of Electrical Engineering and Computer Science (EECS)<br>
> Department of Theoretical Computer Science (TCS)<br>
> <<a href="http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha">http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha</a>><br>
> <<a href="https://www.kth.se/profile/amansha">https://www.kth.se/profile/amansha</a>>https://algomaster99.github.io/<br>
> <<a href="https://algomaster99.github.io/">https://algomaster99.github.io/</a>><br>
> ------------------------------------------------------------------------<br>
> *From:* core-libs-dev <core-libs-dev-retn@openjdk.org<br>
> <<a href="mailto:core-libs-dev-retn@openjdk.org">mailto:core-libs-dev-retn@openjdk.org</a>>> on behalf of Roger Riggs<br>
> <roger.riggs@oracle.com <<a href="mailto:roger.riggs@oracle.com">mailto:roger.riggs@oracle.com</a>>><br>
> *Sent:* Friday, May 17, 2024 4:57:46 AM<br>
> *To:* core-libs-dev@openjdk.org <<a href="mailto:core-libs-dev@openjdk.org">mailto:core-libs-dev@openjdk.org</a>><br>
> *Subject:* Re: Deterministic naming of subclasses of<br>
> `java/lang/reflect/Proxy`<br>
> Hi Aman,<br>
> <br>
> You may also run into hidden classes (JEP 371: Hidden Classes) that<br>
> allow classes to be defined, at runtime, without names.<br>
> It has been proposed to use them for generated proxies but that<br>
> hasn't been implemented yet.<br>
> There are benefits to having nameless classes, because they can't be<br>
> referenced by name, only as a capability, they can be better<br>
> encapsulated.<br>
> <br>
> fyi, Roger Riggs<br>
> <br>
> <br>
> On 5/16/24 8:11 AM, Aman Sharma wrote:<br>
>><br>
>> Hi,<br>
>><br>
>><br>
>> Thanks for your response, Liang!<br>
>><br>
>><br>
>> > I think you meant CVE-2021-42392 instead of 2022.<br>
>><br>
>><br>
>> Sorry of the error. I indeed meant CVE-2021-42392<br>
>> <<a href="https://nvd.nist.gov/vuln/detail/cve-2021-42392">https://nvd.nist.gov/vuln/detail/cve-2021-42392</a>>.<br>
>><br>
>><br>
>> > Leyden mainly avoids this unstable generation by performing a<br>
>> training run to collect classes loaded<br>
>><br>
>><br>
>> Would love to know the details of Project Leyden and how they<br>
>> worked so far to focus on this goal. In our case, the training run<br>
>> is the test suite.<br>
>><br>
>><br>
>> > GeneratedConstructorAccessor is already retired by JEP 416 [2]<br>
>> in Java 18<br>
>><br>
>><br>
>> I did see them not appearing in my allowlist when I ran my study<br>
>> subject (Apache PDFBox) with Java 21. Thanks for letting me know<br>
>> about this JEP. I see they are re-implemented with method handles.<br>
>><br>
>><br>
>> > How are you checking the classes?<br>
>><br>
>><br>
>> To detect runtime generated code, we have javaagent that is hooked<br>
>> statically to the test suite execution. It gives us all classes<br>
>> that that is loaded post the JVM and the javaagent are loaded. So<br>
>> we only check the classes loaded for the purpose of running the<br>
>> application. This is also why we did not choose -agentlib as it<br>
>> would give classes for the setting up JVM and javaagent and we the<br>
>> user of our tool must the classes they load.<br>
>><br>
>><br>
>> Next, we have a `ClassFileTransformer` hook in the agent where we<br>
>> produce the checksum using the bytecode. And we compare the<br>
>> checksum with the one existing in the allowlist. The checksum<br>
>> computation algorithm is same for both steps. Let me describe how<br>
>> I compute the checksum.<br>
>><br>
>><br>
>> 1. I get the CONSTANT_Class_info<br>
>> <<a href="https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1">https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.1</a>> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <<a href="https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7">https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.7</a>>
corresponding to a fix String constant, say "foo".<br>
>> 2. Since, the name of the class is used to refer to its types<br>
>> members (fields/method), I get all CONSTANT_Fieldref_info<br>
>> <<a href="https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2">https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.2</a>> and if its `class_index` corresponds to the old `this_class`, we rewrite the UTF8
value of class_index to the same constant "foo".<br>
>> 3. Next, since the naming of the fields, in Proxy classes, are<br>
>> also suffixed by numbers, for example, `private static Method<br>
>> m4`, we rewrite the UTF8 value of name in the<br>
>> CONSTANT_NameAndType_info<br>
>> <<a href="https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6">https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html#jvms-4.4.6</a>>.<br>
>> 4. These fields can also have a random order so we simply sort<br>
>> the entire byte code using `Arrays.sort(byte[])` to eliminate<br>
>> any differences due to ordering of fields/methods.<br>
>> 5. Simply sorting the byte array still had minute differences. I<br>
>> could not understand why they existed even though values in<br>
>> constant pool of the bytecode in allowlist and at runtime were<br>
>> exactly the same after rewriting. The differences existed in<br>
>> the bytes of the Code attribute of methods. I concluded that<br>
>> the bytes stored some position information. To avoid this, I<br>
>> created a subarray where I considered the bytes corresponding<br>
>> to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for<br>
>> it resulted in the same checksums for both classfiles. <br>
>><br>
>><br>
>> Let's understand the whole approach with an example of Proxy class.<br>
>><br>
>> `<br>
>> public final class $Proxy42 extends Proxy implements org.apache.logging.log4j.core.config.plugins.Plugin {<br>
>> `<br>
>><br>
>> The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".<br>
>><br>
>> When the same class is intercepted at runtime, say "$Proxy10", we<br>
>> look for "Proxy_Plugin" in the allowlist and since the checksum<br>
>> algorithm is same in both cases, we get a match and let the class<br>
>> load.<br>
>><br>
>> This approach has seemed to work well for Proxy classes, Generated<br>
>> Constructor Accessor (which is removed as you said). I also looked<br>
>> at the species generated by method handles. I did not notice any<br>
>> modification in them. Their name generation seemed okay to me. If<br>
>> some new Species are generated, it is of course detected since it<br>
>> is not in the allowlist.<br>
>><br>
>> I have not looked into LambdaMetafactory because I did not<br>
>> encounter it as a problem so far, but I am aware its name<br>
>> generation is also unstable. I have run my approach only a few<br>
>> projects only. And for hidden classes, I assume the the agent<br>
>> won't be able to intercept them so detecting them would be really<br>
>> hard.<br>
>><br>
>><br>
>> Regards,<br>
>> Aman Sharma<br>
>><br>
>> PhD Student<br>
>> KTH Royal Institute of Technology<br>
>> School of Electrical Engineering and Computer Science (EECS)<br>
>> Department of Theoretical Computer Science (TCS)<br>
>> <<a href="https://www.kth.se/profile/amansha">https://www.kth.se/profile/amansha</a>>https://algomaster99.github.io/ <<a href="https://algomaster99.github.io/">https://algomaster99.github.io/</a>><br>
>> ------------------------------------------------------------------------<br>
>> *From:* liangchenblue@gmail.com <<a href="mailto:liangchenblue@gmail.com">mailto:liangchenblue@gmail.com</a>><br>
>> <liangchenblue@gmail.com> <<a href="mailto:liangchenblue@gmail.com">mailto:liangchenblue@gmail.com</a>><br>
>> *Sent:* Thursday, May 16, 2024 5:52:03 AM<br>
>> *To:* Aman Sharma; core-libs-dev<br>
>> *Cc:* Martin Monperrus<br>
>> *Subject:* Re: Deterministic naming of subclasses of<br>
>> `java/lang/reflect/Proxy`<br>
>> Hi Aman,<br>
>> I think you meant CVE-2021-42392 instead of 2022.<br>
>><br>
>> For your approach of an "allowlist" for Java runtime, project<br>
>> Leyden is looking to generate a static image [1], that<br>
>> > At run time it cannot load classes from outside the image, nor<br>
>> can it create classes dynamically.<br>
>> Leyden mainly avoids this unstable generation by performing a<br>
>> training run to collect classes loaded and even object graphs; I<br>
>> am not familiar with the details unfortunately.<br>
>><br>
>> Otherwise, the Proxy discussion belongs better to core-libs-dev,<br>
>> as java.lang.reflect.Proxy is part of Java's core libraries. I am<br>
>> replying this thread to core-libs-dev.<br>
>><br>
>> For your perceived problem that classes don't have unique names,<br>
>> your description sounds dubious: GeneratedConstructorAccessor is<br>
>> already retired by JEP 416 [2] in Java 18, and there are many<br>
>> other cases in which JDK generates classes without stable names,<br>
>> notoriously LambdaMetafactory (Gradle wished for cacheable<br>
>> Lambdas); the same applies for the generated classes for<br>
>> MethodHandle's LambdaForms (which carries implementation code for<br>
>> LambdaForm). How are you checking the classes? It seems you are<br>
>> not checking hidden classes. Proxy and Lambda classes are defined<br>
>> by the caller's class loader, while LambdaForms are under JDK's<br>
>> system class loader I think. We need to ensure you are correctly<br>
>> finding all unstable classes before we can proceed.<br>
>><br>
>> [1]: <a href="https://openjdk.org/projects/leyden/notes/01-beginnings">https://openjdk.org/projects/leyden/notes/01-beginnings</a><br>
>> <<a href="https://openjdk.org/projects/leyden/notes/01-beginnings">https://openjdk.org/projects/leyden/notes/01-beginnings</a>><br>
>> [2]: <a href="https://openjdk.org/jeps/416">https://openjdk.org/jeps/416</a> <<a href="https://openjdk.org/jeps/416">https://openjdk.org/jeps/416</a>><br>
>><br>
>> On Wed, May 15, 2024 at 7:00 PM Aman Sharma <amansha@kth.se<br>
>> <<a href="mailto:amansha@kth.se">mailto:amansha@kth.se</a>>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>><br>
>> My name is Aman and I am a PhD student at KTH Royal Institute<br>
>> of Technology, Stockholm, Sweden. I research as part of CHAINS<br>
>> <<a href="https://chains.proj.kth.se/">https://chains.proj.kth.se/</a>> project to strengthen the<br>
>> software supply chain of multiple ecosystem. I particularly<br>
>> focus on runtime integrity in Java. In this email, I want to<br>
>> write about an issue I have discovered with /dynamic<br>
>> generation of `java.lang.reflect.Proxy`classes/. I will<br>
>> propose a solution and would love to hear the feedback from<br>
>> the community. Let me know if this is the correct mailing-list<br>
>> for such discussions. It seemed the most relevant from this<br>
>> list <<a href="https://mail.openjdk.org/mailman/listinfo">https://mail.openjdk.org/mailman/listinfo</a>>.<br>
>><br>
>><br>
>> *My research*<br>
>><br>
>> *<br>
>> *<br>
>><br>
>> Java has features to load class on the fly - it can either<br>
>> download or generate a class at runtime. These features are<br>
>> useful for inner workings of JDK. For example, implementing<br>
>> annotations, reflective access, etc. However, these features<br>
>> have also contributed to critical vulnerabilities in the past<br>
>> - CVE-2021-44228 (log4shell), CVE-2022-33980, CVE-2022-42392.<br>
>> All of these vulnerabilities have one thing in common - /a<br>
>> class that was not known during build time was<br>
>> downloaded/generated at runtime and loaded into JVM./<br>
>><br>
>><br>
>> To defend against such vulnerabilities, we propose a solution<br>
>> to /allowlist classes for runtime/. This allowlist will<br>
>> contain an exhaustive list of classes that can be loaded by<br>
>> the JVM and it will be enforced at runtime. We build this<br>
>> allowlist from three sources:<br>
>><br>
>> 1. All classes of all modules provided by the Java Standard<br>
>> Library. We use ClassGraph<br>
>> <<a href="https://github.com/classgraph/classgraph">https://github.com/classgraph/classgraph</a>> to scan the JDK.<br>
>> 2. We can take the source code and all dependencies of an<br>
>> application. We use a software bill of materials to get<br>
>> all the data.<br>
>> 3. Finally, we use run the test suite to include any runtime<br>
>> downloaded/generated classes. <br>
>><br>
>> Such a list is able to prevent the above 3 CVEs because it<br>
>> does not let the "unknown" bytecode to be loaded.<br>
>><br>
>> *Problem with generating such an allowlist*<br>
>> *<br>
>> *<br>
>> The first two parts of the allowlist are easy to get. The<br>
>> problem is with the third step where we want to allowlist all<br>
>> the classes that could be downloaded or generated. Upon<br>
>> running the test suite and hooking to the classes it loads, we<br>
>> observer that the list consists of classes that are called<br>
>> "com/sun/proxy/$Proxy2",<br>
>> "jdk/internal/reflect/GeneratedConstructorAccessor3" among<br>
>> many more. The purpose of these classes can be identifed. The<br>
>> proxy class is created for to implement an annotation. The<br>
>> accessor gives access to constructor of a class to the JVM.<br>
>><br>
>> When enforcing this allowlist at runtime, we see that the<br>
>> bytecode content for "com/sun/proxy/$Proxy2" differs in the<br>
>> allowlist and at runtime. In our case, we we are experimenting<br>
>> with pdfbox <<a href="https://github.com/apache/pdfbox">https://github.com/apache/pdfbox</a>> so we created<br>
>> the allowlist using its test suite. Then we enforced this<br>
>> allowlist while running some of its subcommands. However,<br>
>> there was some other proxy class say "com/sun/proxy/$Proxy5"<br>
>> at runtime that implemented the same interfaces and had the<br>
>> same methods as "com/sun/proxy/$Proxy2" in the allowlist. They<br>
>> only differed in the name of the class, order of fields, and<br>
>> types for fields references. This could happen because the<br>
>> order of the loading of class is workload dependent, but it<br>
>> causes problem to generate such an allowlist.<br>
>><br>
>> *Solution<br>
>> *<br>
>><br>
>><br>
>> We propose that naming of subclasses of<br>
>> "java/lang/reflect/Proxy" should not be dependent upon the<br>
>> order of loading. In order to do so, two issues can be fixed:<br>
>><br>
>> 1. The naming of the class should not be based on AtomicLong<br>
>> <<a href="https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531">https://github.com/openjdk/jdk/blob/b687aa550837830b38f0f0faa69c353b1e85219c/src/java.base/share/classes/java/lang/reflect/Proxy.java#L531</a>>.
Rather it could be named based on the interfaces it implements. I also wonder why AtomicLong is chosen in the first place.<br>
>> 2. Methods of the interfaces must be in a particular order.<br>
>> Right now, they are not sorted in any particular order<br>
>> <<a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2178</a>>.<br>
>><br>
>><br>
>> These fixes will make proxy class generation deterministic<br>
>> with respect to order of loading and won't be flagged at<br>
>> runtime since the test suite would already detect them.<br>
>><br>
>> I would love to hear from the community about these ideas. If<br>
>> in agreement, I would be happy to produce a patch. I have<br>
>> discovered this issue with subclasses of<br>
>> GeneratedConstructorAccessor<br>
>> <<a href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/reflect/ConstructorAccessor.java</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.<br>
>><br>
>> I also have PoCs for the above CVEs<br>
>> <<a href="https://github.com/chains-project/exploits-for-sbom.exe">https://github.com/chains-project/exploits-for-sbom.exe</a>> and<br>
>> a proof concept tool is being developed under the name<br>
>> sbom.exe <<a href="https://github.com/chains-project/sbom.exe">https://github.com/chains-project/sbom.exe</a>> in case<br>
>> any one wonders about the implementation. I would also be<br>
>> happy to explain more.<br>
>><br>
>> Regards,<br>
>> Aman Sharma<br>
>><br>
>> PhD Student<br>
>> KTH Royal Institute of Technology<br>
>> School of Electrical Engineering and Computer Science (EECS)<br>
>> Department of Theoretical Computer Science (TCS)<br>
>> <<a href="https://www.kth.se/profile/amansha">https://www.kth.se/profile/amansha</a>>https://algomaster99.github.io/ <<a href="https://algomaster99.github.io/">https://algomaster99.github.io/</a>><br>
>><br>
> <br>
> <br>
</div>
</span></font>
</body>
</html>