3

I'm not well versed in technology but have a problem that maybe you experts could answer. We have a software application that supports our laboratory - obviously must be secure. We want to be able to have outside parties interact with the application through a webmodule that we bought for the application. However our IT folks are concerned because the application currently needs Java 1.6 on the server - and they cite many security vulnerabilities. The vendor indicates they haven't completed testing for any future versions of Java.

This application is in use in many large hospital systems, so finding it hard to believe that vendor wouldn't have addressed this somehow. Its causing some contention and we users are stuck in the middle.

Can someone help me understand - in lay terms if possible:

  1. Is this is a concern?
  2. What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?
  3. Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?
  4. Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Not sure where to begin or who to believe about this... Thank you!

1

Is this is a concern?

I won't say no but one thing to realize is that Java comes with a lot of things that aren't relevant in any context you are likely to see it used. Almost all of the security vulnerabilities in Java are client-side. That is, most are only applicable when you are using Java plug-ins on your browser. Very few of the Java vulnerabilities are server-side. A lot of IT-admin type people fail to understand this and it's possible they are over-reacting.

On the other hand, a small number of vulnerabilities (e.g. one) can allow for pretty significant exploits so there's really no good argument for not working to patch the JVM.

Overall, though, it's likely that your vendor has creared vulnerabilities in their code or have used libraries with vulnerabilities. I would wager it's far more likely those issues will be exploited than JVM/JDK vulnerabilities. This is strongly suggested by the fact that they seem unable/unwilling to retest their code on a new version of Java. Backwards compatability is very well maintained in Java. It's really unacceptable for them to respond in this way. It implies they have very weak development processes.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

Those are good questions to start. You probably need to have some help though. You might want to have someone do a static analysis (their license may forbid this, however) of the system and/or penetration testing.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

I would. It really should not be an issue. They won't need to change any code, to my knowledge. It's unreasonable for them to refuse.

EDIT: I should add, if this is an application that is running on servers that your IT team controls, you can have your IT people install and run the application on an updated JVM without any assistance from the vendor. It's unlikely there will be any issues unless they are doing something goofy but they might use this as an excuse for not supporting the application. There's no need to recompile or anything, an application written using Java 1.6 should run on a 1.8 JVM.

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Yes, in 2013. You can buy extended support, however.

0

Personally, I think you need to hire a security consultancy company to properly cover the security issues here. Your exact security issues will likely be highly contextual, and there are additional regulatory implications in hospitals. That said, I'll try to cover your concerns.

This application is in use in many large hospital systems, so finding it hard to believe that vendor wouldn't have addressed this somehow

Unfortunately, that's pretty common. Speak to anyone who handles IT infrastructure, networks, security, software, etc. in a hospital (or any organisation really) and they'll tell you the same thing - vendors are usually slow to fix problems, and often won't put the effort in for legacy products that are still relied upon.

Is this is a concern?

Most likely, yes. You're putting an out-of-date, insecure framework on the affected systems. Java can be invoked via the browser unless it is properly configured, which potentially allows for remote attacks against the system. Another potential attack vector against the framework is via Java web servers such as Apache Tomcat, which might expose exploitable functionality (e.g. RMI) regardless of what the application does.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

The problem is that, if they're using out of date Java (esp. 1.6 or earlier) then it doesn't really matter what they do to address individual vulnerabilities in their application - the underlying framework itself is broken and they can't mitigate that individually.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

The simple answer is yes. The more complex answer is that you could sandbox off the application server so that, if it were to be compromised, there's a limited level of access that it has back to your internal network, if any. However, if patient data is included (especially any PII) then you've got regulatory requirements to contest with.

The TL;DR is that the vendor should update their code to work with a more modern version of Java. There are two primary ways you can expedite this: offer to pay towards the development time required to do so, or threaten to switch off their service and use an alternative which is more up-to-date.

Another avenue you have is regulatory: assuming you're in the US, tell your HIPAA regulatory body that their software uses a vulnerable framework that results in risks exposure of patient information. If their customer base is large, they may be required by law to update their software or otherwise mitigate any issues.

  • "Java can be invoked via the browser" - on a server? – Philipp Oct 27 '15 at 22:28
  • @Philipp Depends on the config, but don't underestimate what people will do on servers. – Polynomial Oct 29 '15 at 3:30
0

Is this is a concern?

Obviously yes because that is quite an old version of Java before even Oracle buys Sun so your version misses critical security patches.

What questions do I ask of the vendor to determine our specific vulnerability - e.g. if they keep our system updated with critical patches, etc?

The problem is that the whole platform may be troublesome for the reason I stated in the previous question. The ideal solution is to ask the third party company to assess that application within the newest Java version but that is not practical as it will cost you so much both in money and time.

Is the only recourse to insist that the vendor move to 1.8 before we create access into our network from outside entities?

As I said before, it can be the ideal solution: but then, how much time and money will it take?

Is it true that 1.6 is at end of life and therefore no more security patches are generated?

Refer to @JimmyJames' answer (additional link: Oracle Lifetime Support Policies)

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.