Java security problem

[LocoRon]

http://www.computerworld.com/s/article/ ... indows_bug

No, long-standing security exploits are not unique to Java.

[RobertJasiek]

Since I dislike many executables, I avoid accessing several go servers! Usually, I am only on KGS, for which I have to suffer from the JRE weakness (but for which I profit from other security advantages such as knowing WMS reliable reputation.)

Concerning security exploits, a major principle is to avoid them if anyhow possible. The JRE problems can be avoided by a) not using JRE (and thus not CGoban) or b) convincing the programmer to avoid JRE. Either way closes the vector of JRE-related security issues. (Provided one does not have to use third programs depending on JRE.)

Updating JRE reduces security gaps but does not avoid them (and currently causes CGoban sound problems, IIRC).

(Better general security mechanisms also help restricting the JRE security problems.)

[speedchase]

http://javainxml.blogspot.com/

I liked this blog post. It puts it in perspective without getting to technical.

[flOvermind]

or b) convincing the programmer to avoid JRE. Either way closes the vector of JRE-related security issues. (Provided one does not have to use third programs depending on JRE.)

You are missing one crucial point: Sure, not using JRE closes the vector of JRE-related security issues. But it also opens the vector of security issues that arise from the use of native code, like for example buffer overflows.

Compare these two scenarios:
1) A programmer writes a network application in Java. Some security bug in the JRE appears, and it *may* affect the application (in the case of KGS and the current JRE issue, it does not, but that's beside the point). But there are lots of people using the JRE, so the bug will be found, and the security experts at Oracle are going to fix it within some reasonable time. The programmer doesn't need to do anything, the application is secure again.

2) A programmer avoids Java, and writes the network application in native code (let's say C++). Sure, the application is not affected by any JRE bug. But since the programmer is not a security expert, the program will have some kind of buffer overflow bug. These are incredibly hard to find, and since not many people are using the application, noone is really interested in security analysis. Except of course the bad guys that want to get into your computer, but they certainly won't send a friendly mail to the programmer on how they exploited the code. The bottom line: You are almost guaranteed to have a security vurnerability on your system, and while it may be less likely to be exploited, there is practically zero chance of it being fixed.

The second scenario is impossible with Java. Because of the way Java works, buffer overflows and similar bugs are impossible. These bugs will always be caught by the JRE and won't be able to do any damage. So yes, you may have security bugs in the JRE. But you will have *only* these bugs, and no additional ones from the applications themselves. That's especially important if you want to install more than one application on your computer: 10 applications using Java have just one attack vector, the JRE. 10 native applications open up 10 potential attack vectors...


To summarize: Java is not perfect, it does have security flaws. But from a pure security standpoint, using Java is still a lot more secure than not using Java. Somewhere behind that there are things like e.g. .NET or the various scripting languages, and possibly even Flash. Not using any of these and writing native code is by far the worst alternative (from a pure security point of view).

[RobertJasiek]

For a statically compiled application and for a buffer to overflow, there must be a reason: division by zero, missing garbage colletion or interpretation of unchecked input of network data or GUI entered data. The programmer need not be a security expert to avoid such, but he just needs discipline: check for unequal to zero before dividing, clean the dynamic heap data structures, check input data before processing them.

A java application can have more than one attack vector. In particular, the application's JAR file can be bad or even hacked and contain malicious code. Published checksums of distributed JAR files and manual installation could reduce the problem. AFAIK, so far programmers of go software even fail to publish checksums.

The toughest attack vector might be hijacking of a running application instance.

[Xyiana]

The programmer need not be a security expert to avoid such, but he just needs discipline: check for unequal to zero before dividing, clean the dynamic heap data structures, check input data before processing them.

It is amazing how number of "code vulnerability experts" is raising after each discovery with good media coverage/hype.

You can have even fataly flawed code from security point of view and it can be best solution for your problems still. Each solution, use of tools/frameworks, ppl training for some form of security defensive coding, testing,... is with high cost if you want to be serious and even after all that effort you can be sure that there are problems left still.

And personally i dont think jvm problems are so bad when compared with different it technology in the past so there is no need for refusing jvm. You can use countless defensive countermeasures if you are too afraid of your privacy.

[flOvermind]

For a statically compiled application and for a buffer to overflow, there must be a reason: division by zero, missing garbage colletion or interpretation of unchecked input of network data or GUI entered data. The programmer need not be a security expert to avoid such, but he just needs discipline: check for unequal to zero before dividing, clean the dynamic heap data structures, check input data before processing them.

Or missing/buggy array bounds check. Or something wrong with your recursive function. Or a subtle race condition in multi-threaded code. Or any of these not in your code, but in one of the libraries you use, including the operating system. I could continue that list...

It takes a lot more that "just discipline" to avoid these kinds of errors with "native" languages like C, and that's even assuming that you know about all the potential problems. Actually, the fact alone that you are not aware of all these subtle things shows that it's not that easy to write a secure application. It's just not possible to think of every existing attack vector out there and actively protect against it.

The advantage of using a "safe" language (like Java) is that you don't have to worry about a huge percentage of these things, because the worst that can happen is that your application crashes, and the attacker is never going to be able to insert malicious code through a bug in the application.

A java application can have more than one attack vector. In particular, the application's JAR file can be bad or even hacked and contain malicious code. Published checksums of distributed JAR files and manual installation could reduce the problem. AFAIK, so far programmers of go software even fail to publish checksums.

Replace every instance of JAR file with EXE file, and you have an even worse problem. That's actually the point of the whole fuss: With Java, you have security measures in place against masicious code. They are just not perfect, there are apparently some security holes. With EXE files and native applications, you have no security at all, if you don't trust the file and its author, you can't use it, period. On the other hand, it takes a little bit more than "just" malicious code in a JAR file to break out of the Java sandbox. That's why people (and sadly also browsers) tend to blindly trust in Java to protect them, and it's really bad when suddenly it's discovered that Java isn't perfect. But there is no such thing as bug-free software.

And while we're at it, I actually have no idea why until recently browsers just executed plugin content (including Java) without asking the user. You'd think people have learned something from ActiveX plugins . And even worse: At least on Firefox, there is an exception for Flash, so I expect all the security problems to just shift to a different plugin, now that the default is click-to-start for everything else. But maybe not, because people just tend to click on Ok anyway .

Executing code from an unknown source just isn't a good idea, ever, regardless of programming language .

The toughest attack vector might be hijacking of a running application instance.

Actually, for C programs, that's the most common attack vector. For Java, it's almost non-existant.

As a practical example, all things being equal, just assume there is an alternative KGS client written also by wms, with exactly the same feature set, but written in C++ instead of Java. Which one would you use?

I would definitely use the Java client, because while I'm pretty sure I can trust wms, I'm also pretty sure there are security relevant bugs in the code. There always are, as soon as the application uses network connections. But I'm also pretty sure that the Java VM protects me from most of them by just crashing the application in the worst case, instead of allowing an attacker to capture my computer.

On the other hand, if someone I don't trust sends me a program, I don't think it's a good idea to start it, not even if its written in Java

[RobertJasiek]

a "safe" language (like Java)

Can you please elaborate on what makes a lanuage (or its environment) "safe" in contrast to a native language?

With EXE files and native applications, you have no security at all, if you don't trust the file and its author, you can't use it, period.

Partly, right. There are, however, the possibilities of open source code to be compiled, hashs or certificates. (The latter two also require trusting the author or certificate distributer.)

there is no such thing as bug-free software.

One of my informatics prof said: "The longest error-free program I have seen had 5 lines of code.";)

