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?

Improve this question
16
  • 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, 2014 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, 2014 at 15:46
  • 22
    Because it was bullied as a child.
    – TylerH
    May 10, 2014 at 17:28
  • 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, 2014 at 12:52
  • 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, 2014 at 14:15

8 Answers 8

Reset to default
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.

Improve this answer
12
  • 19
    Yes, the major security problem is only the sandbox.
    – Steffen Ullrich
    May 9, 2014 at 18:33
  • 9
    No stackoverflows? I accidentally triggered one just today with infinite recursion. Did you mean buffer overflow?
    – Lekensteyn
    May 9, 2014 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 9, 2014 at 19:14
  • 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, 2014 at 15:32
  • 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, 2014 at 10:51
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).

Improve this answer
3
  • 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, 2014 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, 2014 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 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, 2014 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.

Improve this answer
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#).

Improve this answer
1
  • 2
    Nitpick: It's more like thousands of classes, and tens of thousands of methods. Other than that: Great answer!
    – meriton
    May 16, 2014 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.

Improve this answer
1
  • 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, 2014 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.

Improve this answer
-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.

Improve this answer
1
  • 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, 2021 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.

Improve this answer
5
  • 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, 2014 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, 2014 at 5: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, 2014 at 8: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, 2014 at 1: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)
    – David Tonhofer
    Nov 17, 2016 at 12:40

You must log in to answer this question.

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