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.
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.
And my favourite, since I was there:
That's just a small sampling, by the way.
The alternative to using RAM is wasting RAM. You can't save it for later.
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.
Hire a company to do static analysis on your program. Veracode, for example, is a company that I have used in the past for auditing code security of Java programs, specifically.
Bill your admin team's charge code, obviously.
Explain that all other languages (or virtual machines) can be rendered insecure by the code that is deployed onto them, just as with Java. If he thinks the other platforms are inherently secure (or more secure than Java) without correctly address security, then he is delusional.
Your company obviously invested in hiring a Java developer, why is the sysadmin refusing to support a technology that the company decided to use?
I would flip the question and ask him what alternatives he proposes and how they are more secure than the latest Server JRE available, in very specific terms. In the mean time, work to show you understand your technology, the possible attack surface and that you've worked to minimize it (e.g. unnecessary frameworks, 3rd-party code, etc). Have your code verified, look for vulnerabilities published for the frameworks you rely on in the last X years, compare it to other languages/frameworks (make sure to include marketshare too, obscure frameworks without published vulnerabilities mean nothing).
We can't possibly know how the whole conversion between you two happened but if that were his two arguments, I believe you are dealing with a junior system administrator. Does he have experience with Java application servers? Perhaps he is uncomfortable with the technology and afraid to put something in production without thoroughly understanding it (good sysadmin attitude then).