aquasecurity / trivy

Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
https://aquasecurity.github.io/trivy
Apache License 2.0
23.29k stars 2.3k forks source link

CVE-2022-31692 detected on spring-security-core but should be spring-security-web only #5169

Open nikpivkin opened 1 year ago

nikpivkin commented 1 year ago

Discussed in https://github.com/aquasecurity/trivy/discussions/5122

Originally posted by **mischa-n** September 5, 2023 ### IDs CVE-2022-31692 ### Description This is a follow-up ticket for https://gitlab.com/gitlab-org/security-products/gemnasium-db/-/issues/245 In an image with Spring Security 5.7.9 or 5.7.10, Trivy incorrectly finds CVE-2022-31692 in spring-security-core (and correctly does not find it in spring-security-web). The cause could be an incorrect interpretation of https://gitlab.com/gitlab-org/advisories-community/-/blob/main/maven/org.springframework.security/spring-security-core/CVE-2022-31692.yml?ref_type=heads#L11 affected_range: "(0)": this is supposed to signal that no version is affected. On the other hand, Trivy does not seem to find the CVE when using Spring Security 6.x.x, so the situation or cause is not entirely clear. ### Reproduction Steps ```bash 1. create image with spring-boot-maven-plugin 2. analyze with docker run --volume /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:latest image --format=json --debug ``` ### Target Container Image ### Scanner Vulnerability ### Target OS ubuntu: os version: 18.04 ### Debug Output ```bash 2023-09-05 07:50:37 { 2023-09-05 07:50:37 "VulnerabilityID": "CVE-2022-31692", 2023-09-05 07:50:37 "PkgName": "org.springframework.security:spring-security-core", 2023-09-05 07:50:37 "FixedVersion": "5.6.9, 5.7.5", 2023-09-05 07:50:37 "Status": "fixed", 2023-09-05 07:50:37 "Layer": { 2023-09-05 07:50:37 "DiffID": "sha256:###" 2023-09-05 07:50:37 }, 2023-09-05 07:50:37 "SeveritySource": "nvd", 2023-09-05 07:50:37 "PrimaryURL": "https://avd.aquasec.com/nvd/cve-2022-31692", 2023-09-05 07:50:37 "PkgRef": "pkg:maven/org.springframework.security/spring-security-core?package-id=d9715c3dae047259", 2023-09-05 07:50:37 "DataSource": { 2023-09-05 07:50:37 "ID": "glad", 2023-09-05 07:50:37 "Name": "GitLab Advisory Database Community", 2023-09-05 07:50:37 "URL": "https://gitlab.com/gitlab-org/advisories-community" 2023-09-05 07:50:37 }, 2023-09-05 07:50:37 "Title": "Authorization rules can be bypassed via forward or include dispatcher types in Spring Security", 2023-09-05 07:50:37 "Description": "Spring Security, versions 5.7 prior to 5.7.5 and 5.6 prior to 5.6.9 could be susceptible to authorization rules bypass via forward or include dispatcher types. Specifically, an application is vulnerable when all of the following are true: The application expects that Spring Security applies security to forward and include dispatcher types. The application uses the AuthorizationFilter either manually or via the authorizeHttpRequests() method. The application configures the FilterChainProxy to apply to forward and/or include requests (e.g. spring.security.filter.dispatcher-types = request, error, async, forward, include). The application may forward or include the request to a higher privilege-secured endpoint.The application configures Spring Security to apply to every dispatcher type via authorizeHttpRequests().shouldFilterAllDispatcherTypes(true)", 2023-09-05 07:50:37 "Severity": "CRITICAL", 2023-09-05 07:50:37 "CVSS": { 2023-09-05 07:50:37 "ghsa": { 2023-09-05 07:50:37 "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", 2023-09-05 07:50:37 "V3Score": 9.8 2023-09-05 07:50:37 }, 2023-09-05 07:50:37 "nvd": { 2023-09-05 07:50:37 "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", 2023-09-05 07:50:37 "V3Score": 9.8 2023-09-05 07:50:37 }, 2023-09-05 07:50:37 "redhat": { 2023-09-05 07:50:37 "V3Vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N", 2023-09-05 07:50:37 "V3Score": 7.4 2023-09-05 07:50:37 } 2023-09-05 07:50:37 }, 2023-09-05 07:50:37 "References": [ 2023-09-05 07:50:37 "https://access.redhat.com/security/cve/CVE-2022-31692", 2023-09-05 07:50:37 "https://github.com/advisories/GHSA-mmmh-wcxm-2wr4", 2023-09-05 07:50:37 "https://github.com/spring-projects/spring-security", 2023-09-05 07:50:37 "https://nvd.nist.gov/vuln/detail/CVE-2022-31692", 2023-09-05 07:50:37 "https://security.netapp.com/advisory/ntap-20221215-0010/", 2023-09-05 07:50:37 "https://spring.io/security/cve-2022-31692", 2023-09-05 07:50:37 "https://tanzu.vmware.com/security/cve-2022-31692", 2023-09-05 07:50:37 "https://www.cve.org/CVERecord?id=CVE-2022-31692" 2023-09-05 07:50:37 ], 2023-09-05 07:50:37 "PublishedDate": "2022-10-31T20:15:00Z", 2023-09-05 07:50:37 "LastModifiedDate": "2023-08-08T14:22:00Z" 2023-09-05 07:50:37 } ``` ### Version ```bash Version: 0.45.0 ``` ### Checklist - [X] Read [the documentation regarding wrong detection](https://aquasecurity.github.io/trivy/dev/community/contribute/discussion/#false-detection) - [X] Ran Trivy with `-f json` that shows data sources and confirmed that the security advisory in data sources was correct
knqyf263 commented 1 year ago

@nikpivkin Is it our issue? Or a data source issue?

nikpivkin commented 1 year ago

@knqyf263 It seems to me this issue is related to the Trivy.

knqyf263 commented 1 year ago

Thanks for confirming. Let's look into it, then.