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.

lajuette
  • 761
  • 6
  • 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 '14 at 18:46
  • 4
    Convince him that it isn't _your company's_ code he just saw on thedailywtf.com. – Michael Hampton Aug 27 '14 at 18:58
  • 9
    Java had a *rough* year in 2013. There was even a [website keeping track of the 0-day exploits](http://java-0day.com/) 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](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java) this year alone. That is a long way from "secure". – Chris S Aug 27 '14 at 19:02
  • Check out [this](http://security.stackexchange.com/questions/57646/why-do-i-hear-about-so-many-java-insecurities-are-other-languages-more-secure) link for a possible duplicate. If this isn't what you're looking for you can always search "is Java secure" on Google. – Julian LaNeve Aug 27 '14 at 18:42
  • 1
    Java is the world's most widely distributed malware package. The installer even says so. Over 3 billion devices infected by Java. (And contrary to your assertion, Java exploits are not primarily aimed at Microsoft platforms; their value is exactly the opposite - in that they are cross platform threats, and can be used to attack any operating system which has a Java infection on it.) – HopelessN00b Aug 27 '14 at 19:46
  • 1
    @JulianLaNeve: As i pointed out searching for "is java secure" only points me to articles which only deal with the Java browser plugin's problems. But i don't want to consider it here. I'm only interested in defending the use of Java on Servers. Headless servers. – lajuette Aug 28 '14 at 08:28
  • @Iain sadly we are not talking about a company here. Or an organisation with enough funds to aquire new hardware :-/ – lajuette Aug 28 '14 at 08:29
  • 1
    @ChrisS: Where does the number 107 come from? Did you filter out CVEs related to specific software developed in Java? Because i don't care about these, if i don't use this software. CVEs related to the JRE or Java core libraries would be more interesting. How many were there? Swing, AWT and other Frameworks that are not interesting for Server applications don'T count either. – lajuette Aug 28 '14 at 08:31
  • @HopelessN00b I'm talking about security of Java on servers. I don't care about Microsoft platforms. – lajuette Aug 28 '14 at 08:33
  • 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 '14 at 11:59
  • 2
    @MichaelHampton: Can i trigger a bug in the PHP interpreter, the .NET runtime, [your-runtime-here] by feeding malicious data into some application? Sure. But what makes Java more insecure than any other Language? Are those "quite a few of those CVEs" just as severe as bugs in other runtimes or interpreters? – lajuette Aug 28 '14 at 12:39
  • 1
    `But what makes Java more insecure than any other Language?` All the security vulnerabilities and exploits, primarily. – HopelessN00b Aug 28 '14 at 16:25
  • 2
    @lajuette The big difference is the sheer number of reported vulns and the slowness of Oracle in releasing fixes. JVM is a very complex beast in its own right. – Nathan C Aug 28 '14 at 16:30
  • 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 '14 at 17:41
  • @ChrisS: I did click the link and read a few dozen CVEs. About half of these Issues are not relevant for Java applications running on servers. I sorted out everything related to 3rd party software. Also JavaFX and Swing are no concern. – lajuette Aug 29 '14 at 06:58
  • 1
    @NathanC: The slowness of Oracle in releasing fixes - that's a good point. On the other hand: None of the relevant CVEs don't have an exploit published yet. At least none of the ones i read. – lajuette Aug 29 '14 at 07:02

4 Answers4

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.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
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.

David Schwartz
  • 31,215
  • 2
  • 53
  • 82
  • That's exactly what i told my admin. But he won't believe that it's "safe". Hrmph. – lajuette Aug 28 '14 at 09:58
  • 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 '14 at 10:19
  • I'm here to ask the community for some other tools. I don't like my pliers... – lajuette Aug 28 '14 at 10:31
  • The point about RAM is neither here nor there, but also incorrect - if the JVM keeps RAM it doesn't need but is too busy and important to free, the kernel can't use it to cache files, which it does maximally in otherwise free RAM. – Falcon Momot Aug 28 '14 at 23:59
  • 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 '14 at 00: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 '14 at 00:04
  • @FalconMomot Actually, that's not true. Swapping it out is not slow because the OS can swap it out before it's actually under memory pressure, when I/O bandwidth is not scarce. That makes the pages discardable by the time the system is under memory pressure. Modern operating systems do all these things right, they're written by very, very smart people and you can safely assume they don't do stupid things that produce poor performance for no reason. – David Schwartz Aug 29 '14 at 00:09
  • 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 '14 at 00:10
  • It's not complicated. The operating system simply steals the RAM from the process and uses it for some other purpose. That's basically the entire point of virtual memory. The process can think it owns as much RAM as address space it allocated, even if that's more physical memory than the system has. If the process actually has physical RAM, it's because the OS decided that was the best use of RAM. – David Schwartz Aug 29 '14 at 00:12
  • That, and if your application is I/O bound, there isn't a lot of spare I/O bandwidth floating about to use for swapping. I won't pull out any credentials here, but seriously, you either don't know what you're talking about or you're ignoring some really important considerations. Also, the point of virtual memory is to give each process its own address space and obviate the need for segmentation, as well as to allow for paging. But I'd still love to know how you think the kernel can know RAM is free before the application frees it. – Falcon Momot Aug 29 '14 at 00:15
  • And by the way, the answer is page faults. Think about that for a moment, and a disk-bound application, and tell me again that wasteful userspace allocations have zero performance impact. – Falcon Momot Aug 29 '14 at 00:16
  • 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 '14 at 00:18
  • You're missing our point. This answer seems to imply that, after a program calls `malloc()` and writes some data to the buffer it gets back, that the kernel can then use that same space _as disk cache_ before the program `free()`s it! Obviously this can't be so, at least not without serious data corruption, and I'm very confused as to why you're claiming that it is. – Michael Hampton Sep 01 '14 at 17:37
  • 1
    @MichaelHampton That *is* so. That's basically how paging works on every modern operating system. The `malloc` and `free` functions allocate only virtual memory. The backing of that virtual memory with physical memory is at the discretion of the operating system. If a program is using a bunch of RAM, unless it locked things in RAM, it's only because the OS felt that was the best use of physical memory. – David Schwartz Sep 01 '14 at 19:42
  • Then how does the kernel avoid corrupting some program's memory when reusing one of these pages as disk cache? Why don't we hear about this a lot more? – Michael Hampton Sep 01 '14 at 19:49
  • 1
    @MichaelHampton Before it uses the physical page for some other purpose, it unmaps it from that program's memory space. I'm not sure what you mean by "Why don't we hear about this a lot more", we hear about it all the time. The 4,500 questions about "Why is my system using swap space when it has plenty of free RAM" are all about this exact thing. It's using swap space so that it can have a larger disk cache because that's what the OS felt was the best use of physical memory. – David Schwartz Sep 01 '14 at 20:12
  • Now I'm quite sure you've missed an important detail. We're not talking about _unused_ memory. Both the OP and I are talking about memory which the program has already actively stored data in, but has not freed it yet. Are you quite certain that this can be used as disk cache before the program frees it? – Michael Hampton Sep 01 '14 at 20:14
  • 1
    @MichaelHampton Yes, quite certain. The OS can take the physical RAM away from the process before the process releases the virtual memory. That's how paging works. The OS uses physical RAM for whatever purpose it thinks is best. If it's backing a process' mappings with physical RAM (assuming the process didn't lock them), it's because the OS believes that's a better use for that RAM than disk cache. – David Schwartz Sep 01 '14 at 20:32
  • I'm really having trouble imagining _any_ scenario in which the kernel would seriously consider clobbering a program's data. The kernel developers are smarter than that, aren't they? – Michael Hampton Sep 01 '14 at 20:42
  • 1
    The data is not clobbered. It is opportunistically saved to swap *before* the system is under memory pressure. That allows the physical page to be considered discardable until it's modified. This also helps to minimize the I/O demands should the system later come under memory pressure since fewer writes are needed. The disk cache won't be reduced by the outstanding memory allocations unless the OS thinks that's the best use of physical memory. It has choices. (Hence all the "why is my system using swap when there's plenty of free RAM" questions -- it's to make the disk cache bigger.) – David Schwartz Sep 01 '14 at 20:49
  • OK, so you really aren't making [the bizarre claim that it appeared you were making](http://serverfault.com/questions/624527/how-to-convince-my-administrator-that-java-on-a-server-is-not-insecure-per-se/624668?noredirect=1#comment749386_624668). Yes, Linux can swap out a program and use that RAM for disk cache, and that's what you were talking about? – Michael Hampton Sep 01 '14 at 23:04
  • @MichaelHampton I don't see why you think that claim appears bizarre. It's quite straightforward. Unless a process locks something in memory, the OS backs a mapping with RAM only if it thinks that's the best use of the RAM. – David Schwartz Sep 01 '14 at 23:05
  • The last dozen comments were specifically about the unclear thing you said! But since it's been clarified, and the horse is well and truly dead now, I don't think there's any point to beating it any further... – Michael Hampton Sep 01 '14 at 23:06
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.

mfinni
  • 35,711
  • 3
  • 50
  • 86
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).

Giovanni Tirloni
  • 5,693
  • 3
  • 24
  • 49
  • 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 03 '14 at 17:56