Sun Java - Security Vulnerabilities and Updates

Hi mikewanca,

"Can you give a references for why the Java cache should be turned off? ". There were many references on the major PC sites when this occurred a few months ago. I act on such without saving links. You can search in eweek, computerworld, zdnet, pcworld etc & find it.

"Here's what I found on Sun's site:... ".
Sorry to say it's a real poor site for finding correct info.

"From another forum: ".
There are 2 things we both know you find all over the web: inaccuracies; knowledge that may have once been correct.

 

If uou have the current SUN version there is no known vulnerability. To that literal extent you're correct.

The point is SUN previously believed & repeatedly said the cache 'sandbox' was 100% secure. Then, that was proven wrong. Then they updated. Hackers now know it's not a perfect security & are challenged to beat SUN on the current version. True, that may or may not occur. Why risk it when you can remove the vulnerability by turning off the java cache? Only reason would be IF you're on dialup + IF it noticeably affects sites you regularly visit. On broadband, turning off the java cache might well likely have a statistically measureable affect, but not one you can feel in surfing.

 

Just to add a tidbit, I found that after upgrading to SUN Java 1.50 & turning on the autoupdater & setting it to monthly (with intention to manually check more often): the autostart from it jusched.exe began a memory leak (mem usage) that grew to an instability warning on XP with 768RAM! I turned it off & removed the autostart.

 

I'm afraid I don't understand why you would think that turning of the Java cache removes any vulnerability or otherwise makes your system more secure. Do you have any evidence or a reference to back that up? I don't think asking me to do a websearch is fair, since you're the one making the claim.

I don't mind turning off the Java cache, but I don't think it will accomplish anything except possibly avoiding some false positives... and even that has been questioned here.

 

Hi charlesvar,

"I think we're talking past each other about this. I'm addressing a particular issue, Byte Verify, and your addressing malware in general ". True. Guess my concern was that readers could think some of the statements applied in general. Also, admitedly I didn't research the trojan suffix & history. Not saying you did, but it wouldn't be safe to extrapolate from one trojan to a slightly different one/suffix.

"I respect your right to a different view.
Thanks, and I feel the same about you ". Thanks! I enjoy a good conversation, helping others, & learning when I'm wrong. The most annoying thing in forums can be others who are thin skinned or even folks who mistake discussion / sharing / learning as arguing & feel 'flamed' when they weren't (or perhaps they seek any 'excuse' to be the 'flamer').

"Great to "talk" to someone as knowlegable and articulate as you are "
Definitely feel the same to you.

 

I think that may be the sticking point. I don't know what you mean by Cache 'sandbox' The term "sandbox" as I understand it, means the area in which code is allowed to run.... code cannot escape out of the JRE (Java runtime environment) and into the local computer. Nothing to do with the Java cache, if I understand right. I'll do some research and post back... I just wanted to post this first.

OK, one reference, real quick...

http://developer.intel.com/technology/itj/2003/volume07issue01/art05_security/p04_evolution.htm

 

Hi mikewanca,

It's clear that trojans enter the sandbox. I think you agree. What you're not aware of is that they can leave the sandbox that SUN previously thought was 100% secure (& they were so proud). Turning off the cache is turning off the sandbox & thus eliminates 1 point of trojan entry that is not prevented by any tool. Thus turning off the java cache increases security (not everyone has adequate security & even if you & I do, there will be future trojans our security measures will not immediately detect on outbreak).

As to the websearch, I respect your view that I should conduct it, but I respectfully disagree. This is not an academic forum. Further providing a link or links sometimes just results in a 'war' (term used politely) of link versus link. I'm certain you'd find links in other Forums that could disagree (or disagreed at the point in time that they were posted). I sometimes do include links IF they're 'handy' or if they're helpful in providing specific instructions or services. Unless I have something 'at hand' or a person is in PC distress & lacks research skills, - I don't do the Googling.

Again, I respect your view to the contrary, but wanted to further explain my view on the research which I'm not saying is or isn't the correct approach (other than for me).

 

I'll guess you're likely using terminology better than I do. The trojans use this entry when you run Java AND have the Java cache enabled. Initially SUN claimed that any trojan entering through the open enabled cache could not escape SUN's sandbox. Then that was proven & acknowledged as false (not by a security researcher testing but by trojans infecting people). A quick update was issued that stopped the specific trojans but has no implied guaranty to stop future trojans as the SUN sandbox theory has been proved to be vulnerable.

 

