NOD32---Found infected .jar file, but only gave me "LEAVE" button

[Thomas G. Marshall]

NOD32 (demo) found a .jar file in the java cache, but all the buttons but
"Leave" were grayed out. No delete, no clean, no nuthin. There was a "copy
to quarantine" checkbox there, but it of course left the file in place. I
had to go find it and delete it myself.

1. Why?

and

2. Further, NOD32 cannot clean within archives, is that correct?

Thanks so much!

 

[Adam Piggott]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NOD32 (demo) found a .jar file in the java cache, but all the buttons but
"Leave" were grayed out. No delete, no clean, no nuthin. There was a "copy
to quarantine" checkbox there, but it of course left the file in place. I
had to go find it and delete it myself.

1. Why?

I don't know why it does this. One could say that an infected archive may
have something wanted in it, but then it can be restore from quarantine.

2. Further, NOD32 cannot clean within archives, is that correct?

I have seen it delete files from self-extracting archives but not zip files
(jar is a zip file). It will prevent infected archives being written to
disk or downloaded, though.

Adam Piggott, Proprietor, Proactive Services (Computing).
http://www.proactiveservices.co.uk/

Please replace dot invalid with dot uk to email me.
Apply personally for PGP public key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)

iD8DBQFEwh+m7uRVdtPsXDkRAgKEAJ9RL2VTiNzAbiIkxfRfJFZ7JFR7xQCeKdbb
wTSz4hgQzTLZE07qJIh74Zs=
=d1Xf
-----END PGP SIGNATURE-----

 

[David H. Lipman]

From: "Thomas G. Marshall" <[email protected]>

|
| NOD32 (demo) found a .jar file in the java cache, but all the buttons but
| "Leave" were grayed out. No delete, no clean, no nuthin. There was a "copy
| to quarantine" checkbox there, but it of course left the file in place. I
| had to go find it and delete it myself.
|
| 1. Why?
|
| and
|
| 2. Further, NOD32 cannot clean within archives, is that correct?
|
| Thanks so much!
|

You had a Trojan or Exploit .n a .CLASS file indside a Java Jar. A ZIP type file.
AV Software can't pull and infected file from an archive file and then repack the archive.
It can only scan the conents of an archive file and deal with the whole archive file. This
includes such file types as; CHM, CAB, ZIP, LZH etc.

Here are some suggestions for this type of situation...

If you are using any version of Sun Java that is prior to JRE Version 5.0,
then you are strongly urged to remove any/all versions that are prior to JRE/JSE
Version 5.0. There are vulnerabilities in them and they are actively being exploited.
It is possible that is how you got infected with malware.

Therefore, it is highly suggested that if there are any prior versions of Sun Java
to Version 5 on the PC that they be removed and Sun Java JRE/JSE Version 5.0 Update 7
be installed ASAP.

Simple check, look under...
C:\Program Files\Java

The only folder under that folder should be the latest version...

C:\Program Files\Java\jre1.5.0_07

http://www.java.com/en/download/manual.jsp

1) Dump the contents of your IE cache -
Start --> settings --> control panel --> Internet options --> delete files

2) Dump the contents of the Mozilla FireFox Cache { if you use FireFox }
Tools --> Options --> Privacy --> Cache --> Clear

3) Dump the contents of your Sun Java cache -
Start --> settings --> control panel --> Java applet --> cache --> clear
or
Start --> settings --> control panel --> Java applet --> general --> settings -->
delete files

4) Re-scan your system using your anti virus software.

 

[Thomas G. Marshall]

David H. Lipman said something like:

From: "Thomas G. Marshall"


You had a Trojan or Exploit .n a .CLASS file indside a Java Jar. A ZIP
type
file.
AV Software can't pull and infected file from an archive file and then
repack the archive. It can only scan the conents of an archive file and
deal
with the whole archive file. This includes such file types as; CHM, CAB,
ZIP, LZH etc.

Absolutely not true. NAV has no trouble whatsoever doing this.

Here are some suggestions for this type of situation...

If you are using any version of Sun Java that is prior to JRE Version 5.0,
then you are strongly urged to remove any/all versions that are prior to
JRE/JSE
Version 5.0. There are vulnerabilities in them and they are actively
being
exploited.
It is possible that is how you got infected with malware.

Therefore, it is highly suggested that if there are any prior versions of
Sun Java
to Version 5 on the PC that they be removed and Sun Java JRE/JSE Version
5.0
Update 7
be installed ASAP.

