[External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

[Ron Pressler]

On 28 Apr 2023, at 20:14, Eirik Bjørsnøs <eirbjo at gmail.com<mailto:eirbjo at gmail.com>> wrote:

>    Agents are used by profiling tools to instrument Java applications,
>    but agents can also be misused to undermine the integrity of the
>    Java Platform.

I don't think it is fair to assume that profilers are the only "valid"
use case for agents and imply that all other use cases are a mis-use
of the API.

First, I don't read the JEP as implying that all non-profiler use cases are misuse.

Having said that, I do think that agents can in fact strengthen the integrity of the platform. Case in point is that when the Java serialization vulnerabilities hit around 2015, I could very quickly ( a few hours) whip together the "NotSoSerial" serialization firewall agent [1] to efficiently prevent exploits. I later got word that a large CMS vendor deployed it to their platform which included some of the world's busiest websites. I don't know if they used the attach mechanism to plug their serialization holes, but they surely could at the time.

With microservices gaining popularity over the years, restarts are probably more common and automated now, including configuration of JVM options. So attaching to long-running instances to prevent restarts is probably becoming less useful over time.

The agent misuse that the JEP is referring to here is perhaps mostly concerning libraries using the attach mechanism to get access they otherwise would not have in a running JVM? Perhaps the JEP could be updated to be more clear on this?

Cheers,
Eirik.

[1] https://github.com/kantega/notsoserial/<https://urldefense.com/v3/__https://github.com/kantega/notsoserial/__;!!ACWV5N9M2RV99hQ!N8oN0PnS91PqZc8Bs_d5cOcHeV61_9P5AcNXC7zRaeaykTQiWKD2gqxnONwng9pKA92IVDQ7ilqZ9bQ$>



Keep in mind two things:

1. Dynamically loaded agents are more limited in their capabilities than agents loaded at startup because redefinition/retransformation is limited to changing the body of existing methods. Redefinition can only fix issues if you’re lucky.

2. Java offers no general mechanism to make patches applied through redefinition persistent. They are reverted at the next startup.

Due to these two facts, patching code in production to change its logic (as opposed to benign instrumentation with profiling events) has never been a sanctioned usage of dynamic agents. It’s simply not a generally-effective mechanism for that. Tools that offer less restricted dynamic patching (e.g. JRebel) require an agent *loaded at startup*.

— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20230501/7efe3a43/attachment.htm>