In 2013, OWASP added a new item to the top 10: "Using Components with Known Vulnerabilities". Java build systems such as maven allow developers to easily incorporate a complex tree of third-party components into their applications, potentially exposing the issue of using components with known vulnerabilities. To address this, the victims project provides a canonical database of known-vulnerable JAR files, along with tools to compare this database to Java applications in development, release and production environments.
Maven is currently the dominant build tool for enterprise Java applications. It has been rapidly adopted by developers, as it offers a powerful solution to the problem of dependency management, coupled with a huge public repository of open source components called maven central. From a developer's perspective, maven makes things very easy: just add a reference to a particular component in pom.xml. For example, to include Spring 2.5.6 in your project, just add:
<dependency> <groupId>org.springframework</groupId> <artifactId>spring</artifactId> <version>2.5.6</version> </dependency>
From a security perspective however, there is a big problem. What happens if Spring 2.5.6 has a major security flaw (which it does)? The project needs to be rebuilt with an updated reference to the patched version of Spring - in this case, Spring 2.5.6.SEC03, since there have been 3 major security flaws found in Spring 2.5.6. Sonatype, the company behind maven, has publicly acknowleged that managing such dependency updates is a major problem. One of the key recommendations of Sonatype's study is to enforce scans of dependencies against a known vulnerability database. Victims is an open source known vulnerability database for Java components.
Sonatype's study highlights that this problem is both endemic and fractal. For example, 1447 projects rely on spring, all of which need to be updated with a reference to a patched version when one is made available. At the same time, there are no good mechanisms for people to know when a component needs to be updated. This problem is particularly acute because of the design of Java packaging and dependency management systems.
All Linux distributions have a package management system that ensures a single version of a component is shared by all applications which depend on it. You patch that one component, and you're done. The maven approach is analogous to having a Linux distribution where every package is statically compiled against all of its dependencies. This makes things easy for a developer of a given package - they can choose to base on particular dependency versions. It makes things very difficult for system administrators trying to handle patch management. Victims aims to address this problem by making it possible to scan for known vulnerable dependencies at build time, and to analyze compiled Java applications to determine whether they include known vulnerable dependencies.
Java components are provided as JAR files. JARs are zip files with a standard layout, consisting of individual compiled classes and metadata in META-INF/MANIFEST.MF. An example MANIFEST.MF file follows:
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: someguy Build-Jdk: 1.6.0_06A simple approach would be to fingerprint known vulnerable JARs based purely on their metadata. This approach has limited use, since the metadata elements are not mandatory. Many JARs omit them entirely, and others fail to increment the version when a security patch is applied. Victims can identify known vulnerable JARs based on metadata, but this is secondary to the main hashing mechanism.
Version 1 of victims used SHA checksums of JAR files to identify known vulnerable versions. This also turned out to have limited use, as any recompile of a JAR from the same source code would result in a different checksum. Version 2 of victims now uses a more advanced hashing mechanism, which is able to identify rebuilds based on a single canonical hash.
The victims database is primarily maintained by the Red Hat Security Response Team, who populate it for vulnerabilities that affect Java components shipped in Red Hat products. Community contributions to the database are welcome and encouraged.