Deterministic naming of subclasses of `java/lang/reflect/Proxy`

Chen Liang liangchenblue at gmail.com
Wed May 22 11:35:46 UTC 2024


Hi Aman,
We have tried defining Proxy as hidden classes; a previous attempt was on
hold because of issues with serialization. Otherwise, Proxies work great as
hidden classes.

Chen

On Mon, May 20, 2024 at 7:56 AM Aman Sharma <amansha at kth.se> wrote:

> Hi David,
>
>
> > I would not expect any class load
> events.
>
>
> I understand. I also haven't tried to intercept them but I see only one
> approach right now to include them in an allowlist - 1) statically look for
> invocations of "Lookup::defineHiddenClass". 2) Instrument them so that
> its first argument "bytes" can be looked into upon. I haven't looked into
> it much because I did not have much idea about it. And they are hidden so
> it made it worse. 😅 Thanks for sharing the JEP!
>
>
> >
> java.lang.reflect.Proxy could define hidden classes to act as the proxy
> classes which implement proxy interfaces; from JEP 317
>
>
> It says that Proxy classes will also become hidden classes. Is it
> underway? Right now one can intercept, transform them, and include them in
> an allowlist. What do you think of naming them independent of AtomicLong so
> that a proxy class generated at runtime is easy to lookup in the allowlist?
>
>
>
> Regards,
> Aman Sharma
>
> PhD Student
> KTH Royal Institute of Technology
> School of Electrical Engineering and Computer Science (EECS)
> Department of Theoretical Computer Science (TCS)
> <http://www.kth.se> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>
> <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> ------------------------------
> *From:* David Holmes <david.holmes at oracle.com>
> *Sent:* Monday, May 20, 2024 2:30:37 PM
> *To:* Aman Sharma; liangchenblue at gmail.com
> *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> *Subject:* Re: Deterministic naming of subclasses of
> `java/lang/reflect/Proxy`
>
> On 20/05/2024 10:12 pm, Aman Sharma wrote:
> > Hi David,
> >
> >
> >  > How did you try to intercept them? Hidden classes are not "loaded" in
> > the normal sense so won't trigger class load events.
> >
> >
> > I could not intercept them. I only see them when I pass `-verbose:class`
> > in the Java CLI.
>
> Yes that is why I asked how you tried to intercept them.
>
> >
> > I also couldn't intercept them using JVMTI Class File Load Hook
> > <
> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassFileLoadHook>
> event. However JEP 371 suggests that it should be possible to intercept
> them using JVMTI Class Load <
> https://docs.oracle.com/en/java/javase/21/docs/specs/jvmti.html#ClassLoad>
> 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?
>
> Hidden classes are not loaded so I would not expect any class load
> events. However the exact nature of the JVMTI class load event is
> unclear as it talks about "class or interface creation" which is neither
> loading or defining per se. But a class prepare event sounds like it
> should be issued. However neither give you access to the bytecode of the
> class AFAICS.
>
> David
> -----
>
>
> >
> > Regards,
> > Aman Sharma
> >
> > PhD Student
> > KTH Royal Institute of Technology
> > School of Electrical Engineering and Computer Science (EECS)
> > Department of Theoretical Computer Science (TCS)
> > <
> http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha
> >
> > <https://www.kth.se/profile/amansha>https://algomaster99.github.io/
> > <https://algomaster99.github.io/>
> > ------------------------------------------------------------------------
> > *From:* David Holmes <david.holmes at oracle.com>
> > *Sent:* Monday, May 20, 2024 2:59:17 AM
> > *To:* Aman Sharma; liangchenblue at gmail.com
> > *Cc:* core-libs-dev at openjdk.org; leyden-dev at openjdk.org
> > *Subject:* Re: Deterministic naming of subclasses of
> > `java/lang/reflect/Proxy`
> > On 17/05/2024 9:43 pm, Aman Sharma wrote:
> >> Hi Chen,
> >>
> >>  > java.lang.invoke.LambdaForm$MH/0x00000200cc000400
> >>
> >> I do see this as output when I pass -verbose:class. However, based on
> my
> >> experiments, I have seen that neither an agent passed via 'javaagent'
> >> nor an agent passed via 'agentpath' is able to intercept this hidden
> class.
> >
> > How did you try to intercept them? Hidden classes are not "loaded" in
> > the normal sense so won't trigger class load events.
> >
> >> Also, I was a bit confused since I saw somewhere that the names of
> >> hidden classes are null. But thanks for clarifying here.
> >
> > The JEP clearly defines the name format for hidden classes - though the
> > final component is VM specific (and typically a hashcode).
> >
> > https://openjdk.org/jeps/371 <https://openjdk.org/jeps/371>
> >
> > Cheers,
> > David
> > -----
> >
> >>  > avoid dynamic class loading
> >>
> >> I don't see dynamic class loading as a problem. I only mind some
> >> unstable generation aspects of them which make it hard to verify them
> >> based on an allowlist.
> >>
> >> For example, if this hidden class is generated with the exact same name
> >> and the exact same bytecode during runtime as well, it would be easy to
> >> verify it. However, I do see the names are based on some sort of memory
> >> address so and I don't know what bytecode it has so I don't have
> >> suggestions to make them stable as of now. For Proxy classes, I feel it
> >> can be addressed unless you disagree or some involved in Project Leyden
> >> does. :) Thank you for forwarding my mail there.
> >>
> >> Regards,
> >> Aman Sharma
> >>
> >> PhD Student
> >> KTH Royal Institute of Technology
> >> https://algomaster99.github.io/ <https://algomaster99.github.io/>
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>
> >> ------------------------------------------------------------------------
> >> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
> >> *Sent:* Friday, May 17, 2024 1:23:58 pm
> >> *To:* Aman Sharma <amansha at kth.se>
> >> *Cc:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> >> leyden-dev at openjdk.org <leyden-dev at openjdk.org>
> >> *Subject:* Re: Deterministic naming of subclasses of
> >> `java/lang/reflect/Proxy`
> >>
> >> Hi Aman,
> >> For `-verbose:class`, it's a JVM argument instead of a program
> argument;
> >> so when you run a java program like `java Main`, you should call it as
> >> `java -verbose:class Main`.
> >> When done correctly, you should see hidden class outputs like:
> >> [0.032s][info][class,load]
> >> java.lang.invoke.LambdaForm$MH/0x00000200cc000400 source:
> >> __JVM_LookupDefineClass__
> >> The loading of java.lang.invoke hidden classes requires your program to
> >> use MethodHandle features, like a lambda.
> >>
> >> I think the problem you are exploring, that to avoid dynamic class
> >> loading and effectively turn Java Platform closed for security, is also
> >> being accomplished by project Leyden (as I've shared initially); Thus,
> I
> >> am forwarding this to leyden-dev instead, so you can see what approach
> >> Leyden uses to accomplish the same goal as yours.
> >>
> >> Regards, Chen Liang
> >>
> >> On Fri, May 17, 2024 at 4:40 AM Aman Sharma <amansha at kth.se
> >> <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
> wrote:
> >>
> >>     __
> >>
> >>     Hi Roger,
> >>
> >>
> >>     Do you have ideas on how to intercept them? My javaagent is not able
> >>     to nor a JVMTI agent passed using `agentpath` option. It also does
> >>     not seem to show up in logs when I pass `-verbose:class`.
> >>
> >>
> >>     Also, what do you think of renaming the proxy classes as suggested
> >>     below?
> >>
> >>
> >>     Regards,
> >>     Aman Sharma
> >>
> >>     PhD Student
> >>     KTH Royal Institute of Technology
> >>     School of Electrical Engineering and Computer Science (EECS)
> >>     Department of Theoretical Computer Science (TCS)
> >>     <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
> >>
> >>     <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> >>     <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>
> ------------------------------------------------------------------------
> >>     *From:* core-libs-dev <core-libs-dev-retn at openjdk.org
> >>     <mailto:core-libs-dev-retn at openjdk.org
> > <mailto:core-libs-dev-retn at openjdk.org <core-libs-dev-retn at openjdk.org>>>>
> on behalf of Roger Riggs
> >>     <roger.riggs at oracle.com <mailto:roger.riggs at oracle.com <
> mailto:roger.riggs at oracle.com <roger.riggs at oracle.com>>>>
> >>     *Sent:* Friday, May 17, 2024 4:57:46 AM
> >>     *To:* core-libs-dev at openjdk.org <mailto:core-libs-dev at openjdk.org <
> mailto:core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>>>
> >>     *Subject:* Re: Deterministic naming of subclasses of
> >>     `java/lang/reflect/Proxy`
> >>     Hi Aman,
> >>
> >>     You may also run into hidden classes (JEP 371: Hidden Classes) that
> >>     allow classes to be defined, at runtime, without names.
> >>     It has been proposed to use them for generated proxies but that
> >>     hasn't been implemented yet.
> >>     There are benefits to having nameless classes, because they can't be
> >>     referenced by name, only as a capability, they can be better
> >>     encapsulated.
> >>
> >>     fyi, Roger Riggs
> >>
> >>
> >>     On 5/16/24 8:11 AM, Aman Sharma wrote:
> >>>
> >>>     Hi,
> >>>
> >>>
> >>>     Thanks for your response, Liang!
> >>>
> >>>
> >>>     > I think you meant CVE-2021-42392 instead of 2022.
> >>>
> >>>
> >>>     Sorry of the error. I indeed meant CVE-2021-42392
> >>>     <https://nvd.nist.gov/vuln/detail/cve-2021-42392
> > <https://nvd.nist.gov/vuln/detail/cve-2021-42392>>.
> >>>
> >>>
> >>>     > Leyden mainly avoids this unstable generation by performing a
> >>>     training run to collect classes loaded
> >>>
> >>>
> >>>     Would love to know the details of Project Leyden and how they
> >>>     worked so far to focus on this goal. In our case, the training run
> >>>     is the test suite.
> >>>
> >>>
> >>>     > GeneratedConstructorAccessor is already retired by JEP 416 [2]
> >>>     in Java 18
> >>>
> >>>
> >>>     I did see them not appearing in my allowlist when I ran my study
> >>>     subject (Apache PDFBox) with Java 21. Thanks for letting me know
> >>>     about this JEP. I see they are re-implemented with method handles.
> >>>
> >>>
> >>>     > How are you checking the classes?
> >>>
> >>>
> >>>     To detect runtime generated code, we have javaagent that is hooked
> >>>     statically to the test suite execution. It gives us all classes
> >>>     that that is loaded post the JVM and the javaagent are loaded. So
> >>>     we only check the classes loaded for the purpose of running the
> >>>     application. This is also why we did not choose -agentlib as it
> >>>     would give classes for the setting up JVM and javaagent and we the
> >>>     user of our tool must the classes they load.
> >>>
> >>>
> >>>     Next, we have a `ClassFileTransformer` hook in the agent where we
> >>>     produce the checksum using the bytecode. And we compare the
> >>>     checksum with the one existing in the allowlist. The checksum
> >>>     computation algorithm is same for both steps. Let me describe how
> >>>     I compute the checksum.
> >>>
> >>>
> >>>      1. I get the CONSTANT_Class_info
> >>>         <
> 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>>
> entry corresponding to `this_class` and rewrite the CONSTANT_Utf8_info <
> 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>>
> corresponding to a fix String constant, say "foo".
> >>>      2. Since, the name of the class is used to refer to its types
> >>>         members (fields/method), I get all CONSTANT_Fieldref_info
> >>>         <
> 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>>
> and if its `class_index` corresponds to the old `this_class`, we rewrite
> the UTF8 value of class_index to the same constant "foo".
> >>>      3. Next, since the naming of the fields, in Proxy classes, are
> >>>         also suffixed by numbers, for example, `private static Method
> >>>         m4`, we rewrite the UTF8 value of name in the
> >>>         CONSTANT_NameAndType_info
> >>>         <
> 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
> >>.
> >>>      4. These fields can also have a random order so we simply sort
> >>>         the entire byte code using `Arrays.sort(byte[])` to eliminate
> >>>         any differences due to ordering of fields/methods.
> >>>      5. Simply sorting the byte array still had minute differences. I
> >>>         could not understand why they existed even though values in
> >>>         constant pool of the bytecode in allowlist and at runtime were
> >>>         exactly the same after rewriting. The differences existed in
> >>>         the bytes of the Code attribute of methods. I concluded that
> >>>         the bytes stored some position information. To avoid this, I
> >>>         created a subarray where I considered the bytes corresponding
> >>>         to `CONSTANT_Utf8_info.bytes` only. Computing a checksum for
> >>>         it resulted in the same checksums for both classfiles.
> >>>
> >>>
> >>>     Let's understand the whole approach with an example of Proxy class.
> >>>
> >>>     `
> >>>     public  final  class  $Proxy42  extends  Proxy  implements
> org.apache.logging.log4j.core.config.plugins.Plugin  {
> >>>     `
> >>>
> >>>     The will go in the allowlist as "Proxy_Plugin: <SHA256 checksum>".
> >>>
> >>>     When the same class is intercepted at runtime, say "$Proxy10", we
> >>>     look for "Proxy_Plugin" in the allowlist and since the checksum
> >>>     algorithm is same in both cases, we get a match and let the class
> >>>     load.
> >>>
> >>>     This approach has seemed to work well for Proxy classes, Generated
> >>>     Constructor Accessor (which is removed as you said). I also looked
> >>>     at the species generated by method handles. I did not notice any
> >>>     modification in them. Their name generation seemed okay to me. If
> >>>     some new Species are generated, it is of course detected since it
> >>>     is not in the allowlist.
> >>>
> >>>     I have not looked into LambdaMetafactory because I did not
> >>>     encounter it as a problem so far, but I am aware its name
> >>>     generation is also unstable. I have run my approach only a few
> >>>     projects only. And for hidden classes, I assume the the agent
> >>>     won't be able to intercept them so detecting them would be really
> >>>     hard.
> >>>
> >>>
> >>>     Regards,
> >>>     Aman Sharma
> >>>
> >>>     PhD Student
> >>>     KTH Royal Institute of Technology
> >>>     School of Electrical Engineering and Computer Science (EECS)
> >>>     Department of Theoretical Computer Science (TCS)
> >>>     <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>>
> ------------------------------------------------------------------------
> >>>     *From:* liangchenblue at gmail.com <mailto:liangchenblue at gmail.com <
> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
> >>>     <liangchenblue at gmail.com> <mailto:liangchenblue at gmail.com <
> mailto:liangchenblue at gmail.com <liangchenblue at gmail.com>>>
> >>>     *Sent:* Thursday, May 16, 2024 5:52:03 AM
> >>>     *To:* Aman Sharma; core-libs-dev
> >>>     *Cc:* Martin Monperrus
> >>>     *Subject:* Re: Deterministic naming of subclasses of
> >>>     `java/lang/reflect/Proxy`
> >>>     Hi Aman,
> >>>     I think you meant CVE-2021-42392 instead of 2022.
> >>>
> >>>     For your approach of an "allowlist" for Java runtime, project
> >>>     Leyden is looking to generate a static image [1], that
> >>>     > At run time it cannot load classes from outside the image, nor
> >>>     can it create classes dynamically.
> >>>     Leyden mainly avoids this unstable generation by performing a
> >>>     training run to collect classes loaded and even object graphs; I
> >>>     am not familiar with the details unfortunately.
> >>>
> >>>     Otherwise, the Proxy discussion belongs better to core-libs-dev,
> >>>     as java.lang.reflect.Proxy is part of Java's core libraries. I am
> >>>     replying this thread to core-libs-dev.
> >>>
> >>>     For your perceived problem that classes don't have unique names,
> >>>     your description sounds dubious: GeneratedConstructorAccessor is
> >>>     already retired by JEP 416 [2] in Java 18, and there are many
> >>>     other cases in which JDK generates classes without stable names,
> >>>     notoriously LambdaMetafactory (Gradle wished for cacheable
> >>>     Lambdas); the same applies for the generated classes for
> >>>     MethodHandle's LambdaForms (which carries implementation code for
> >>>     LambdaForm). How are you checking the classes? It seems you are
> >>>     not checking hidden classes. Proxy and Lambda classes are defined
> >>>     by the caller's class loader, while LambdaForms are under JDK's
> >>>     system class loader I think. We need to ensure you are correctly
> >>>     finding all unstable classes before we can proceed.
> >>>
> >>>     [1]: https://openjdk.org/projects/leyden/notes/01-beginnings
> > <https://openjdk.org/projects/leyden/notes/01-beginnings>
> >>>     <https://openjdk.org/projects/leyden/notes/01-beginnings
> > <https://openjdk.org/projects/leyden/notes/01-beginnings>>
> >>>     [2]: https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>
> > <https://openjdk.org/jeps/416 <https://openjdk.org/jeps/416>>
> >>>
> >>>     On Wed, May 15, 2024 at 7:00 PM Aman Sharma <amansha at kth.se
> >>>     <mailto:amansha at kth.se <mailto:amansha at kth.se <amansha at kth.se>>>>
> wrote:
> >>>
> >>>         Hi,
> >>>
> >>>
> >>>         My name is Aman and I am a PhD student at KTH Royal Institute
> >>>         of Technology, Stockholm, Sweden. I research as part of CHAINS
> >>>         <https://chains.proj.kth.se/ <https://chains.proj.kth.se/>>
> 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 /dynamic
> >>>         generation of `java.lang.reflect.Proxy`classes/. 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 this
> >>>         list <https://mail.openjdk.org/mailman/listinfo
> > <https://mail.openjdk.org/mailman/listinfo>>.
> >>>
> >>>
> >>>         *My research*
> >>>
> >>>         *
> >>>         *
> >>>
> >>>         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 - /a
> >>>         class that was not known during build time was
> >>>         downloaded/generated at runtime and loaded into JVM./
> >>>
> >>>
> >>>         To defend against such vulnerabilities, we propose a solution
> >>>         to /allowlist classes for runtime/. 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:
> >>>
> >>>          1. All classes of all modules provided by the Java Standard
> >>>             Library. We use ClassGraph
> >>>             <https://github.com/classgraph/classgraph
> > <https://github.com/classgraph/classgraph>> to scan the JDK.
> >>>          2. We can take the source code and all dependencies of an
> >>>             application. We use a software bill of materials to get
> >>>             all the data.
> >>>          3. Finally, we use run the test suite to include any runtime
> >>>             downloaded/generated classes.
> >>>
> >>>         Such a list is able to prevent the above 3 CVEs because it
> >>>         does not let the "unknown" bytecode to be loaded.
> >>>
> >>>         *Problem with generating such an allowlist*
> >>>         *
> >>>         *
> >>>         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
> >>>         "com/sun/proxy/$Proxy2",
> >>>         "jdk/internal/reflect/GeneratedConstructorAccessor3" 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.
> >>>
> >>>         When enforcing this allowlist at runtime, we see that the
> >>>         bytecode content for "com/sun/proxy/$Proxy2" differs in the
> >>>         allowlist and at runtime. In our case, we we are experimenting
> >>>         with pdfbox <https://github.com/apache/pdfbox <
> https://github.com/apache/pdfbox>> 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 "com/sun/proxy/$Proxy5"
> >>>         at runtime that implemented the same interfaces and had the
> >>>         same methods as "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.
> >>>
> >>>         *Solution
> >>>         *
> >>>
> >>>
> >>>         We propose that naming of subclasses of
> >>>         "java/lang/reflect/Proxy" should not be dependent upon the
> >>>         order of loading. In order to do so, two issues can be fixed:
> >>>
> >>>          1. The naming of the class should not be based on AtomicLong
> >>>             <
> 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>>.
> Rather it could be named based on the interfaces it implements. I also
> wonder why AtomicLong is chosen in the first place.
> >>>          2. Methods of the interfaces must be in a particular order.
> >>>             Right now, they are not sorted in any particular order
> >>>             <
> 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
> >>.
> >>>
> >>>
> >>>         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.
> >>>
> >>>         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
> >>>         GeneratedConstructorAccessor
> >>>         <
> 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>>
> 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.
> >>>
> >>>         I also have PoCs for the above CVEs
> >>>         <https://github.com/chains-project/exploits-for-sbom.exe
> > <https://github.com/chains-project/exploits-for-sbom.exe>> and
> >>>         a proof concept tool is being developed under the name
> >>>         sbom.exe <https://github.com/chains-project/sbom.exe
> > <https://github.com/chains-project/sbom.exe>> in case
> >>>         any one wonders about the implementation. I would also be
> >>>         happy to explain more.
> >>>
> >>>         Regards,
> >>>         Aman Sharma
> >>>
> >>>         PhD Student
> >>>         KTH Royal Institute of Technology
> >>>         School of Electrical Engineering and Computer Science (EECS)
> >>>         Department of Theoretical Computer Science (TCS)
> >>>         <https://www.kth.se/profile/amansha
> > <https://www.kth.se/profile/amansha>>https://algomaster99.github.io/
> > <https://algomaster99.github.io/ <https://algomaster99.github.io/>>
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240522/2dd4a473/attachment-0001.htm>


More information about the core-libs-dev mailing list