On 28 Apr 2023, at 20:14, Eirik Bjørsnøs 
<eir...@gmail.com<mailto:eir...@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

Reply via email to