Simple check, look under...
C:\Program Files\Java

The only folder under that folder should be the latest version...

C:\Program Files\Java\jre1.5.0_07

http://www.java.com/en/download/manual.jsp

1) Dump the contents of your IE cache -
Start --> settings --> control panel --> Internet options -->
delete
files

2) Dump the contents of the Mozilla FireFox Cache { if you use
FireFox }
Tools --> Options --> Privacy --> Cache --> Clear

3) Dump the contents of your Sun Java cache -
Start --> settings --> control panel --> Java applet --> cache -->
clear or
Start --> settings --> control panel --> Java applet -->
general -->
settings --> delete files

4) Re-scan your system using your anti virus software.

Thanks. Ironically, I'm a long time java engineer from the pre-1.0 beta
beginning, so these were my next steps anyway, but I appreciate the
thoroughness of your answer. I use older JRE's for other reasons, so they
will stay put, or perhaps out of the way.

 

[David H. Lipman]

From: "Thomas G. Marshall" <[email protected]>


|
| Thanks. Ironically, I'm a long time java engineer from the pre-1.0 beta
| beginning, so these were my next steps anyway, but I appreciate the
| thoroughness of your answer. I use older JRE's for other reasons, so they
| will stay put, or perhaps out of the way.
|

Sure you can keep them but on a PC NOT connected to the Internet.

There are Trojans and adware currently exploiting the vulnerabilities in the older versions
of Sun Java. These Trojans will traverse the C:\Program Files\Java tree looking for a
vulnerable version to exploit. The writers are well aq2uanted with the fact that Sun Java
auto-downloads new versions and doesn't remove old versions. This is part of the
exploitation scheme.

 

[Adam Piggott]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From: "Thomas G. Marshall" <[email protected]>


|
| Thanks. Ironically, I'm a long time java engineer from the pre-1.0 beta
| beginning, so these were my next steps anyway, but I appreciate the
| thoroughness of your answer. I use older JRE's for other reasons, so they
| will stay put, or perhaps out of the way.
|

Sure you can keep them but on a PC NOT connected to the Internet.

There are Trojans and adware currently exploiting the vulnerabilities in the older versions
of Sun Java. These Trojans will traverse the C:\Program Files\Java tree looking for a
vulnerable version to exploit.

<snip>

Surely if they're able to traverse a directory then they are executing
locally and you're infected no matter what version you're using? (Not that
I'm saying your approach on removing older versions is misguided)

Adam Piggott, Proprietor, Proactive Services (Computing).
http://www.proactiveservices.co.uk/

Please replace dot invalid with dot uk to email me.
Apply personally for PGP public key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)

iD8DBQFEwnrH7uRVdtPsXDkRAjNHAJ9O5GnB7uWu1MD3FUCKQZIyOS91gACeJFsI
Zaitido5ycQTefB5U66OiyU=
=h07v
-----END PGP SIGNATURE-----

 

[Virus Guy]

There are Trojans and adware currently exploiting the
vulnerabilities in the older versions of Sun Java. These
Trojans will traverse the C:\Program Files\Java tree
looking for a vulnerable version to exploit.

Are you saying that web-based (and browser-retrived) java code has the
ability to pick and choose which version of the java runtime engine is
used to execute/render the code? Isin't that a function of the
browser?

 

[Thomas G. Marshall]

David H. Lipman said something like:

Sure you can keep them but on a PC NOT connected to the Internet.

There are Trojans and adware currently exploiting the vulnerabilities in
the
older versions of Sun Java. These Trojans will traverse the C:\Program
Files\Java tree looking for a vulnerable version to exploit. The writers
are well aq2uanted with the fact that Sun Java auto-downloads new versions
and doesn't remove old versions. This is part of the exploitation scheme.

Hence the "out of the way" remark and I have a hard time seeing how
something that was going to be executed in JRE 1.x (high value x dictated
from the browser) could gain anything by attempting to access something
directly in *my filesystem* in JRE 1.y (y < x).

The .x would theoretically stop that, no?----once I'm compromised to that
point, why would it need the .y at all? I'll have to think a bit more on
this---viral security manager work-arounds are not my "specialty" within
java.

 

[Thomas G. Marshall]

Adam Piggott said something like:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<snip>

