J2EE and JBoss virus alerts

[erik777]

Can anyone tell me how I can verify if these virus alerts are valid or false positives:

C:\Program Files\IBM\WebSphere Studio\eclipse\plugins\org.eclipse.platform.doc.isv_2.0.0\doc.zip/product_update.htm infected: VBS.Spth.Jsg.B@mm
C:\Program Files\Rational\Rational Test\QualityArchitect\j2ee.jar/MimeMappingDialog.class infected: BAT.Trojan.DeltreeY.ax
C:\Programs\Java\j2ee\j2sdkee1.3.1\lib\j2ee.jar/ObjectKey.class infected: IRC-Worm.HIQ.A
C:\Programs\Java\Sun\AppServer\jdk\jre\lib\rt.jar/CacheEntry.class infected: Backdoor.SDBot.Gen
C:\Programs\JBoss\jboss-3.2.3\client\jboss-common-client.jar/XmlHelper.class infected: BAT.SmogDopper
C:\Programs\JBoss\jboss-3.2.3\client\jbossall-client.jar/XmlHelper.class infected: BAT.SmogDopper
C:\Programs\JBoss\jboss-3.2.3\lib\jboss-common.jar/XmlHelper.class infected: BAT.SmogDopper
C:\Programs\Java\J2ee\j2sdkee1.3.1\lib\j2ee.jar/ObjectKey.class infected: IRC-Worm.HIQ.A

If they are valid, how did they get infected? I don't have untrusted entries in the Run keys of the registry. The only other files showing virus alerts are countless emails we all receive and know better than to open (e.g., Skynet via PIF files.) All indication is that barring the J2EE classes above, my machine is not running a virus.

I was able to visually verify that the product_update.htm alert was a false positive, unless my eye missed something. I didn't see any scripting in the file.

Has anyone automated the process of verifying the integrity of their Java components? Do I have to compile to be sure? Even so, how do you know javac is not compromised?

In this case, I'd really like to check the integrity of just the individual classes, but don't really want to go through the hoops of downloading all the source and compiling, and I'm not sure that's possible in all cases or realistic.

Even on FreeBSD, where I compiled the JVM, I'm not sure what the best process is for daily checking the integrity of the classes. I dread recompiling the JVM since it takes so long, and will require bringing the server down.

Due to Window's lame file security, the possibility of having your Java classes in various libraries become infected is significantly higher on Windows than BSD/Linux/Unix OS's. The Windows box I'm concerned about is used for testing and production backup, though.

Until this is resolved, I'm not running J2EE on this computer. Unfortunately, since this is a test box, this puts a damper on my application escalation process, delying production updates

[acoliver]

I don't use windows, but..... What virus checker is this? How can your .class files be infected with BATCH file worms/viruses? http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=98955

Grab a copy of the Jboss 3.2.3 cleanly and compare the supposedly infected files. Are they identical? If so, ditch your virus checked and get one that doesn't scare you. Or if you don't want to deal with virus checkers wipe windows off of that box and put Linux on ;-)

[erik777]

I use and love Linux and FreeBSD. Windows is a necessary evil though to ensure and be able to support and document cross-OS compatibility. MySQL and Apache are configured differently on Windows, and are

How can a batch virus infect a class file? The same reason an email can carry any virus/worm payload... to propogate.

AntiVirus eXpert Professional is detecting the payloads.

I'd like to believe these are false positives, and consider it a high possibility, but need to be sure.

The JBoss jars are dated 11/30/03 3:45a. I ran the scan on the files that I had on FreeBSD, which I consider more protected and obtained the same results.

I realize this tempts us to try to deny the possiblity that class files could become infected, or that JBoss might be vulnerable, but this would deny one of the primary benefits of open source... open peer and critical review for security. This is something I believe in, so I believe it's better to discuss the possibility and how we can protect our applications, JVMs and class files in general rather than hope blindly that running on Linux is a cure all for security.

[starksm64]

A class file cannot be infected by virus based on platform native code due to the fact that the byte code is interpreted by the vm and all that could have happened is that the bytecode has been modified. The jboss-3.2.3 md5sums are on http://jboss.org/downloads which can be used to validate the downloaded archive.

[erik777]

Thank you, Scott, for the MD5 link. I was really hoping for come class level checks, but I can md5 the downloaded file, then md5 the individual classes immediately after unarchiving them from a verified tar ball.

