108

I really like the Java programming language, but I continuously hear about how insecure it is. Googling 'java insecure' or 'java vulnerabilities' brings up multiple articles talking about why you should uninstall or disable Java to protect your computer. Java often releases a huge number of security patches at a time, and yet there are still tons of vulnerabilities left to patch.

I understand that there will always be bugs in software, but the amount of vulnerabilities Java has had does not seem normal (or am I imagining that?). What's even more confusing is that if there is a single architectural decision that is creating these vulnerabilities, why not change that design? There are tons of other programming languages that don't have this problem, so there must be a better way to do whatever Java is doing wrong. So why is Java still so insecure?

dimo414
  • 231
  • 1
  • 8
gsgx
  • 1,215
  • 2
  • 12
  • 13
  • 35
    I find it really unfair that some people claim java would be "insecure" because its sandboxing concept has a few flaws while most other technologies don't even have sandboxing and allow programs to do virtually anything they want on the machine they run on. The critique is only justified in the really narrow use-case of applets run in a web browser, where the alternatives like Flash have a security track record which is just as bad. – Philipp May 10 '14 at 14:16
  • 32
    Your question similar to asking "Why do cars still have engine problems?". (And for those who come from the angle of "C(++) does not have these!", add "My bicycle never has any!") – Raphael May 10 '14 at 15:46
  • 22
    Because it was bullied as a child. – TylerH May 10 '14 at 17:28
  • Java has had relatively few security vulnerabilities for a full fledged programming language that is capable of running in a browser (most other browser-capable languages are, by design, not capable of doing certain things). -- The vulnerabilities you have heard about recently are entirely malicious applications (read Applets) finding a way to break out of the sandbox and execute arbitrary code on your system. There could be an argument that Applets are a part of java that should be put to rest, however many technologies still rely on them (IMPI Consoles, bank websites, etc). – SnakeDoc May 10 '14 at 21:06
  • 9
    @Philipp: I don't think it's unfair at all. If a language is promoted as sandboxed, but its sandbox has a history of tens to hundreds of critical vulnerabilities every year, it's perfectly fair to condemn it as insecure. Security is not an absolute thing but a matter of living up to the published contract. Perhaps it's not fair to compare Java and C++, but it's certainly fair to compare Java and Lua. If I'm not mistaken, the latter has not even passed the single-digits for sandbox-escape vulnerabilities. – R.. GitHub STOP HELPING ICE May 12 '14 at 12:52
  • @R.. The sandboxing only applies to a very narrow context, and that's java applets in web browsers. When you want to say that these are insecure, I wholeheartedly agree. But as you can tell from this question, many people extend this critique to Java in general, which covers use-cases where the sandboxing problems of applets do not matter at all. – Philipp May 12 '14 at 13:12
  • @R.. The comparison Java to Lua isn't fair either, because Java is a general-purpose language with a huge standard library which includes everything but the kitchen sink while Lua has a very tiny standard library and is meant to be embedded in a host application which adds domain-specific script bindings to lua which might or might not be secure. – Philipp May 12 '14 at 13:18
  • My opinion is that it's perfectly fair, because a huge standard library implemented outside the sandbox essentially precludes the ability to offer a secure sandbox environment. This is one of the things Java got horribly wrong that Lua got right. – R.. GitHub STOP HELPING ICE May 12 '14 at 13:20
  • I agree that "Java the language" gets a lot of negative publicity from "Java the sandbox" being so broken. Whether this is "fair" or not is a judgement call, but it's a consequence of the marketing decision to closely couple the two. On most systems merely installing Java (for whatever purpose) also installs browser components that expose the system to critical remote vulnerabilities if the browser is used, so it's fair to say that simply having Java installed, unless you've gone out of your way to block its use in the browser, is a security problem. – R.. GitHub STOP HELPING ICE May 12 '14 at 13:30
  • 4
    @R.. A company I worked for used LotusNotes purely because few people used it and so the security flaws it certainly had (like everything) remained undetected. I fear java is on the opposite side. Any flaw it has will be discovered, doesn't mean other less widely used things are more secure, there are just less people trying to crack them – Richard Tingle May 12 '14 at 14:15
  • 1
    @R.. "it's certainly fair to compare Java and Lua. If I'm not mistaken, the latter has not even passed the single-digits for sandbox-escape vulnerabilities." By that argument, we really all ought to be using PostScript, since it has had even fewer such vulnerabilities. (PostScript does in fact offer sandboxing, and if correctly configured can allow you to execute hostile code with impunity, FYI) (If you don't quite get what I am saying, it is that Java has more discovered vulnerabilities because Java is used far more often than Lua.) – AJMansfield May 13 '14 at 01:40
  • Actually PostScript historically has quite a few vulnerabilities, especially when you consider the environment it's meant to be used in. And any Turing-complete language is a DoS vulnerability in the context of what PostScript is meant for (documents), especially when you're running it on 1MHz microcontrollers inside printers. – R.. GitHub STOP HELPING ICE May 13 '14 at 10:31
  • As for Java vs Lua, it's not a matter of how much they're used. It's a matter of design. Lua has a tiny number of points of potential failure (one of them was an idiotic one: allowing Lua code to feed bytecode straight to the virtual machine). Java has an astronomical number. – R.. GitHub STOP HELPING ICE May 13 '14 at 10:32
  • Obviously for (white-hat)-hackers, investigating in Java vulns is more interesting than in the others language, this is like what Windows is for others operating systems. – elsadek Oct 15 '14 at 14:56
  • Maybe you can clarify what the context of your statement is. It seems like you are stating that you feel that the Java code may need to fixed and that the software maintainers are not doing a good-enough job? Every application will have its own applicable code-type to be implemented so relying on any one set of coding practices should be avoided. I bet that client-side Java applications will go by way of Flash and soon die-off. –  Aug 12 '15 at 21:25
  • Hah, talk about unfair: we are developing a browser in Java, and people mistake it with applets, or associate it with Java which they mistake with applets, or they associate the security-manager sandbox with the more specific applet sandbox... and so on. – HRJ Sep 27 '15 at 04:23

8 Answers8

124

If you use Java like most other programming languages, e.g. to write standalone applications, it is no less secure than other languages and more secure than C or C++ because of no buffer overflows etc.

But Java is regularly used as a plugin inside the web browser, e.g. similar to Flash. Because in this case the user runs untrusted code without having explicitly installed it, the idea is to have the code run inside a limited sandbox, where it should not be able to somehow act against the system or the user (e.g. read local files and send them to the website, scan the local network etc). And this is where Java failed in the recent years, e.g. new bugs popped up sometimes on a daily basis which allowed escaping from the sandbox.

Also, sometimes bugs in the byte code interpreter or native libraries lead to buffer overflows and could compromise the system, but in this regard Flash is usually considered worse.

And as for the other languages being better: these usually can't even run as untrusted code inside a sandbox (exception is JavaScript and maybe Flash), so they would be even worse because there is no inherent way to limit their interaction with the system.

Oli
  • 1,121
  • 9
  • 13
Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
  • 1
    So server and desktop Java applications have less vulnerabilities than Java applets? – gsgx May 09 '14 at 18:30
  • 19
    Yes, the major security problem is only the sandbox. – Steffen Ullrich May 09 '14 at 18:33
  • 9
    No stackoverflows? I accidentally triggered one just today with infinite recursion. Did you mean buffer overflow? – Lekensteyn May 09 '14 at 19:13
  • 8
    Yes, I mean buffer overflows. Thanks for correcting. And you can still get them but not as omnipresent as in C,C++. – Steffen Ullrich May 09 '14 at 19:14
  • 2
    Java on the server lets Oracle sell database licences etc, however java applets don’t make sense to Oracle’s business therefore don’t expect Oracle to make more than manual effort to short out vulnerabilities related to them. – Ian Ringrose May 10 '14 at 10:26
  • 6
    @IanRingrose Don't agree. Oracle is not bound by shareholders to perform more than minimal maintenance, but up to now they seem to have taken vulnerabilities rather seriously. As indicated, vulnerabilities are reflected upon the whole system, and Webapp applications and Applets are usually backed up by server applications in Java. In general I don't think there is no indication that Oracle does not take these failures seriously. Also note that developers themselves often have a strong feeling of responsibility, regardless of the company itself. Black/white statements are useless here. – Maarten Bodewes May 10 '14 at 15:32
  • @Lekensteyn The Java language specifications demands that implementations detect stack overflows and throw an exception. In C/C++ it's just undefined behavior with all that entails. So to some degree "stack overflows" still works as well there. – Voo May 10 '14 at 18:04
  • @SteffenUllrich to elaborate -- it's because the sandbox is attempting to contain/limit the capabilities of a full-fledged programming language. Unlike some of the other browser-enabled languages which were designed initially without certain capabilities (ie. doesn't matter if you break out of the sandbox because you still can't do certain things). So long as a full-fledged programming language is running in your browser, there will be a possibility for it do things to your local system. Java Applets are very powerful still today (IMPI Consoles, etc). – SnakeDoc May 10 '14 at 21:14
  • 3
    Your equation of Java applets and JavaScript is false. JavaScript is an intrinsic browser feature, and Java requires an explicit, seperately installed plugin. A JavaScript exploit in one browser is not the same as the other, but an applet exploit works everywhere because the plugin is the same everywhere. Furthermore, JavaScript is not designed to provide operating system features in most browsers and can be sandboxed in different ways (prevent native code execution). It's better to equate Java and Flash. – DCKing May 11 '14 at 10:51
  • 1
    *Big groan* regarding the "e.g. similar to JavaScript". Just putting them in the same sentence is begging for confusion; they're really nothing alike and JS really doesn't work like a plugin. I've just read all the comments now... What @DCKing said. – Oli May 12 '14 at 15:38
  • 1
    @DCKing: Javascript actually isn't as intrinsic to the browser as you might think; Javascript interpreters like Rhino, SpiderMonkey, and V8 actually can run independent of the browser they're normally attached to. There do exist some sort of plugin interface between the host application (not necessarily a browser) and all these popular Javascript engines. – Lie Ryan May 13 '14 at 20:08
  • 1
    @LieRyan That's arguing semantics. Each major browser uses a different JavaScript implementation and attackers require different vulnerabilities for each of them. Plugins are the same everywhere. That's the point. – DCKing May 15 '14 at 12:57
83

The security vulnerabilites reported are not about Java (the programming language), which, by virtue of the JVM enforcing memory safety, is actually more robust than languages such as C or C++, where buffer overflows and buffer over-reads remain a threat, and can result in messes like Heartbleed.

Instead, the vulnerabilites reported are in the Java Sandbox, which attempts to enforce a priviledge model that permits safe execution of untrusted code, and is most famously used to permit the automatic execution of Java Applets in a browser. That sandbox is riddled with holes. Also, Oracle releases patches (the "critical patch updates") only 4 times a year. Needless to say to browser vendors are not happy about this. Firefox, for instance, is requiring user authorisation to launch a Java Applet since Firefox 26.

The reason the press reports do not make that distinction is that Oracle uses the "Java" trademark both for the programming language, and the browser plugin that runs applets. In fact, if an ordinary user encounters the Java trademark, it probably refers to the latter.

It is somewhat speculative why exactly the Sandbox remains vulnerable. If you ask me, one reason is that the same API is used both with and without the Sandbox, and most Java code runs without the Sandbox (because the code is trusted). As a result, it is quite possible for a developer to forget about that obscure feature when changing the Java API or its implementation, accidentally exposing things that should be protected (to illustrate how easy that is, behold the lengthy Secure Coding Guidelines for Java SE). Another but related reason is the sheer size of the Java API (5800 classes, and nearly 50,000 methods, for Java SE 6).

meriton
  • 1,488
  • 1
  • 10
  • 13
  • 4
    IMHO this is the best answer, as it touches the complexity of securing an API that tries to do everything. A fully walled up version of Java for applets (no IO) would provide a lot of relief, but the current API is just too tightly coupled for that. – Maarten Bodewes May 10 '14 at 15:39
  • 3
    Only beefs I have with this answer is that 1) Heartbleed was not the result of a buffer overflow attack. 2) You also cannot say that a language coupled with a virtual machine is 'better' than another language by itself, for obvious reasons. Other than that, good note about the real holes being in that sandbox, a programming language is no more 'safe' or 'unsafe' than a human language, it all boils down to a compiler or interpreter, and most important: The person using the language. – MDMoore313 May 12 '14 at 13:42
  • 1
  • Ok, according to Wikipedia, Heartbleed was a buffer over-read rather than a buffer overflow, as the access beyond the buffer length was a read access rather than a write one. Will fix the terminology. 2) I think that is a valid comparision, as the Java Language Specification mandates that the runtime environment performs this check. In Java, memory safety is a language feature. In C or C++, it isn't.
    • – meriton May 12 '14 at 17:50