Bad Java, BAD! No More Jars!
@ 2010-03-27 23:26:42
Filed under: Code Tech Security Frustration Python
A big frustration for me is the sprawl of Jar's (java "packages") which are everywhere. These special zip files tend to be copied into other applications and then left alone. Many of these Jar's have newer releases to fix security issues, but the bundled version isn't updated. It's even worse that many Jar's don't provide enough meta information that you can be sure of who owns it. Yes, you could keep SHA1SUM's in a database like maven does, and that is better than nothing, but it's not really a fix, it's a hack.
Here is an example of metadata that came with one Jar:
How helpful! Well, we can at least see what it is by the name of the file: sqlitejdbc.jar. It still doesn't tell us what version. Let's look at another:
Better, but still isn't that helpful. In this case we get lucky as some of the info is in the file name: gettext-commons-0.9.6.jar.
It really seems like the whole 'keep metadata in your Jar' is more of an inside joke which requires a hack to try to track what jars to include (as maven does). Welcome to Jar hell. How fun. Anyway, here is another hack ...
For the heck of it I decided to write a very simple scanner. It reads the metadata from the Jar file and then tries to match it up against an online database. If it gets no results back it keeps it as 'either safe or not enough information'. If there isn't even enough data to make a call out to the database it's assumed bad and tells you the user to bother about it if that is listed, and if the database confirms vulnerabilities it's known bad. It needs a lot of work to better guess information not provided by the metadata but here is an example run (with some changes to protect the guilty)
I'm tired. I'm going to bed. I'll throw the code up somewhere tomorrow.
digg it
seed it
del.icio.us
ma.gnolia
Log in to post comments.
Filed under: Code Tech Security Frustration Python
A big frustration for me is the sprawl of Jar's (java "packages") which are everywhere. These special zip files tend to be copied into other applications and then left alone. Many of these Jar's have newer releases to fix security issues, but the bundled version isn't updated. It's even worse that many Jar's don't provide enough meta information that you can be sure of who owns it. Yes, you could keep SHA1SUM's in a database like maven does, and that is better than nothing, but it's not really a fix, it's a hack.
Here is an example of metadata that came with one Jar:
Manifest-Version: 1.0 Created-By: 1.6.0_10 (Sun Microsystems Inc.)
How helpful! Well, we can at least see what it is by the name of the file: sqlitejdbc.jar. It still doesn't tell us what version. Let's look at another:
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: fberger Build-Jdk: 1.6.0_06
Better, but still isn't that helpful. In this case we get lucky as some of the info is in the file name: gettext-commons-0.9.6.jar.
It really seems like the whole 'keep metadata in your Jar' is more of an inside joke which requires a hack to try to track what jars to include (as maven does). Welcome to Jar hell. How fun. Anyway, here is another hack ...
For the heck of it I decided to write a very simple scanner. It reads the metadata from the Jar file and then tries to match it up against an online database. If it gets no results back it keeps it as 'either safe or not enough information'. If there isn't even enough data to make a call out to the database it's assumed bad and tells you the user to bother about it if that is listed, and if the database confirms vulnerabilities it's known bad. It needs a lot of work to better guess information not provided by the metadata but here is an example run (with some changes to protect the guilty)
$ python jarscanner.py *jar
WARNING:root:apache-mime4j-0.6.jar is the latest secure version or not enough info
WARNING:root:commons-codec-1.3.jar is the latest secure version or not enough info
WARNING:root:commons-logging-1.1.1.jar is the latest secure version or not enough info
WARNING:root:hsqldb.jar is the latest secure version or not enough info
WARNING:root:httpclient-4.0.jar is the latest secure version or not enough info
WARNING:root:httpcore-4.0.1.jar is the latest secure version or not enough info
WARNING:root:httpmime-4.0.jar is the latest secure version or not enough info
INFO:root:jetty-6.1.7.jar found 15 vulns
INFO:root:jetty-util-6.1.7.jar found 15 vulns
WARNING:root:servlet-api-2.5-6.1.7.jar is the latest secure version or not enough info
WARNING:root:The following jars are known to be bad ...
WARNING:root:jetty-6.1.7.jar
WARNING:root:jetty-util-6.1.7.jar
CRITICAL:root:Sorry, but a number of jars are crap and don't provide enough information.
These should be assumed bad!!!
CRITICAL:root:bdiff.jar
CRITICAL:root:fast-md5.jar (go bug dragonlz about it)
CRITICAL:root:gettext-commons-0.9.6.jar (go bug fberger about it)
CRITICAL:root:jcip-annotations.jar
CRITICAL:root:linuxfolderwatcher.jar
CRITICAL:root:messages.jar
CRITICAL:root:snakeyaml-1.5.jar (go bug somov about it)
CRITICAL:root:sqlitejdbc.jar
CRITICAL:root:stringtree-json-2.0.9.jar
CRITICAL:root:swt.jar
CRITICAL:root:unixapi.jar
CRITICAL:root:XXXXXXXXXX.jar
CRITICAL:root:XXXXXXXXXX.jar
I'm tired. I'm going to bed. I'll throw the code up somewhere tomorrow.
digg it
seed it
del.icio.us
ma.gnolia
Log in to post comments.
