[FP]: spring-security-crypto 5.7.1

[martijnhoekstra]

Package URl

pkg:maven/org.springframework.security/[email protected]

CPE

cpe:2.3:a:org.springframework.security:spring-security-crypto:5.7.1:::::::*

CVE

CVE-2020-5408

ODC Integration

No response

ODC Version

7.1.0

Description

Description:

Spring Security versions 5.3.x prior to 5.3.2, 5.2.x prior to 5.2.4, 5.1.x prior to 5.1.10, 5.0.x prior to 5.0.16 and 4.2.x prior to 4.2.16 use a fixed null initialization vector with CBC Mode in the implementation of the queryable text encryptor. A malicious user with access to the data that has been encrypted using such an encryptor may be able to derive the unencrypted values using a dictionary attack.

5.7.1 doesn't match the vulnerable version numbers

[github-actions]

Maven Coordinates

<dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-crypto</artifactId>
   <version>5.7.1</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #4528
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/org\.springframework\.security/spring-security-crypto@.*$</packageUrl>
   <cpe>cpe:/a:org.springframework.security:spring-security-crypto</cpe>
</suppress>

Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/2378430452

[bjansen]

It looks like it's caused by OSS Index, see OSSIndex/vulns#276

[tech-consortium]

Suddenly, yesterday, we started seeing a bunch, not just this one dependency reporting to have a CVE. We are still investigating, but either the OSS indexes are wrong or the descriptions of the CVEs because things aren't matching up.

[lako12]

I scanned my spring boot project and detect this CVE. I tried searching around but couldn't figure out how to fix it.
The most interesting thing I found is this:

All users should discontinue the use of Encryptors#queryableText(CharSequence, CharSequence) and rely on their data store for querying encrypted data. Users should perform the following upgrades, as this method has been deprecated in newer versions of Spring Security. Older versions should upgrade to a supported branch. Releases that have fixed this issue include:
Source: https://tanzu.vmware.com/security/cve-2020-5408
This means that I just need to check if my project uses Encryptors#queryableText(CharSequence, CharSequence)?

[norrs]

I assume @jlstephens89 is in dialoge with @jeremylong regarding the false positives that appeard after the oss-index update? As there is several other issues opened related to false reports as well.

@lako12: We have temporary suppressed em for a month at our work place with <suppress until=....>. See https://jeremylong.github.io/DependencyCheck/general/suppression.html

[lako12]

Thanks @norrs I have set the suppression for a month waiting for new updates

[j-s-3]

@norrs All of the cases we've investigated so far have in fact not been false positives but because of the way we're currently presenting the data it is giving that perception. Most of these have been discovered or corrected by Sonatype's human research team.

The additional data that would make it easier for the community to self diagnose/investigate is currently only available within Sonatype's commercial products. We're working on getting some of that data included although it will likely require a free login to ossindex.sonatype.org. We're targeting next week for a release

[AntonOellerer]

@jlstephens89 so does that mean spring-security-crypto 5.7.1 is in fact vulnerable?

[ken-duck]

@AntonOellerer : Correct, spring-security-crypto 5.7.1 is in fact vulnerable in the opinion of the Sonatype security researchers.

The Sonatype security research team discovered that this issue is not yet fixed as new versions simply @Deprecated the vulnerable method, as mentioned in the advisory as opposed to replacing it with a safe alternative. Therefore, these are still flagged as vulnerable.

This is a critical distinction, as people using the deprecated methods in the library might just upgrade thinking they were safe using a newer version, when in reality they are still using the deprecated methods. They might notice the newly deprecated method in their IDE if they happen to look at the method call, or they might not. This is particularly difficult if there is a chain of dependencies leading to the vulnerable package in which case the programmer may never notice that the vulnerable code is still accessed.

One might argue that deprecating the method and putting a note in the advisory is sufficient, but it is our security researchers opinion that the vulnerable code is still there and easily accessible, and therefore have opted to leave the CVE open ended until such a time that the offending method is fixed or removed.

[AntonOellerer]

@ken-duck thank you very much for the fast and expansive explanation!

[aikebah]

The definitive resolution of this issue (removal of the code) is tracked by Spring-security as spring-projects/spring-security#8980 and currently linked to their 6.0.x milestone

[ken-duck]

@aikebah Thanks for the information, that's great to hear. I will forward this thread to our security researchers, who I am sure will be quite eager to hear.