0

We have an agent application deployed to some internal web servers that runs on java, and installs a specific JRE to use. The agent updates regularly and installs updated JRE versions to use, but doesn't remove the old files.

Our security team gets a notification that this in insecure even if secure versions are installed and in use - specifically: https://www.tenable.com/plugins/nessus/92517

What kind of risks are there to having old JREs installed, even if not in use by any application?

To clarify: my understanding is that Java exploits target running processes, applications or the jre/jdk installers, and that the JRE files aren't more or less insecure than any other programming language's source files. Is there an attack vector in which having JRE files on a box is more dangerous than having bash installed?

  • 1
    "even if not in use by any application" Well, the obvious counter-question becomes: If they are there, how do you guarantee they are not used by anything? – a CVn May 14 at 14:02
  • 1
    Insecure apps are backdoors waiting for exploitation. – mootmoot May 14 at 14:31
  • Why cannot you remove or uninstall the unused versions? – A. Hersean May 14 at 15:36
  • 1
    We are cleaning these files up, but only because they're unnecessary - I'm curious why they warrant "Critical" or "High" security threats – user19702 May 14 at 15:38
0

If it's literally code that's sitting on the server, but is never executed, the risks are mostly one of miss-configuration. Unless the java code has some special privileges assigned to it, or special location, I don't see how it's any different from any other executable that shouldn't be running. If the attacker can execute this exploitable java code, can they, as you say, execute bash? If they can do that, it's not java's fault, it's the attack vector that lead to code being executed that shouldn't be.

I wouldn't dismiss the miss-config issue however. If you've got 10 versions of Java sitting around, and 8 of which are compromised in some way, it's possible that someone could miss configure the server to use the old exploitable code. It might be an emergency situation where they tried a different jvm, or just an honest mistake.

But if I were making the call, I'd classify it as "high", not critical. I'd also make sure it gets fixed, or mitigated.

  • Thanks! It makes sense to me, and we do have some other cleanup cases where miss-configuration may be more likely. This helps me prioritize better. – user19702 May 14 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.