[External] : Re: Reflective access to bytes[] of loaded class

[Brian Goetz]

One concern that we have is that unrestricted access to bytecode of 
loaded classes may constitute an attack vector for malicious code.

While we don't recommend people program like this:

     boolean checkPassword(String pw) {
         return "s00perSeekrit".equals(pw);
     }

arbitrary access to bytecode will compromise the "security" of this code 
in ways that the author might not have reasonably forseen.



On 2/9/2023 1:24 PM, Dan Heidinga wrote:
> Thanks for confirming, Gary.
>
> On Thu, Feb 9, 2023 at 11:59 AM Gary Frost <gary.frost at oracle.com> wrote:
>
>     Dan
>
>     I have indeed used JVMTI (and Java) agents for this. In the case
>     of JVMTI by keeping a std::map<std::string,byte[]>, and providing
>     a JNI call to get the bytes.
>
>     It works well for cases where we know the set of classes we want
>     bytes for at JVM 'launch time' , or there is something in the
>     class (name match? constant pool entry?) that we can trigger to
>     prune the size of the map.    Otherwise we are forced to retain a
>     map for all classes, just in case.
>
>     And of course who knew whether our JVMTI agent was the last
>     'actor' in the chain of possible mutators to play with the bytes.
>
>
> Can you expand on the use case for getting the current bytes from the 
> runtime?  As I said in the previous email, they aren't a good 
> candidate for feeding back into the runtime due to the existing JVMTI 
> agent process.  Is this mostly for testing purposes?
>
> --Dan
>
>
>
>     Hence the desire for runtime help
>
>
>     ------------------------------------------------------------------------
>     *From:* Dan Heidinga <heidinga at redhat.com>
>     *Sent:* Thursday, February 9, 2023 4:35 PM
>     *To:* Gary Frost <gary.frost at oracle.com>
>     *Cc:* classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
>     *Subject:* [External] : Re: Reflective access to bytes[] of loaded
>     class
>
>
>     On Thu, Feb 9, 2023 at 11:03 AM Gary Frost <gary.frost at oracle.com>
>     wrote:
>
>         I would like to make a case for adding a reflection API for
>         getting the bytes for class loaded by the VM as part of this
>         Classfile API.
>
>         Something akin to
>
>         byte[] Class.getClassfileBytes();
>
>
>     I've often wanted the same kind of API when doing one off tests
>     and minor modifications so I'm very sympathetic to the request. 
>     Typically when doing more "serious" class modification, I've used
>     the Instrumentation::retransform API [0] or written a native JVMTI
>     agent [1] and then such an api to get the current classfile bytes
>     isn't required.  Does this match your typical use cases as well?
>
>     The JVM does some interesting handling of classfile bytes in these
>     cases - it allows non-retransform-capable agents to do a 1 time
>     modification of the original classfile bytes and then saves those
>     bytes away before passing them on to the retransform-capable
>     agents.  One subsequent retransform events, those saved bytes are
>     reused and only the retransform-capable agents get a chance to
>     modify the bytes.
>
>     The reason this matters is that existing retransform-capable
>     agents aren't expecting to see the modifications they've made
>     present in the classfile bytes they get passed.  Providing an easy
>     api to get the currently executing bytecodes will mean that these
>     agents will now "see" their own modifications which may result in
>     incompatibilities.
>
>     I'd be interested in feedback from existing major agent providers
>     to see how much of a problem such a change would cause them before
>     pursuing it unless there's a more common pattern of use I'm
>     unaware of.
>
>     [0]
>     https://cr.openjdk.java.net/~iris/se/17/latestSpec/api/java.instrument/java/lang/instrument/Instrumentation.html#retransformClasses(java.lang.Class...)
>
>     [1]
>     https://cr.openjdk.java.net/~iris/se/17/latestSpec/specs/jvmti.html#RetransformClasses
>
>
>
>
>         At present developers usually resort to something like
>
>         clazz.getClassLoader().getResourceAsStream(
>             clazz.getName().replace(".", "/") + ".class")
>
>         Ignoring the fact that we may have just forced an expensive
>         network fetch, to bytes that the JVM clearly already has
>         'squirrelled away' somewhere...
>
>         For me this is hugely problematic as there is no guarentee
>         that the bytes fetched from such a stream will match the bytes
>         that the JVM is using for the class in question....
>
>         Java offers all sorts of opportunities (JVMTI agents, Java
>         agents, even custom ClassLoaders) for mutating the incoming
>         classfile's bytes. All of which the stream fetched via
>         getResourceAsStream() completely sidesteps.
>
>
>     See above (or the JVMTI spec) for which bytes get passed through
>     to agents.  The story is more complex than it first appears.
>
>     --Dan
>
>
>         This may well be considered 'out of bounds' for the Classfile
>         API, but I think we should consider it, as it seems to be
>         something that users of the Classfile API will need going
>         forward.
>
>         Gary
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230209/113a5eac/attachment-0001.htm>