Regression: Dependency Check detects false positive CVE-2015-9097 on javax.mail 1.5.6

[joergsesterhenn]

Issue Type:

• defect report
• enhancement request

Current Behavior:

Via Dependency-Track the following gap was marked for all applications:
javax.mail 1.5.6 com.sun.mail NVD CVE-2015-9097
CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')

This is based on the component org.apache.commons:commons-email.

However, the CVE states that it refers to Ruby:

" The mail gem before 2.5.5 for Ruby (aka A Really Ruby Mail Library) is vulnerable to SMTP command injection via CRLF sequences in a RCPT TO or MAIL FROM command, as demonstrated by CRLF sequences immediately before and after a DATA substring."

So it represents a false positive for us. It has already been reported to Dependecy-Check (jeremylong/DependencyCheck#912, resp. jeremylong/DependencyCheck#895). Those are supposedly fixed for 3.0.

Steps to Reproduce (if defect):

Scan project using component 'javax.mail 1.5.6' mentioned above.

Expected Behavior:

Vulnerability should not show up.

Environment:

• Dependency-Track Version: 3.3
• Distribution: [ Docker ]
• BoM Format & Version: CycloneDX
• Database Server: [ H2 ]
• Browser: Firefox

Other Details:

see above

[msymons]

using Dependency-Track v3.3.1 with CycloneDX Maven Plugin, I see the exact same threat identified for:

• pkg:maven/javax.mail/javax.mail-api@1.6.1?type=jar
• pkg:maven/com.sun.mail/javax.mail@1.4.4 (Filename glassfish-embedded-all-3.1.2.2.jar (shaded: com.sun.mail:javax.mail:1.4.4)

[stevespringett]

@joergsesterhenn have you enabled OSSIndex? Also, whatever was reported to Dependency-Check may or may not work with Dependency-Track. This is due to the fact that Dependency-Check relies on evidence and Dependency-Track requires facts. With CycloneDX you're getting facts. But in order to benefit from that, you need to enable OSSIndex and disable Dependency-Check.

Also note, this is not a defect. If you look at the suppressions for Dependency-Check, most of them rely on evidence from the various file analyzers, not on descriptive evidence such as GAVs. So you cannot rely on dependency-check base suppressions as many/most of them will not work with Dependency-Track. Again, if you're using CycloneDX, there's a good possibility you can safely disable the Dependency-Check scanner. But if you can't, Dependency-Track allows you to have a global suppression file specific for Dependency-Track which would allow you to put in suppressions that actually work.

[joergsesterhenn]

@stevespringett : we have not yet enabled ossindex.

Also, whatever was reported to Dependency-Check may or may not work with Dependency-Track. This is due to the fact that Dependency-Check relies on evidence and Dependency-Track requires facts. With CycloneDX you're getting facts. But in order to benefit from that, you need to enable OSSIndex and disable Dependency-Check.

IMHO this is important information that should be pointed out by dependency-track itself, or at least be part of the documentation. There is no way I could have figured this out by using the tool or reading the docs. Please consider adding the information to the docs or the ui.

[stevespringett]

Most of this information exists but is scattered between various docs, YouTube channel, and the product itself, but what is missing is more prescriptive use-cases and best-practices. Completely agree.

I'm currently writing docs for the upcoming release of v3.4 and will hopefully be able to create such documentation. I've created #247 to track this work.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.