Sun Java - Security Vulnerabilities and Updates

(using XP SP1, w/current updates -- SP2 no good with this notebook).

Yesterday, updated from java ". . . . -06" to java ". . . . -07 ". Immediately took on a virus:

"Byte Verify ", "OpenStream" per AVG 7 (updated). AVG reports it to be in the "install jar" file! What's that all about?

Fixed and "vaulted" the virus and returned to java "....-06" So far no new virii (???)

Boy, to the technically challenged, like my self, this is most confusing. The update gets the virus but the previous version doesn't?

I'm sittin' with "....-06" version for the moment. Wot a complicated world!!!

Bob

 

That particular trojan is rather harmless in that location, part of Java's cache: Documents and Settings\Applications\Java\ (if XP). You can clean that manually yourself, good idea to do periodically anyway.

The 07 vs the 06 issue, I would be inclined to say that's coincidence, I've had Byte Verify in that location with earlier versions.

Regards - Charles

 

Charles,

I respectfully disagree regarding the trojan because the java 'sandbox' has been now breached by trojans including I believe that one (that's why the cache should be permanently turned off)! Cleaning involves shut modem, clear & turn off the java cache, temp turn off System Restore, reboot, deep/byte scan AV, scan with Trojan Hunter. After any cleaning, reboot & repeat scans. When clean, reenable System Restore.

A lucky AV or Trojan Hunter catching it usually means it's active outside the sandbox when you scan (or perhaps scanners can now newly read inside the sanbox which I believe was previously a fully locked file).

I agree with you regarding the version just being a coincidence, & I urge the other person to definitely update & after updating to again click update as it seems SUN's system somehow only updates so far up & you have to continue updating to reach the current 1.50

 

Hi Bob,
Please read my reply to Charlesvar. Thank you.

 

Hi Marlet,

Should have made myself clearer, harmless beause the AV eviscerates it leaving an empty 0 kb file.

I have not personally found this particular bugger outside the cache, nor any instance from my reading, and once the AV does catch it, that's the only place it is.

Your steps are all good, but willing to bet that there is nothing left.

A lucky AV or Trojan Hunter catching it usually means it's active outside the sandbox when you scan (or perhaps scanners can now newly read inside the sanbox which I believe was previously a fully locked file).
This trojan has been around for a looong time, any competent AV/AT will catch it.

Nor would I disable SR in this instance, remember, that for a lot of ME/XP users, SR is the only means to recover from a disaster, and this doesn't qualify as a disaster, easy enough to deal w/o burning any bridges.

Regards - Charles

 

Thinking about this a little more:

In this particular instance, because its known when the infection occurred, SR could be employed to restore to say yesterday, certainly cleaning the cache, then SR could be disabled/re-enabled with a clean RP.

Normally, users don't know exactly when the infection took place, hence the blanket advice to clean the Sytem Volume Information file out.

One more point - Java's sandbox did its job, this is precisley what its for.

Regards - Charles

 

Thanks to everyone for their responses. I have cleared the cache and have opted to disable this feature and am just about ready to reinstall the latest update as soon as I get this posted.

Bob

 

Hi charlesvar,

"...harmless beause the AV eviscerates it... ". I'd never trust an AV to fully remove a trojan no matter how long the trojan has been around. That simply isn't the competence of AV products. The V in AV is for Virus. Trojan detection by AVs are limited; removal is more limited; complete removal is even more limited.

"I have not personally found this particular bugger outside the cache, nor any instance from my reading, and once the AV does catch it, that's the only place it is ". I don't know why you believe this. I've seen no evidence that a trojan in the cache is only in the cache.

"Your steps are all good, but willing to bet that there is nothing left ". There you may well be correct, but I'd say those steps should always be followed.

"Nor would I disable SR in this instance, remember, that for a lot of ME/XP users, SR is the only means to recover from a disaster... ". There is no disaster & I said to only temp disable it. After the scannings it gets reenabled & a new Restore point gets created. Often the biggest mistake people make (are unaware of) is that they don't turn off System Restore after being infected.

I respect your right to a different view.

 

That's often a bad assumption (though probably not in this case). An AV or AT finds malware. Generally the person who scans regularly assumes it's a new infection & thinks older Restore points are clean. This logic is faulty as the malware may have been previously present & is only detected now based on new signatures or changed heuristics in the scanner, or even a malware that has delayed activation & is only detected in its later state.

Again, it may not directly apply here & I do see your second paragraph. We don't know though if the affected person recently changed AV or updates once a year (no offense to that person as I'm speaking hypothetically).

As to the sandbox, are you unaware that SUN & Scott himself has acknowledged vulnerabilities in the sandbox (they previously had claimed 100% security). Yes, now they updated it but no longer can or do claim 100% security that hackers won't defeat the newest version.

 

Hi Marklet,

I think we're talking past each other about this.

I'm addressing a particular issue, Byte Verify, and your addressing malware in general. I don't disagree with what you're saying.

I don't know why you believe this. I've seen no evidence that a trojan in the cache is only in the cache.
I'm referring to this particular one, not trojans in general.

