13

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:

  1. Java applications eat up all my RAM
  2. 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.

Improve this question
16
  • 7
    If the hardware it's on is demonstrably underpowered and causing problems then along side the SA's concerns surely you have a business case for getting new hardware.
    – user9517
    Aug 27, 2014 at 18:46
  • 4
    Convince him that it isn't your company's code he just saw on thedailywtf.com.
    – Michael Hampton
    Aug 27, 2014 at 18:58
  • 9
    Java had a rough year in 2013. There was even a website keeping track of the 0-day exploits as they just kept rolling out. Since the middle of last year there haven't been any 0-day exploits, but researchers still have found 107 Java CVEs this year alone. That is a long way from "secure".
    – Chris S
    Aug 27, 2014 at 19:02
  • 5
    Can I trigger a JVM bug by feeding malicious data to your application? You better believe it. And quite a few of those CVEs relate to running Java on servers, not the usual Windows desktop browser plugin.
    – Michael Hampton
    Aug 28, 2014 at 11:59
  • 3
    @lajuette I provided a link with the 107 number for a reason - if you had clicked it all those Questions you just asked would have been answered. Some of those 107 are related to non-Oracle implementations, like Android's Dalvak, but the vast majority are related to the Oracle implementation. Java is not inherently insecure, but Sun/Oracle's JRE is riddled with problems. PHP, Perl, Ruby all have vulnerabilities too - none of them are perfect. I couldn't say if Java is better or worse that those currently, but over the last year it's definitely been the whipping boy of the security industry.
    – Chris S
    Aug 28, 2014 at 17:41

4 Answers 4

Reset to default
18

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.

Improve this answer
6

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.

Improve this answer
23
  • 3
    Okay, so reason doesn't work. What other tools are in your persuasion toolbox? Do you have any rusty pliers?
    – David Schwartz
    Aug 28, 2014 at 10:19
  • 1
    @FalconMomot Yes, the kernel can use it to cache files. The kernel can take memory away from the JVM if it has a better use for it. That's how pretty much every modern OS works. The alternative to using RAM is wasting RAM. The OS has a memory manager specifically to ensure RAM goes to the best purpose. Arguments like "Java applications eat up all my RAM" almost always indicate an admin who doesn't understand how modern operating systems use RAM.
    – David Schwartz
    Aug 29, 2014 at 0:00
  • 1
    If the JVM doesn't free the memory, it has to swap it out to the swap space (if it has any) to do this, which is slow. The kernel can't invoke the garbage collector. Also, file caching is typically lower priority than userspace allocations even if they are rarely utilized (as much as the kernel can tell that they are rarely utilized, which is not very well).
    – Falcon Momot
    Aug 29, 2014 at 0:04
  • 3
    I want to know more about how Linux can simultaneously use a block of RAM for cache while a process still thinks it owns it. I've never heard of this before.
    – Michael Hampton
    Aug 29, 2014 at 0:10
  • 1
    @FalconMomot The kernel doesn't need to know the RAM is "free". The kernel always has control over the use of RAM unless the application locks pages. It just has to make the mapped pages discardable to get the RAM back. If the data is unmodified and unused for a period of time, and I/O bandwidth isn't saturated, it can opportunistically write it to swap, making the pages discardable, allowing it to reclaim the RAM as soon as it has a better use for it. (This space isn't large enough to explain how modern memory management works, but it seems like you have some very common misconceptions.)
    – David Schwartz
    Aug 29, 2014 at 0:18
2

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.

Improve this answer
1

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).

Improve this answer
1
  • Thanks. We are not talking about a company. Rather a non-profit association. Out sysadmin has a doctor in IT & marketing, but isn't a "real" sysadmin. And yes: i believe he's afraid of Java, which he doesn't fully understand.
    – lajuette
    Sep 3, 2014 at 17:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .