2

It seems like there's a new major security hole patched in Java every other week, and I would assume the same goes for other development platforms. After years of frustration trying to get customers to install and configure a compatible JRE on their systems, we started bundling one with our software. (By bundling, I mean we extract a copy of the JRE in our installation directory--we don't install the JRE and configure it as the system default.)

The problem is, it's a hassle having to keep that JRE up-to-date because first we have to retest everything to make sure the update didn't break anything (it has broken some of our third-party dependencies in the past).

How seriously, if at all, are we putting our customers at risk if we don't update our SDK/JDK and the runtime/JRE that we bundle with our product every time there's a security update? Is it reasonable to just update on a periodic schedule--say, once every 6 months or so?

jacktrades
  • 113
  • 7
rob
  • 306
  • 2
  • 11
  • 1
    I don't think that updating JDK minor revisions will cause problems. When you go from JDK 6 to 7, that might cause problems. – jacktrades Oct 18 '13 at 17:20
  • I'd assume you are risking whatever security problem they are fixing being exploited... – Rig Oct 18 '13 at 17:24
  • 1
    Generally updating to a new minor version does not cause problems, but we still have to thoroughly test everything nonetheless *just in case*. – rob Oct 18 '13 at 17:25
  • @Rig but how likely is it that security hole can be exploited if the JRE is not configured as a system-wide JRE? (it isn't in add/remove programs so it isn't the default and can't be queried) – rob Oct 18 '13 at 17:27
  • @rob That is going to be really dependent on the security flaw and whether the JRE is actively running or not at the moment. Its a tough question to answer in general. – Rig Oct 18 '13 at 17:29
  • @rob, Which is the OS of your customers? – jacktrades Oct 18 '13 at 17:31
  • right click on the Java update notification and click `disable updates`. Problem solved. – Reactgular Oct 18 '13 at 17:31
  • Related: [Considerations on which Java version to run in Production](http://programmers.stackexchange.com/questions/183982/considerations-on-which-java-version-to-run-in-production). Realize also that some systems (finance, point of sales, etc...) may require a frequent update schedule. –  Oct 18 '13 at 19:21
  • @jacktrades Almost all Windows, with a handful of Linux customers. – rob Oct 18 '13 at 20:02
  • 1
    @MathewFoscarini thanks for the suggestion, but the update notification is not relevant for a bundled runtime. – rob Oct 18 '13 at 20:04
  • @rob I was being sarcastic. http://www.wikihow.com/Deal-With-a-Sarcastic-Person – Reactgular Oct 18 '13 at 21:02
  • 1
    @MathewFoscarini do you have a link to an article on how to differentiate between someone who's being sarcastic and someone who seems like they're trying to help but missed some details in the question? ;) – rob Oct 18 '13 at 21:49

1 Answers1

3

That depends on the nature of the security holes and that of your application.

The most popular and major ones that have been fixed are related to applets. This is to say that there's some hole in the Java stack (JVM, native libraries, Java libraries, etc.) that allows an applet to access e.g. files on disk, to run a process, the kind of things that applets shouldn't be able to do.

If your application is a desktop application, I believe there is very little risk involved for a 6 months update interval. Most of the times, the kind of holes in desktop applications is tied to operating system holes, such as allowing a lower privilege application access a window from a higher privilege one. Or similarly, an application running in non-administrator being able to access an administrator's application windows and process address space.

On the other hand, another application that the user runs with as much privilege as yours can do just about anything. Messing around with your application is not really the worse of things I can imagine, unless it can launch missiles or withdraw money.

EDIT: If your application is a server, then again some of the nasty vulnerabilities might pose a greater risk. We never know. Maybe there's something in Java's sockets that allows remote code execution, and so you'd consider this to be very high risk compared to delegating the update burden to your client.

acelent
  • 429
  • 2
  • 8