Marklet,

Since you're unwilling to provide evidence or post references to back up notions such as

I'll bow out of further discussion.

 

I respect your point of view & your decision.

Just to further clarify terminolgy a bit, the trojan installer applet file doesn't leave the sandbox. The files it installs get out of the sandbox. Detection of the trojan installer & removal of the trojan installer does not always include removal of what I'll call its payload (files now in other locations & Registry changes).

By definition nothing can get outside a sanbox, but of course that only applies if the sandbox truly is secure. Though it had vulnerabilities, it is still referred to as the sandbox (as that's what it is 'intended' to be).

When I read something in a Forum & I'm unsure of its accuracy, I do my own research if links are not available. That's me, my view. Again, I respect that you have a different view & I respect you & your posts. Thank you.

 

we seem to need a couple of definitions. So:

Sandbox:
(snipped older definition)... the code technology that provides the basis of Java's security. 'Trusted' code is allowed full access to the system. 'Untrusted' code is restricted to the sandbox, a protected and limited area of memory in which the code may 'play' without causing any damage to the host system. In practice, this usually means that a Java application has full access to the system, while a Java applet (as downloaded from the Internet) is limited to the protected sandbox
(www.itsecurity.com/ss.htm)

Cache:
A section of a computer's memory which retains recently accessed data in order to speed up repeated access to the same data
(https://www.namesecure.com/en_US/index.jhtml)

...quite a good definition of sandbox, it draws the distinction between application and applet

==

Turning off the cache does not turn off the sandbox. If you run SUN Java with the cache disabled, the applets still run in the sandbox.

And, what possible advantage could there be in disabling the sandbox (even if this could be done) - the very thing which is curtailing the ability of malware to infect your computer? Just because of the possibility that it's not 100% secure?

Simple question - without a sandbox, what else is there to keep the applets under control? (ans: uninstall Java )

The possibility of an escape from the sandbox depends upon the applet, and the integrity of the sandbox itself... whether or not said applet gets cached for future use doesn't enter into it

(unless we include the scenario of changing Java version, the newly installed version being vulnerable to a previously saved applet)

anyway, consider how the applets got into the cache in the first place - they get downloaded from a website and are run in the sandbox at that time - so if they were going to do damage, it would already have happened

(I suppose, a "time-bomb" applet could be innocuous when first downloaded but somehow become lethal at a later date... but that's a very "special" case)

if this is wrong, please let me know

best wishes, HJ

 

Hi Hugh Jarss,

"Turning off the cache does not turn off the sandbox. If you run SUN Java with the cache disabled, the applets still run in the sandbox ". I'll start with I might use imperfect terminology & I likely don't understand the technical aspects. I do know what I read previously in news stories on trusted major sites, & also in security forums (what I'll called an informed User perspective as to the bottom line. That is that turning off the java cache stops the vulnerability AND that it's tied to the sanbox not sandboxing all trojans. Maybe that boils down to the applet being able to run in the sandbox for page display on that website but not being able to stay on your PC in the cache. I definitely don't know all the terms & how to explain it to some advanced users here who are technically ahead of me. I am confident in the step needed to remove the vulnerability.

"The possibility of an escape from the sandbox depends upon the applet, and the integrity of the sandbox itself... whether or not said applet gets cached for future use doesn't enter into it ". Maybe in some way your statement ordanarily would 99% make 'technical' sense. I don't know, but it just respectfully doesn't apply to the bottom line on this.

"anyway, consider how the applets got into the cache in the first place - they get downloaded from a website and are run in the sandbox at that time - so if they were going to do damage, it would already have happened ". That makes perfect sense/logic in reading your well stated words, but just isn't the case here.

"if this is wrong, please let me know "
I don't think your logic or articulation is wrong. It's surely better than mine. I accept full responsibility for in all probabality not explaining it well, but again am still confident that there is a vulnerability & there is an easy solution, & the solution I stated is correct.

 

Hi Marklet - you're right !

...in advising that turning off the cache will keep you safe(r).

I just wish that you hadn't gone on with "disabling the cache disables the sandbox ", because (IMO) this detracts badly from the credibility of your good advice about the cache.

1) disabling the cache doesn't disable the sandbox
2) disabling the sandbox is a seriously bad idea, it's the very thing which keeps the applets under control

if people realise that the sandbox is what's keeping them safe, they aren't very likely to respect advice to disable it??

==

common knowledge - firewalls help keep a computer safe

If I said: "I think my firewall may leak a bit, what should I do?" and got advice along the lines of "Yikes your firewall might have a leak? Disable your firewall - stop the leak" pheew.... would I take the advice seriously?

Marklet - this isn't in any way meant to be getting at you! - I'm trying to suggest a better way of presenting your good advice about the cache, so that more people are drawn toward following it.

==

Your advice to disable the cache is correct - and how! Cross-Browser Vulnerabilities. The Java cache works the bridge.

FF across to nailed down IE via cached .jar (rather than ActiveX) tip of the iceberg I fear...

best wishes, HJ

PS - I (finally) found out how to disable the Java sandbox - thankfully, it's not an easy thing to do (sign into a jar + nobble local JNLP file to allow all permissions + replace security manager), can see why the thing's considered so robust - note the warning at the bottom of the page. BW, HJ

 

Hi Hugh Jarss,

"Hi Marklet - you're right ! ". Thank you. And thank you for your whole post (even though I don't 100% understand all parts of it, but it's really not necessary or on topic that I do).

. "I just wish that you hadn't gone on with "disabling the cache disables the sandbox ", because (IMO) this detracts badly from the credibility of your good advice about the cache ". I see from the discussion that you're absolutely correct, thank you. Should the statement then be: disabling the java cache disables the sandbox vulnerability in previous versions of Java & possible (likely even) to be discovered in future versions?

"if people realise that the sandbox is what's keeping them safe, they aren't very likely to respect advice to disable it?? ". Yes, well stated. I will defend my prior posts a bit though by saying that even though my terms were incorrect, the solution steps I specifically provided disabled the java cache without as you correctly point out actually disabling the sandbox. The steps only disabled the cache & the vulnerability related to the sandbox design/concept. Correct? This not change your points that are absolutely correct/perfect.

You're firewall analogy (without quoting it) is correct/perfect. Thank you. It reinforced the point/logic very well.

"Marklet - this isn't in any way meant to be getting at you! - I'm trying to suggest a better way of presenting your good advice about the cache, so that more people are drawn toward following it ". Yes, thank you. In no way what so ever was I offended or thinking anything at all negative as to your motivation. I'm not generally thin skinned. To the contrary, I appreciate/enjoy discussion & when appropriate (as was here) corrections and/or improvements. Thank you.

Very best wishes to you too. Please correct me any time (& if you remember me, don't worry about ever offending me as you were 100% properly addressing the content of what I posted/wrote, & not insulting me as a person). Addressing content is 100% appropriate.

Just curious. Prior to my 'starting this': Was your Java cache disabled?

 

no it wasn't! Hadn't even thought about it. Thanks you might just have helped me avoid picking up a "surprise gift" of a type I'd rather do without...

maybe keep it simple, along the lines of "Disabling the cache will eliminate many potential cross-browser problems" - leaving the term "sandbox" out of it altogether.

==

it's not going to be a simple situation whatever way you look at it - what about two browsers running at the same time ?? (as opposed to a FF session followed by an IE session)

that's why I included the word "many "

all sorts of complications ahead I fear

==

When folks read posts like these they tend to go off and Google; include the buzzwords "sandbox" or "escape" and you guarantee a lot of clutter on the search results from the old Javascript+Java problem.

(There's masses of clutter anyway because of the "AV false positives in Java cache" hooey - cannot be avoided because the word "cache" is unavoidable)

simple as possible and as to-the-point as possible - could probably get it much better than what I suggest above! - let's see what people come up with

best wishes, HJ

 

Hi Hugh Jarss,

"no it wasn't! Hadn't even thought about it. Thanks you might just have helped me avoid picking up a "surprise gift "... ". You're welcome (& again thank you for restating it in a way others here can accept/benefit from it. I really am glad to have made a contribution of at least spurring your interest into further investigation resulting in improving your security.

"maybe keep it simple, along the lines of "Disabling the cache will eliminate many potential cross-browser problems" - leaving the term "sandbox" out of it altogether ". Whew. In some Forums that would I think actually sound too complex for some to want to follow. I think I'll just limit it to disable the java cache period (though I've often had to explain to followup replies that No that's not the browser cache).

I do wonder now that if SUN originally really believed it was so 100% secure, then why did they include the disable option (I don't personally know of any benefit other than this security benefit in disabling it rather than limiting its size)?

I'll also guess that many saw the news & updated without uninstalling their old Java & emptying the cache. So there's probably alot of vulnerable PCs out there. I also recall reading (& sorry all I don't have a link) that if you have more than 1 Java version and/or vendor on your PC, & even though you select a default in the GUI, - a website can still 'call'/use/activate any version you have. (If I used any term incorrectly, I think you can still understand the point).

"When folks read posts like these they tend to go off and Google;... ". Yes, true & I often do. "...a lot of clutter on the search results... ". Yes, I find that all the time too.

"...let's see what people come up with ". I very much agree & I'm sorry to anyone that didn't follow my correct advice because I very poorly stated the reason.

My 'excuse' is that I'm a User who does enjoy PC topics especially Security, & I read alot almost daily but am not 'technical'. A final excuse is I do believe the news items I initially read used the same or similar incorrect terms while also providing the correct solutions (update & disable cache), but unfortunately they didn't also mention the flaws in SUN's update process.

'Luckily' my advice has helped many people, & of course while a solution doesn't always work for everyone, - I've never heard of my advice hurting/damaging anyone or increasing their problem (unless they did something I specifically said not to do with HJT or Lspfix or Rootkitreveal; of course some will mess up their PC with Spybot's Advanced Tools too IF they disregard its own warnings to read & understand the Help files first).

The bottom line here is the Forum as a group (you, me, others) succeeded! Hoorah for the Forum

 

I'm not convinced

Sorry to be a wet blanket but.....

I read through the article you referenced,
http://www.vitalsecurity.org/2005/03/firefox-spyware-infects-ie.html and I'm still unconvinced ....
what exactly in that article suggests that disabling the Java cache in any way increases security?

In the article, the person saw a Java alert in Firefox, said YES to run a signed applet* despite the warnings and the result was malware installed into IE. Allowing a signed applet to run in Firefox or Mozilla allowed the malware to install. That could also happen in XPI installs done within Mozilla browsers ... see my posts in the Demise of Mozilla thread:
http://www.windowsbbs.com/showthread.php?t=42463&page=1&pp=20

*According to http://www.javaworld.com/javaworld/jw-07-2000/jw-0728-security.html

In the article you referenced, all that I saw mentioning the java cache was:

But that didn't say anything about the cache file being the source of the problem, or that disabling the Java cache could have prevented the problem. As I saw it, the cache was only mentioned as documentation of the jar file.

If it were that easy to protect against Java vulnerabilities, why is the Java cache enabled by default? And don't you think that ONE of the security advisories and alerts put out by Secunia or IDefense or .k-otik would have mentioned disabling the Java cache as a temporary workaround by now?

 

Hi mikewanca,

No, you're not being a "wet blanket ". You have rights to your views, skepticism, & intellectual curiosity.

I hope & believe that Hugh can provide a reply to your satisfaction. I actually did previously change my mind & try to locate links for you (but was not successful; I don't know why as I was expecting to find it).

I can personally attest to you that I was infected by this (I believe the day before it was announced), & I did not receive or agree to a Java Alert. You can of course choose to believe that or not.

I do hope you'll disable your Java cache.

 

Hi Marklet,

OK, then , I'm NOT sorry to be a wet blanket

Discussion is a good thing and disagreements can be beneficial as long as everyone's opinion is respected.

The site Hugh referenced involved someone disregarding a warning message in Firefox and agreeing to run a signed applet. Not sure what bug bit you.

My cache is still enabled, but small (I keep it at 10MB) since I'm on dialup and I do enjoy Yahoo games so I want to keep the downloads speedy if possible, for Java-enabled sites I visit often.

Convince me, and I'll disable it

 

Hi mikewanca,

"The site Hugh referenced involved someone disregarding a warning message in Firefox and agreeing to run a signed applet ". That site did include that but apparently Hugh understood something else said there. Let's see what he'll reply.

"My cache is still enabled, but small (I keep it at 10MB) since I'm on dialup and I do enjoy Yahoo games so I want to keep the downloads speedy if possible, for Java-enabled sites I visit often. Convince me, and I'll disable it ".
Well, I hope someone convinces you. In the interim, is there a way to permanently transfer the applets you want onto your PC not using the Java cache? I don't know if merely limiting the Cache size helps your security. Correct me if I'm wrong: when your Cache is full, anything wanting to enter is successful & the bottom/oldest entry(s) gets removed? If that's correct, limiting the size would only prevent something malicious if it exceeds your size limit? (Yes I know you're not convinced there is any malicious problem).