I'm surprised that no one has asked or commented about the Java security problem that people seem to be worried about. And surprised to see that traffic on Java-based servers hasn't really changed all that much. They say people should actually uninstall Java from their systems, is this another Y2K or what?

Uninstalling Java is a bit of an overreaction. Disable the Java browser plugins.

_________________
Sanity is for the weak.

Oracle have released a patch, so just make sure you install the latest version.

7_11 is the latest version I can get and Firefox still disables it due to security reasons.

_________________
My "guide" to become stronger in Go

Is this on Windows or Linux?

Windows.

_________________
My "guide" to become stronger in Go

I think there were two sandbox breaking vulnerabilities. The second one was published about a day after the first was fixed. I'm not sure if the second one is already fixed.

IMO the best solution, regardless of the patch is to deactivate java plugins(sandbox breaking is a big deal there) but to keep java installed so you can run desktop applications like KGS. Sandbox breaking doesn't matter there.

_________________
Sanity is for the weak.

I only use it for goproblems.com anyway :o

_________________
My "guide" to become stronger in Go

Basically because of security concern, Mozilla Firefox by default disables the Java plugin. In most cases you can still run those Java applets by clicking on it, if you trust the website hosting the Java code. If you don't like to do this again and again, look at the address bar of your browser and you can see a small lego looking icon, click on it and select "Always activate plugins for this site" and you won't be bothered again. Hopefully another patch from Oracle will be available soon to fix this problem.

It would be the best if go software did not use Java Runtime Environment so that there would be simply no related security problem! I have said so many years ago and will say so many years later. Security gaps must never be allowed at all.

Disabling JRE in one's browser(s) can be insufficient WRT to the browser(s). It can be necessary to deactivate it again and again every time the browsers are updated and for every Windows user's browser instances. Check twice if you are using two JREs for 32b and 64b.

this is a joke. You are using the internet. There are security gaps.


there was a thread in the kgs subfourum

Ok, let me state it more precisely: the big and relevant security gaps that can be closed must be closed.

Because binaries on operating systems don't have security holes?

OS binaries' security holes can or cannot affect security of internet communication, depending on whether and how such binaries are involved. Let us concentrate on those involved. Until OS upgrades, they can provide 0-day-exploits. Such can be big and relevant security gaps. The OS meets this danger also by regular OS updates.

Now let us compare Java Runtime Environment gaps. Updated relatively infrequently, typically still leaving a few big and relevant known gaps. JRE tends to be used also by a few internet programs, so the remaining danger is real.

(Both can be restricted by various security means.)

I'm not sure you understand security exploits as well as you think you do, Robert. The JRE has exploits that are being fixed, and you can decide which programs you wish to execute. If you think you would be safer installing binary go clients from every server, then you need to think about this a bit more.

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

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

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.)

http://javainxml.blogspot.com/

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

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).

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.