CODEWITHSUNDEEP
javacve
Brad Parks
Brad Parks

Reputation: 71961

Block instances of a class at the JVM level?

Is there a way to configure the JVM to block instances of a class being created?

I'd like to do this to ensure no service running in the JVM is allowed to create instances of a class that has been identified as a security risk in a CVE, lets call that class BadClass.

NOTE: I'm looking for a general solution, so the following is purely additional information. I would normally address this by switching the library out, or upgrading it to a version that doesn't have the exploit, but it's part of a larger library that wont be addressing the issue for some time. So I'm not even using BadClass anywhere, but want to completely block it.

Upvotes: 0

Views: 253

Answers (3)

Boguś
Boguś

Reputation: 150

Have you considered using Java Agent?

It can intercept class loading in any classloader, and manipulate it's content before the class is actually loaded. Then, you may either modify the class to remove/fix it's bugs, or return dummy class that would throw error in static initializer.

Upvotes: 0

supernova
supernova

Reputation: 2070

I do not know a JVM parameter, but here's some alternatives that might pout you in a position that solve your requirements:

  1. You can write a CustomClassLoader that gives you fine control on what to do. Normal use cases would be plugin loading etc. In your case this is more security governance on devops level.

  2. If you have a CICD pipeline with integration tests you could also start the JVM with -verbose:class parameter and see which classes are loaded when running your tests. Seem a bit hacky, but maybe suits your use case. Just throwing everything into the game, it's up to you judging about the best fit.

  3. Depending on your build system (Maven?) you could restrict building applications just on your private cached libs. So you should have full control on it and put a library - review layer in between. This would also share responsibility between devs and the repository admins.

Upvotes: 2

GhostCat
GhostCat

Reputation: 140427

A distinct non-answer: Do not even try!

What if that larger library that has this dependency wants to call that method? What should happen then?

In other words, what is your blocking supposed to do?

  • Throw some Error instance, that leads to a teardown of the JVM?
  • Return null, so that (maybe much later) other code runs into a NPE?

Remember: that class doesn't exist in a void. There is other code invoking it. That code isn't prepared for you coming in, and well, doing what again?!

I think there are no good answers to these questions.

So, if you really want to "manipulate" things:

Try sneaking in a different version of that specific class into your classpath instead. Either an official one, that doesn't have the security issue, or something that complies to the required interface and that does something less harmful. Or, if you dare going down that path, do as the other answer suggests and get into "my own classloader" business.

In any case, your first objective: get clean on your requirements here. What does blocking mean?!

Upvotes: 2

Related Questions