That simply isn't the competence of AV products. The V in AV is for Virus. Trojan detection by AVs are limited; removal is more limited; complete removal is even more limited.
Agreed to in general, but not in this particular case. I first heard of this malware two years ago, and yes, all the major AV's can deal with this. I run two AV's, NOD and NAV (on two OSes) and I can personally attest to others that I've had experience with.

As to the sandbox, are you unaware that SUN & Scott himself has acknowledged vulnerabilities in the sandbox (they previously had claimed 100% security). Yes, now they updated it but no longer can or do claim 100% security that hackers won't defeat the newest version.
Agreed, no software is 100% secure, and whatever Sun's clams, never was. However, in this particular instance, it works just fine.

I respect your right to a different view.
Thanks, and I feel the same about you.

Great to "talk" to someone as knowlegable and articulate as you are

Regards - Charles

 

Can you give a references for why the Java cache should be turned off? Here's what I found on Sun's site:
http://www.java.com/en/download/help/cache_virus.xml
Virus found in the Java Runtime Environment (JRE) cache directory

From another forum:
http://www.broadbandreports.com/forum/remark,11363541~mode=flat
ByteVerify Myth within Sun Java Cache

 

I'd rather they did - it could give me an idea of which web site(s) the malware is coming from

==

reckon the worst "vulnerability" here is that SUN Java seems so hopeless about alerting the user that they are running an out of date version which needs upgrading

...lulling into a false sense of security?

best wishes, HJ

 

As I see it, then:

Disabling the Java cache does NOT guard against any known vulnerability.

The reason you would disable the Java cache would be to prevent your antivirus program from issuing false alarms.

 

After a breif scan of this thread, I would like to inquire as to whether or not the solution to this quagmire is succinctly outlined somewhere, such that it is not necessary for readers of this thread to spend all day trying to determine what if anything needs to be done and how to quickly accomplish it... If not, would someone like to volunteer to accomplish this - maybe it should be an up front "sticky" so that the general public becomes aware of this situation...

 

keywester - Yes!

some kind of digest would be a really good thing...

...particularly as the thread's meandered in a way which bears little resemblance to the original title

==

at the risk of causing further deviation: has anyone mentioned that the Microsoft VM also has a cache? (called temporary internet files...)

so (hypothetically) if you were to replace one of your system files (prompted by SFC, for example) from Windows CD, and such replacement were to "unpatch" your JVM so that it's no longer as safe as v3810

before you went to WindowsUpdate to mend the situation, even offline browsing would leave you open to the ByteVerify vulnerability - unless you remember to clear out your TIFs first

or is this wrong?

==

yes it seems that way

would it actually prevent "false" alarms from the real-time element of your AV? The .jar (or whatever) has to go somewhere (temp) in order to work whatever Java function it's intended for, the AV would have a look at it as that file gets closed / re-opened, surely - or are these incoming files just left open? I hope not.

I don't like this - it seems that the "better" AVs - in the sense of ones which "know" not to raise false alarms - have to make that decision based upon being sensitive to which particular version of Java you are running, and having to "know" which particular strains of malware to ignore for which particular version of Java; also depending on location of the file...

...too many "depending upon "s for me

==

had a look at the objects in my cache, the biggest seems to be 75kB

best wishes, HJ

 

As far as I can tell, Keywester's original question was answered, both factually and with an opinion by Ramona as to the future of FF.

The rest of this thread's posts are really not about a FF issue, but a Java one. Those issues are still unfolding. In the meantime, users are going to have to deal with it, one way is to experiment, toggling the cache on/off and see the effects, another: keeping up with upgrades, and having tools to deal with any problems, and so on.

Gee, that sounds familiar

Regards - Charles

 

true indeed - but a lot of users are currently faced with the need to upgrade their Java, without (easily) being able to find instructions how to do it - and although the discussion concerning the cache is still developing some points are already clear

I'm with keywester, reckon a sticky with the basics about checking version & upgrading the JVM, and under some title mentioning Java! - would be helpful and save people going round the houses. SUN don't exactly go out of their way to tell you to uninstall the old one first...

best wishes, HJ

 

As I see it, the real-time AV element would only kick in if the malicious code attempted to execute .... and, that would only happen in the Microsft VM, as detailed here:
http://securityresponse.symantec.com/avcenter/venc/data/trojan.byteverify.html
However, the malicious code that has been downloaded to the JRE cache folder IS recognized during a full system scan.

Kind of similar to what happens when a virus attachment is received in e-mail. If you don't open the attachment, the Real-time protection doesn't find it. However, when you run a scheduled or "on demand" AV scan, your antivirus scanner will find it in the inbox, or in Junk mail, or in the trash if you haven't emptied/compacted it.

I thought of disabling the JRE cache to prevent false alarms but I can just as easily clear the Java Plugin cache if and when a detection occurs.

 

Hi Mike,

Has not been my experience. Both NAV and NOD will detect ByteVerify in Java's cache on write to disk (real time protection), and in TIF with MS JVM. Now whether that was because it tried to execute or not, ??.

I mention only this critter because never got anything else.

Regards - Charles

 

ETrust AV's Real Time Protection doesn't scan on "write to disk ", only when files are "accessed ", whatever that means.