How to convince my Administrator that Java ON A SERVER is not insecure per se?

The Application

We have a small Java application which uses some Camel routes to pick up uploaded files from a webserver, process them and send out some e-mails with the results.

The server on which this application was running has been decomissioned. For now we have to run it on underpowered hardware, because i can't convince out admin to install a JRE on the webserver (which is in fact a multi purpose server).

The Fear

I am a Java Application Engineer myself, I write JEE code for a living, handling B2B transactions worth tens of thousands of €uros per week. But i have problems finding credible sources that refute the myth that java is insecure per se.

The admin's two main arguments against installing a JRE:

Java applications eat up all my RAM
Java is full of vulnerabilities

The Truth?

When it comes to java applications eating up ram. Well... I'd say we have to set proper values for Xmx. Done.

Now there are a lot of sources talking about the many vulnerabilities of Java. These sources are mostly aiming at end users running a certain operating System from a company in Redmond/USA. AFAIK it may be true for unpatched versions of the Java Browser Plugin which is configured to execute all applets automatically, that there are quite big chances of being the victim of a drive by infection. Just as there's a risk of catching an STDs when having unprotected sex with eveyone on your train while commuting to work.

But i couldn't find anyone on the world wide interwebz who talks about server applications or JREs running headless. That's a whole other thing.

Or am i missing something here?

[edit 2014-08-28] clarification: I'm only concerned about Java on servers. I don't care about problems with the Java Plugin and/or specific software developed in java.

Solution 1:

The additional security surface java puts into your environment is complex, and it's important not to ignore it or try to simplify it away.

Firstly, there is the horrible record the JRE has for having security bugs. It's hard to point out a specific one, and this is the scary part - the bugs are overwhelmingly unspecified vulnerabilities with unspecified vectors.

When I, as a security consultant, read clauses like "allows a remote attacker" without further qualification as to their meaning, I see that it could very well mean that certain parameters getting into a certain function might invoke the vulnerable condition, even if you are running only code you wrote. And, since they're unspecified, you don't get to know whether you were affected.

Even better, the canonical JRE published by Oracle has a stated quarterly update cycle for critical updates, including almost all security updates. They have created out of cycle patches a grand total of 11 times in the past four years. This means that there is a possibility you might be vulnerable to a security bug up to three months after it is reported before you have any way to fix it.

There are other problems with java that I won't get into here, but really, it seems like there is a justifiable concern, especially for a multi-purpose server. If you have to run such things, you should at least make a single-purpose VM for it and isolate it from other things.

In particular, if there is a remote in the JRE that allows an attacker to gain RCE, and another one in PHP that does the same, and another in Ruby that does the same again, you have to patch all three. All three seem somewhat likely, as these things go, and the attacker gets to pick whichever is most convenient and then own the whole server. That's why we should use VMs to separate software, especially buggy software like managed language frameworks, and especially those that bundle security patches only four times a year and are proprietary to a vendor who asserts in the face of all evidence that they are a paragon of security.

To update, here are some CVEs I cherry-picked from ChrisS's linked CVE search, by way of demonstration.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5884
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5910
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5456
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3007
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2454
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2447
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1557

And my favourite, since I was there:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

That's just a small sampling, by the way.

Solution 2:

Java applications eat up all my RAM

The alternative to using RAM is wasting RAM. You can't save it for later.

Java is full of vulnerabilities

That doesn't really matter because you aren't going to expose the JVM to the world. I presume you aren't going to run any hostile programs, and if you are, Java is safer than most other languages. What matters is whether your applications have vulnerabilities.