assume there is an alternative KGS client written also by wms, with exactly the same feature set, but written in C++ instead of Java. Which one would you use?

I would choose C++, because WMS I trust more than the JRE authors and because I use sandboxing in the operating system's management of running applications.

[Kirby]

a "safe" language (like Java)

Can you please elaborate on what makes a lanuage (or its environment) "safe" in contrast to a native language?

There are generally two aspects that come to mind in terms of language safety.

1.) Language safety means predictability. C and C++ are notorious for undefined behavior: http://en.wikipedia.org/wiki/Undefined_behavior
You often have a lot of flexibility and power with such languages, but of course, undefined behavior is typically undesirable. Further, sometimes you have different C compilers, for example, that produce different behavior for the same compiled source code. This is not the case with Java, for example, where the JRE interprets the bytecode in the same way and produces the same effect.

2.) Language safety can indicate that the language provides abstraction. For example, with an array, you might not dealing directly with memory. Rather, the way elements are added to the array in the language is through an abstraction, which only allows for this to be done through the mechanisms specifically designed for this in the language. Contrast this with writing to an arbitrary memory location.

Language safety makes it harder for the programmer to do dangerous things in their code. You can try to prevent problems by adhering to good programming practices, but programmers are humans and subject to making mistakes.

Safe languages can aid in alleviating this problem.

[rebent]

I suppose this is the best place to ask this question - but, for each new problem on Goproblems.com, Java asks my permission to run. I am using chrome on Windows 7. Is there any way to make it just work, without having to pop up again and again asking permission to run? Or, better yet, is there some sort of standalone goproblems app or program that will get the problems without me even having to use a web browser?

[speedchase]

I suppose this is the best place to ask this question - but, for each new problem on Goproblems.com, Java asks my permission to run. I am using chrome on Windows 7. Is there any way to make it just work, without having to pop up again and again asking permission to run? Or, better yet, is there some sort of standalone goproblems app or program that will get the problems without me even having to use a web browser?

usually there is a checkbox in the popup you can click. (for my version of chrome, you can click always run on this site).

[Bill Spight]

Last time I was on goproblems, I had Java disabled and had the option of using Javascript, which worked fine. (On Safari)

[rebent]

usually there is a checkbox in the popup you can click. (for my version of chrome, you can click always run on this site).

I click that, but it keeps coming up any time. I'll try disabling java and running it through javascript - thanks for the tip!

[hyperpape]

At Pwn2Own, Browser Exploits Getting Harder, More Expensive to Find Has some interesting tidbits.

[RobertJasiek]

According to

http://www.heise.de/newsticker/meldung/ ... 17775.html

certificate verification by Java was programmed but deactivated...! As a consequence, a malware digitally signed with a stolen key was allowed to escape the Java sandbox and download and execute random code [subject to Java-independent security means].

As nice abstraction layers, sandbox and certificates for Java may be in theory, as long as their programming allows the contrary, there is no security in practice.