Surely if they're able to traverse a directory then they are executing
locally and you're infected no matter what version you're using? (Not that
I'm saying your approach on removing older versions is misguided)

Adam Piggott, Proprietor, Proactive Services (Computing).
http://www.proactiveservices.co.uk/

Ah...my post's intent overlaps yours. I should have read through the
replies before responding.

 

[Duane Arnold]

:




Are you saying that web-based (and browser-retrived) java code has the
ability to pick and choose which version of the java runtime engine is
used to execute/render the code? Isin't that a function of the
browser?

It's the same thing with a ASP.NET solution and the C#, VB, or C++ .NET
Code Behind File code that executes with the ASP.NET solution along with
the execution of HTML or script code by the browser. If the solution was
written using the .Net Framework ver 1.1 and it's on the client machine,
then .NET will choose the 1.1 version of the Framework.

If the ASP.NET solution was written using the .NET Framework Ver 2.0 and
it's on the machine, it will execute using the version 2.0.

So in other words, there can be different .NET Framework versions on the
client machine and the correct version will be chosen by .NET based on
the version of .NET solution running at the WEB server. The browser has
nothing to do with it.

Duane

 

[edgewalker]

Surely if they're able to traverse a directory then they are executing
locally and you're infected no matter what version you're using?

Think in terms of an escalation path.

 

[David H. Lipman]

From: "Adam Piggott" <[email protected]>


| <snip>
|
| Surely if they're able to traverse a directory then they are executing
| locally and you're infected no matter what version you're using? (Not that
| I'm saying your approach on removing older versions is misguided)
|
| Adam Piggott, Proprietor, Proactive Services (Computing).
| http://www.proactiveservices.co.uk/
|

Adam:

Take two scenarios.

The first being a PC using the latest Sun Java.

The second being a PC with multiple versions with at least one vulnerable version of Sun
Java.

In the first scenario you get a .CLASS file inside or outside a Java Jar and the code within
is executed. Since the PC is not vulnerable all you have is an exploitation attempt.

In the second scenario you get a .CLASS file inside or outside a Java Jar and the code
within is executed. It finds a vulnerable version of Hun Java and exploits the
vulnerability thus leading to the automatic download of a Trojan or adware. Most notable
examples are the Vundo Trojan and the Virtumonde adware.

 

[David H. Lipman]

From: "Thomas G. Marshall" <[email protected]>


|
| Hence the "out of the way" remark and I have a hard time seeing how
| something that was going to be executed in JRE 1.x (high value x dictated
| from the browser) could gain anything by attempting to access something
| directly in *my filesystem* in JRE 1.y (y < x).
|
| The .x would theoretically stop that, no?----once I'm compromised to that
| point, why would it need the .y at all? I'll have to think a bit more on
| this---viral security manager work-arounds are not my "specialty" within
| java.
|

I am not the researcher. Two MS MVPs did much work on this for almost a year. Sandi H. and
Steve W. and they are the ones best to explain it all. All I can say is see my reply to
Adam P. and read the following which was disseminated Feb. 7, 06.
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102171-1
and
http://www.frsirt.com/english/advisories/2006/0467


Note: It is now the end of July and Dell is /*STILL*/ shipping New computers with the
vulnerable version of Sun Java.

 

[Virus Guy]

So in other words, there can be different .NET Framework versions
on the client machine and the correct version will be chosen by
.NET based on the version of .NET solution running at the WEB
server. The browser has nothing to do with it.

What does .net have anything to do with it?

If a system does (or does not?) have the .net thing installed, and if
it does have multiple versions of JRE, then again I ask this simple
question:

If HTML code (or Java code or class code or other java crap code) is
retrieved by a browser during casual surfing, then can (or IS) said
code processed/executed/rendered/handled by a specific version of the
JRE ->as dicated by data in the code<- ????

 

[Ant]

:

[multiple java versions]

In the second scenario you get a .CLASS file inside or outside a Java Jar and the code
within is executed. It finds a vulnerable version of Hun Java and exploits the
vulnerability [...]

I don't see how there's a problem if the default JVM, which the
browser will have loaded to run the applet, is the non-exploitable
one. A malicious applet would have to load a new virtual machine by
searching the file system. I would be surprised if both operations
(traversing the local file system and executing a new JVM) are not
prohibited by the java security model or sandbox rules.

 

[kurt wismer]

:

[multiple java versions]

In the second scenario you get a .CLASS file inside or outside a Java Jar and the code
within is executed. It finds a vulnerable version of Hun Java and exploits the
vulnerability [...]

I don't see how there's a problem if the default JVM, which the
browser will have loaded to run the applet, is the non-exploitable
one. A malicious applet would have to load a new virtual machine by
searching the file system. I would be surprised if both operations
(traversing the local file system and executing a new JVM) are not
prohibited by the java security model or sandbox rules.

i seem to recall someone telling me it was possible to call arbitrary
versions of java through *javascript* (which is obviously not bound by
java's security rules)...

 

[Duane Arnold]

Duane Arnold wrote:




What does .net have anything to do with it?

..Net and Java do the same thing in the principles of how Web based
solutions work when it comes to multiple versions of the runtime
components on the client workstation, which is going to be based on what
runtime version of either solution (.NET or Java) that executes at the
WEB server.

When the Web server sends HTML controls to the browser to execute and
then the page is sent/posted posted back to the Web server to execute,
it is based on what the Web server is sending and wanting back.

The client side must be in sync with whatever is being used at the Web
server. Web servers on the Internet when it comes to using Java or .NET
solutions are not and do not use the same versions of the runtime
components. A Web server at a company can be using one version of the
runtime components while another company's Web server can be using a
different version of the runtime components.

If a system does (or does not?) have the .net thing installed, and if
it does have multiple versions of JRE, then again I ask this simple
question:

It's obvious that you don't know about Web base application development
and how things work between the client side browser and the Web server side.

If HTML code (or Java code or class code or other java crap code) is
retrieved by a browser during casual surfing, then can (or IS) said
code processed/executed/rendered/handled by a specific version of the
JRE ->as dicated by data in the code<- ????

What data are you talking about? Yes, there is data being sent or posted
back that is encapsulated in HTML controls that may or may not be
visible to the end-user, enterable by the end-user or selectable by the
end-user.

The browser on the client side doesn't retrieve anything. The page is
sent to the browser by the Web server and the browser sends/posts it
back to the Web server.

You have client side code in a page that the Web Server sends in a WEB
session to the browser to execute when the page is rendered at the
client machine. There are server side code/HTML controls in a WEB
session that only work at the Web Server when the page is posted/sent
back to the Web server.

Everything is based on what version of the runtime components at the Web
server that are being used, as it's the Web server that sends the page
the browser is to execute. Newer version of Java or .Net are backwards
compatible with older versions. So things run smoothly or transparently.

But if a Web server sends a HTML control that is based on a newer
version of the runtime Web server components and the newer runtime
version is not on the client side that is needed to render the HTML
control on the page, it's not going to be able to render the HTML control.

It's all based on what version of the Web server runtime components are
being used to render the page at the client machine's browser. And Web
servers out there on the Internet are not in sync with runtime versions.

Web solutions are based on what version of the Web runtime components
are being used in the development of the Web solution by the developer.

The bottom line is there are going to be multiple versions of the
runtime components on the client side.

And what I mean by send and post back in a Web Session is that the Web
server sends a page and the connection is terminated with the client
machine. It's a stateless session.

Then client machine browser posts back to the Web server the page and
then the Web server has to figure out who you are with the Web page that
was posted back, which may or may be done by the use of cookies or other
controls hidden or transparent to the end-user on the page.

The Web sever has multiple stateless sessions with a client or a
stateless session every time a page is sent to the browser and is posted
back by the browser. That way, the Web server can have multiple clients
in stateless sessions.

Duane

 

[Adam Piggott]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Note: It is now the end of July and Dell is /*STILL*/ shipping New computers with the
vulnerable version of Sun Java.

- From my experience they also ship with malware on them so I'd avoid them
like the plague anyway!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)

iD8DBQFEw1Nu7uRVdtPsXDkRAlYJAKCYJRCLD3ZSVsLk4TqspKO7PHzVXgCfegQM
OkC/LgTGW5lgs8KTdmULCRY=
=6Pr7
-----END PGP SIGNATURE-----

 

[David H. Lipman]

From: "Adam Piggott" <[email protected]>

|
| - From my experience they also ship with malware on them so I'd avoid them
| like the plague anyway!

Dell makes quality platforms. However it is my opinion to NEVER take the default factory
configuration. Always wipe the computer and install the OS from scratch. This includes
other vendors.

 

[Virus Guy]

Duane Arnold wrote:

(waaaay to much information).

Look. Just answer a simple question.

If Sun JRE version A has known vulnerabilities, and a user updates
their computer with JRE version B, is the computer still at risk when
web-surfing because it still has JRE version A installed?