Hi, I think it is a good idea implementing this upstream in wildfly, as this tool requires POM modifications. This tool would help us tracking security vulnerabilities proactively rather than retroactively both in wildfly and Enterprise Platforms. Are you OK with that? Cheers, Vaclav On 05/27/2013 07:03 AM, David Jorm wrote: > Hi All > > First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation: > > http://www.victi.ms/about.html > > enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central: > > http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi... > > Please see the README.md and sample app here for configuration details: > > https://github.com/victims/victims-enforcer > > I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database. > > What do people think? Is this something you'd consider implementing? > > Thanks -- Vaclav Tunka Enterprise Application Platforms JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

The possible false negatives (as David mentioned in his original email) can also complicate otherwise successful builds. The following error message might have been caused by gaps in the database, though it's not clear which dependency it is complaining about. [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: Could not determine vulnerabilities for hash: 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472

Yes, the build failed. This plugin can be configured to WARNING level in the pom, but we then we won't catch the real problems. In the test run, I just copied the pom snippet from https://github.com/victims/victims-enforcer In my case, the failed test project is https://github.com/jberet/jsr352/blob/master/test-apps/postConstruct/pom.xml, which has just 1 direct dependency: an internal peer sub-module, which I guess is not known to the scanner database. Probably that's why it failed? But other similarlly-structured sub-modules passed (e.g., https://github.com/jberet/jsr352/blob/master/test-apps/propertyInjection/...) Cheng On 5/29/13 9:55 AM, Brian Stansberry wrote: > On 5/28/13 9:56 PM, Cheng Fang wrote: >> The possible false negatives (as David mentioned in his original email) >> can also complicate otherwise successful builds. The following error >> message might have been caused by gaps in the database, though it's not >> clear which dependency it is complaining about. >> >> [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: >> Could not determine vulnerabilities for hash: >> 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472 >> > Does that fail the build, or is the problem limited to noise in the > build log? > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

This bug is now fixed in enforce-victims-rule 1.3, which was released to maven central today. This release also includes a range of performance improvements, including caching, which significantly improves performance after the first build of a given project. We have tested it with WildFly 8 on a system where build time without the plugin was 10 minutes. With the plugin, the first build took 19 minutes, and all subsequent builds took 11 minutes. Can you please rm -rf ~/.victims/ then update your POM to reference enforce-victims-rule 1.3 and try again? Thanks David > Thanks for reporting this issue. We suspect it is actually a bug in the > victims library, as false negatives or artifacts that do not exist in the > DB > should simply pass inspection with no warning or failure. We've fixed the > suspected bug and we're currently working on an updated release, I will > respond to the list once that is complete so you can test. > > Thanks > David > > > Yes, the build failed. This plugin can be configured to WARNING level > > in the pom, but we then we won't catch the real problems. In the test > > run, I just copied the pom snippet from > > https://github.com/victims/victims-enforcer > > > > In my case, the failed test project is > > https://github.com/jberet/jsr352/blob/master/test-apps/postConstruct/pom.xml, > > which has just 1 direct dependency: an internal peer sub-module, which I > > guess is not known to the scanner database. Probably that's why it > > failed? But other similarlly-structured sub-modules passed (e.g., > > https://github.com/jberet/jsr352/blob/master/test-apps/propertyInjection/...) > > > > Cheng > > > > On 5/29/13 9:55 AM, Brian Stansberry wrote: > > > On 5/28/13 9:56 PM, Cheng Fang wrote: > > >> The possible false negatives (as David mentioned in his original > > >> email) > > >> can also complicate otherwise successful builds. The following error > > >> message might have been caused by gaps in the database, though it's > > >> not > > >> clear which dependency it is complaining about. > > >> > > >> [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > > >> Could not determine vulnerabilities for hash: > > >> 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472 > > >> > > > Does that fail the build, or is the problem limited to noise in the > > > build log? > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Thanks David for the update. I tried rule version 1.3.1 on wildfly by adding the configuration snippet to root pom.xml. After removing ~/.victims, and doing ./build.sh clean install, it took about 15 minutes 34 seconds to complete. The message "Checking for new vulnerabilities..." appeared 122 times. The first time it tries to initialize the victim database, it took maybe 10-15 seconds, and the rest 121 times took 3-4 seconds each. So roughly the time spent on checking for vulnerabilities updates are about 5-6 minutes. Running build.sh clean installl a second time with the plugin took 9:52.217s. It would be nice if it only checks for vulnerabilities update once per mvn run, or once during a certain time period (say 8 hours). Cheng On 6/12/13 9:24 PM, David Jorm wrote: Hi All Just following up on this. Has anyone had a chance to test a build of WildFly with enforce-victims-rule 1.3? From my perspective I think it should be ready to use. Thanks David This bug is now fixed in enforce-victims-rule 1.3, which was released to maven central today. This release also includes a range of performance improvements, including caching, which significantly improves performance after the first build of a given project. We have tested it with WildFly 8 on a system where build time without the plugin was 10 minutes. With the plugin, the first build took 19 minutes, and all subsequent builds took 11 minutes. Can you please rm -rf ~/.victims/ then update your POM to reference enforce-victims-rule 1.3 and try again? Thanks David Thanks for reporting this issue. We suspect it is actually a bug in the victims library, as false negatives or artifacts that do not exist in the DB should simply pass inspection with no warning or failure. We've fixed the suspected bug and we're currently working on an updated release, I will respond to the list once that is complete so you can test. Thanks David Yes, the build failed. This plugin can be configured to WARNING level in the pom, but we then we won't catch the real problems. In the test run, I just copied the pom snippet from https://github.com/victims/victims-enforcer In my case, the failed test project is https://github.com/jberet/jsr352/blob/master/test-apps/postConstruct/pom.xml , which has just 1 direct dependency: an internal peer sub-module, which I guess is not known to the scanner database. Probably that's why it failed? But other similarlly-structured sub-modules passed (e.g., https://github.com/jberet/jsr352/blob/master/test-apps/propertyInjection/... ) Cheng On 5/29/13 9:55 AM, Brian Stansberry wrote: On 5/28/13 9:56 PM, Cheng Fang wrote: The possible false negatives (as David mentioned in his original email) can also complicate otherwise successful builds. The following error message might have been caused by gaps in the database, though it's not clear which dependency it is complaining about. [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: Could not determine vulnerabilities for hash: 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472 Does that fail the build, or is the problem limited to noise in the build log? _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> With this setting in place, do you think we're in a position to try > committing the plugin configuration to a dedicated maven profile in the > root pom.xml, and setting up a jenkins job to run builds using that > profile? That would make sense, as running this as part of every build would be too time consuming for most developers. -- tomaz

I think as a first step, someone familiar with this plugin should raise a PR against WildFly upstream with the suggested approach of using a Maven profile to trigger it. Depending on what the PR looks like, it might need further changes or might be reviewed and merged. -Jaikiran On Monday 19 August 2013 11:27 AM, David Jorm wrote: >>> With this setting in place, do you think we're in a position to try >>> committing the plugin configuration to a dedicated maven profile in the >>> root pom.xml, and setting up a jenkins job to run builds using that >>> profile? >> >> >> That would make sense, as running this as part of every build would be too >> time consuming for most developers. >> >> -- >> tomaz >> > Sorry to be a broken record, but would it be possible to implement this? We're starting to get contributions to the victims database from other parties, so there is increasing value to its usage in wildfly. > > Thanks > David > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Security vulnerability is s specialized area, and I would avoid incurring this overhead on every build run by every developer. To incorporate the victim scanning into upstream project, I would suggest having a dedicated Jenkins job, or adding this capability into existing Jenkins job. I tried it on jberet project by adding the plugin to the top-level pom. For every sub-module, it tries to get the updates from the central server, which lasts a couple seconds each time, and this can add up to significant delay: [INFO] Retrieving updates from http://www.victi.ms/service/... The possible false negatives (as David mentioned in his original email) can also complicate otherwise successful builds. The following error message might have been caused by gaps in the database, though it's not clear which dependency it is complaining about. [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: Could not determine vulnerabilities for hash: 8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472 Cheng On 5/27/13 10:16 AM, Vaclav Tunka wrote: > Hi, > > I think it is a good idea implementing this upstream in wildfly, as this > tool requires POM modifications. This tool would help us tracking > security vulnerabilities proactively rather than retroactively both in > wildfly and Enterprise Platforms. > > Are you OK with that? > > Cheers, > Vaclav > > On 05/27/2013 07:03 AM, David Jorm wrote: >> Hi All >> >> First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation: >> >> http://www.victi.ms/about.html >> >> enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central: >> >> http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi... >> >> Please see the README.md and sample app here for configuration details: >> >> https://github.com/victims/victims-enforcer >> >> I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database. >> >> What do people think? Is this something you'd consider implementing? >> >> Thanks >> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> Hi All > > First I should introduce myself for those who don't know me, as I have > not participated in wildfly dev discussions before. I am a security > response engineer working for Red Hat, handling security patches for the > commercial JBoss products. Recently some colleagues and I have been > working on a tool called 'victims'. The victims tool aims to provide a > canonical database of known-vulnerable JAR files, along with tools that > allow developers and system administrator to determine whether their > projects and systems contain any known-vulnerable JARs. The project's > about page contains a more detailed explanation: > > http://www.victi.ms/about.html > > enforce-victims-rule is a maven plugin that walks the dependency tree at > build time, and uses the victims database to check whether a project is > including any known-vulnerable JARs as dependencies. The plugin is > available on maven central: > > http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi... > > Please see the README.md and sample app here for configuration details: > > https://github.com/victims/victims-enforcer > > I think there would be great value in incorporating this plugin into the > wildfly POM(s). It can catch security flaws at build time, eliminating > the need for much more work to ship patches for flaws later down the > line. It is also designed such that it should not trigger any false > positives. There will be false negatives where there are gaps in the > database. > > What do people think? Is this something you'd consider implementing? What is the build time performance impact? Is there a network lookup, i.e. will it cause a problem on non-network-connected systems (like laptops for those of us who travel)? -- - DML

> Network lookup: By default, the plugin synchronizes a local h2 database > with the canonical database hosted on victi.ms. The sync is > differential. At the moment, the initial sync is > 50MB and could take a > minute or two. 50MB? Holy meatballs... is that a simple text listing of compromised GAVs? If so, that is truly terrifying.