I'm also thinking about ways to automate daily class integrity verification in all libraries installed on a machine, including the JVM, the servers, third-party libraries and applications, and custom applications. Personal firewalls already do this for executables on Windows, so why not something that does it for all Java classes?

A Java class can contain ANY payload as data, and then use Java bytecode to install or propogate the "data" when a method is called. The data can end up being a platform dependent virus or anything under the sun. There's no limit to what a class can hold as data.

In other words, it is entirely possible to create a Java class that carries a BAT virus so it can unload and infect Windows machines the class is run on. The Java class can also be used to propogate the virus, perhaps sending out emails. While Linux machines wouldn't be the target for a BAT virus, Java on any OS can be used to propogate it.

A virus scanner simply looks for a payload, which is treated as data for all intents and purposes. Whether or not the file containing the payload has the ability to directly execute it as code, or is simply carrying it for propogation purposes, is irrelevent to the virus scanner.

I believe a JVM can be secured, but I do not believe that security is inherent or automatic. By default, JVMs running local programs are not sandboxed, giving code free reign to access the file system under the user ID the JVM is run under, in addition to access to the Internet.

I believe open discussion of how to secure a JVM and server applications is critical to the long-term success of Java. If we ignore it, it will come back to haunt us, the way it did for Microsoft. I celebrate that people are flocking away from Microsoft because of their security vulnerabilities. Let's not let it happen to us, giving people a reason to continue with or return to Microsoft.

I also consider it a responsibility for anyone creating applications for a client, employer or customer to do the best to provide robust security.

Symantec spots first Java virus (1998)
http://www.cnn.com/TECH/computing/9808/19/javavirus.idg/

java virus (2004)
http://www.computercops.biz/postitle25516-0-0-.html

First 'proof of concept' .Net virus appears (2002)
http://www.computeruser.com/news/02/01/11/news5.html

[starksm64]

Yes, so prove that the virus detector is correctly identifying modified bytecode that is attempting to execute the indicated win32 virus as I don't believe these warnings are correct.

The dist jars could be signed to ensure post installation tampering does not occur.

[erik777]

I'll check it tomorrow, and post the results. I highly suspect that these are false positives, but not for the same reason as you.

I get the impression you're still caught up on the fact that it reported BAT (win32), which is OS dependent. The point I made in the previous post is that Java code could still be used to propogate win32 viruses, even on Linux boxes, because you don't need to execute the virus being propogated to propogate. Propogation can be done entirely with network communications.

However, it's also important to know that Java can execute win32 code. For a project I worked on last year, our tax libraries were compiled in DLL and SO formats for Windows and Linux respectively, with a Java wrapper so we could call them in Java. Thus, Java can call OS specific executables. I'm not sure how the Java wrapper worked, but it worked. I can assure you of that. I do remember that the wrapper used reflection. It loaded the correct libarary at runtime based on what we put in a properties file.

[starksm64]

No, the issue the is fact that a virus utility found a binary fragment that matches an OS specific virus marker in a java class file. This means nothing since the native code cannot be executed from the class file. In order for a java class to exectue native code it must callout through JNI to an OS specific library containing the native code.

Virtually any file type can be used to transport binary code that can be used in the context of a virus. The existence of such binary code in a java class alone can never be a sufficient check for a virus.

[erik777]

Scott,

I'm happy to report that the XmlHelper that the virus scanner gave the alert for has the same md5 of jboss-3.2.3.tgz that I just downloaded and checked the md5 for.

XmlHelper md5:
28ae27543ae18dc9efd144ac456634c6

To tell you the truth, Scott, the BAT virus was never my concern. I simply posted it here because I was hoping that since a JBoss class was included, someone else had the same experience, and could offer some insight from what they learned.

This experience does make me concerned about the prospect of backdoor IRC viruses, though. I'll be thinking a lot more about establishing procedures to ensure the integrity of classes, particularly on production servers. In the meantime, I am glad that I can run it on Linux/BSDs where I can tighten down the file security.

I did put another post though where I ran into a snag tighening down JBoss by running it under a 'jbossuser' with very limitted rights. Primarily, even though I SU'd to 'jbossuser' to run JBoss, it still tried to put the temporary files in the home folder of the original user I logged in as when it compiled JSPs. I can't log in initially as 'jbossuser' because I need the ability to SU as root and don't want to give this ability to 'jbossuser'.

Do you know how to solved the temporary file problem? Is there a way I can tell it where to create temporary files during JSP compilation? This is using JBoss 3.2.3, integrated Tomcat and Jasper.