109

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,225
  • 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](http://docs.oracle.com/javase/8/docs/api/allclasses-noframe.html) while Lua has [a very tiny standard library](http://www.lua.org/manual/5.2/) 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](https://github.com/UprootLabs/gngr), 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

125

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
  • 184,332
  • 29
  • 363
  • 424
  • 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
84

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,449
  • 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
    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](http://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.10.4) 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
11

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.

That's a pretty high claim, where did you get that impression? There are "tons of other programming languages" that haven't been put through the same paces as Java, or are used as ubiquitously.

In principle, the reason there are so many security patches is because Java was designed to be secure, with a number of security-focused features that other languages don't have.

The Java Language Environment

1.2.2 Robust and Secure

Java technology is designed to operate in distributed environments, which means that security is of paramount importance. With security features designed into the language and run-time system, Java technology lets you construct applications that can't be invaded from outside. In the network environment, applications written in the Java programming language are secure from intrusion by unauthorized code attempting to get behind the scenes and create viruses or invade file systems.

If you don't include "be secure" in the specifications for your programming language, you'll rarely have to release security patches. If, on the other hand, that's one of your stated goals, you'll be hard pressed not to.

Community
  • 1
dimo414
  • 231
  • 1
  • 8
10

By itself, Java has great assets for security, namely its inherent resistance to buffer overflows and memory management errors:

  • All array accesses are checked with regards to allocated array length. Buffer overflows are thus reliably trapped, and trigger an exception, which is better (this turns remote code execution vulnerabilities into mere denial-of-service).

  • Memory allocation is managed through a garbage collector, which prevents use-after-free and double-free errors. Also, the GC allows for an easier handling of character strings (strings are immutable in Java), which removes most occasions for buffer overflow bugs.

  • Strict typing is enforced; code cannot access data bytes for what they are not. This again prevents vulnerabilities (bugs where data types are transgressed will be reported at compilation or, at worst, as a runtime ClassCastException).

This makes Java much stronger than many programming languages (in particular the infernal couple C/C++) when it comes to security.

However, the Java designers tried to leverage this enhanced security to make something hard, i.e. applets. The problem is attack surface: since the applet is potentially hostile code, everything it does must be controlled. But the hostile code must be able to use the "standard Java classes" if it is to do anything, so "control points" must be enforced on every single standard Java class. The attack surface thus consists of hundreds of classes containing thousands of methods, and all of them must enforce adequate checks.

The Java designers sinned by ambition: the difficulty of implementing thousands of checks without botching any was much higher than what they imagined. All the "Java bugs" come from this fact.

We can compare Java with Javascript here; for instance, Java allows access to files on disks, but this right must not be granted to applets, except if the applet asked for it and the user agrees (which entails the whole applet signing business). Javascript, less ambitious, simply lacks any file access method: access controls on a function cannot be implemented improperly if the function does not actually exist !

To sum up: Java is fine and secure. Java applets imply a huge attack surface whose security is very hard to ensure. For stand-alone applications and servers, though, using Java is a good idea if you want security (this equally applies to C#).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    Nitpick: It's more like thousands of classes, and tens of thousands of methods. Other than that: Great answer! – meriton May 16 '14 at 20:20
4

These days, finding more vulnerabilities may not imply how insecure the software is. The problem is how the security response team of each software vendor reacts to it and how quickly the patches are coming out.

Just check how fast Firefox and Chrome are get patched. Many vulnerabilities are found on them also and resolved.

As I remember, Oracle has a program called Critical Patch Updates (CPU) which gives lots of patches quarterly. They also release patches without CPU if there is a zero-day vulnerability out there. But the problem is the time taken by Oracle to release a patch.

Peter Mortensen
  • 877
  • 5
  • 10
Kasun
  • 784
  • 2
  • 5
  • 13
  • 3
    I agree with the first sentence. Not *finding* security holes in other software does not mean there are none -- are people looking (as closely)? – Raphael May 10 '14 at 11:04
2

Overrated fear .. Java itself is fine; the problems occur with old-school Java-Applets running within web browsers, but I doubt anyone actually creates Applets anymore - most development houses have used Flash or HTML4/5 for front-end web interfaces for at least the last 10 years.

These days Java is mostly used for backend JEE, front-end GUI clients (JFX/AWT/SWING), console apps, and mobile apps - hence there is no issue.

John
  • 21
  • 1
-2

I disagree with everybody.

No, Java is not a Secure Programming Language: https://littlemaninmyhead.wordpress.com/2021/01/28/no-java-is-not-a-secure-programming-language/

Java was good for its time. It fixed up problems like buffer overflows that other language such as C had. But it never evolved.

Nowadays, 'insecure by default' is expected in a programming language. Java fails here miserably, and they never update it to fix the problems. In combination with poor documentation that does not tell the proper way to use security functionality, the language is filled with security booby traps.

TheGreatContini
  • 171
  • 1
  • 6
  • 1
    You need to disclose your relationship to the links you provide. The link is to your blog. And include the relevant parts of the link in your answer here. – schroeder Jan 29 '21 at 22:20
-4

The answer is quite obvious. Can you delete your computer files using JavaScript, HTML or Flash? No, you can't.

What about Java. Can you delete all your files, completely wipe your hard drive using a Java applet (hosted on a web site)? The answer is yes, if you accept running the applet. Unlike any other web browser language.

Java has the ability to do things like execute programs on your computer (executables) and also has the ability to write, update or delete files on your hard drive.

Also, Java applets are not detectable by virus scanners: In most cases, you won't even know it screwed up your computer. Some scanners may detect that something is trying to delete files in a restricted directory: One I know is Kaspersky, but most people have this feature turned off by default.

Java applets can do things such as update Windows files, like HAL.dll, which will prevent your computer from booting. It can do anything to your computer when you accept to run the applet.

In some cases it doesn't even matter if a Java applet is signed or not signed - it will still download files on your computer.

Not to mention Java is very popular.

There's another one that's growing in popularity, called Unity Engine (similar to Flash): It has the same security problems like has Java and could do anything to your computer. The only difference between Unity Engine and Java is that Unity runs without asking you if you wish to run it or not. So if someone has Unity Player installed and runs a game that contains a virus, it will screw up your computer.

Less popular, but could potentially extremely harmful is VBScript. I believe Microsoft Internet Explorer is the only one that supports this currently, but I could be wrong. It has the same abilities as Java.

Steven Volckaert
  • 1,193
  • 8
  • 15
SSpoke
  • 113
  • 3
  • 14
    "The answer is quite obvious. Can you delete your computer files using JavaScript, HTML or Flash?" Yes I can. All I need is a sufficient exploit in the JavaScript engine or the Flash plugin. – DCKing May 11 '14 at 10:57
  • Lots of factors involved you have to target a specific version of Flash and JavaScript seems like every browser uses their own engine for this yeah you may be able to target some percentage after all but chances are slim that the person who is worried will get affected, with a langauge that does this without hacking code just a regular programmer can do this no problem with Java/Unity etc, if he be evil of course just trying to say people shouldn't trust something that does harm without even hiding it. Nothing pisses me off more then little kiddies trying to screw me over with keyloggers. Haha – SSpoke May 12 '14 at 05:23
  • Java applets are generally also protected from such scenarios as being able to erase your filesystem - you first have to do some sandbox evasion that also requires you to target specific versions and zero days. From that perspective, the Java and Flash plugins are more or less in the same boat. – DCKing May 12 '14 at 08:41
  • Flash has also had its fair share of exploits. With any language that is "interpreted" by a native engine and has programming bugs (Java, Flash are the predominate examples), it's possible to escape the sandbox they've built and affect the host system, possibly even injecting native code that can then exploit a privilege escalation bug of the host. – phyrfox May 14 '14 at 01:35
  • "The answer is yes, if you accept running the applet." This is completley wrong if we are talking about Applets (and we are, as otherwise, well, all bets are off and I hope you know what you installed on the "nominally your" computer). See: [Permissions in the Java Development Kit (JDK)](http://docs.oracle.com/javase/7/docs/technotes/guides/security/permissions.html) – David Tonhofer Nov 17 '16 at 12:40