Problem/Motivation
When using the experimental OWAS depency check, the results should reports valid issues. It also should be consitant with composer audit or drush sec.
Instead it returns very old CVE that does not match exactly the installed modules/package name or version.
I understand that its still an experimental feature, but since its widely used tools, it worths the try to fix it, either on the Drupal side or on the OWASP one.
https://jeremylong.github.io/DependencyCheck/analyzers/index.html
https://jeremylong.github.io/DependencyCheck/analyzers/composer-lock.html
Steps to reproduce
# Install a drupal version with no core drupal security issues (9.4.10), one symfony issue.
composer create-project drupal/recommended-project:9.4.10 . --stability dev --no-interaction --no-install
# Install modules with security issues.
composer require drush/drush drupal/rest_views drupal/views_attach_library drupal/views_bulk_operations drupal/views_data_export drupal/views_field_compare drupal/leaflet_views
# Check for security issues "the composer way"
composer audit --locked
Found 1 security vulnerability advisory affecting 1 package:
+-------------------+----------------------------------------------------------------------------------+
| Package | symfony/http-kernel |
| CVE | CVE-2022-24894 |
| Title | CVE-2022-24894: Prevent storing cookie headers in HttpCache |
| URL | https://symfony.com/cve-2022-24894 |
| Affected versions | >=2.0.0,<2.1.0|>=2.1.0,<2.2.0|>=2.2.0,<2.3.0|>=2.3.0,<2.4.0|>=2.4.0,<2.5.0|>=2.5 |
| | .0,<2.6.0|>=2.6.0,<2.7.0|>=2.7.0,<2.8.0|>=2.8.0,<3.0.0|>=3.0.0,<3.1.0|>=3.1.0,<3 |
| | .2.0|>=3.2.0,<3.3.0|>=3.3.0,<3.4.0|>=3.4.0,<4.0.0|>=4.0.0,<4.1.0|>=4.1.0,<4.2.0| |
| | >=4.2.0,<4.3.0|>=4.3.0,<4.4.0|>=4.4.0,<4.4.50|>=5.0.0,<5.1.0|>=5.1.0,<5.2.0|>=5. |
| | 2.0,<5.3.0|>=5.3.0,<5.4.0|>=5.4.0,<5.4.20|>=6.0.0,<6.0.20|>=6.1.0,<6.1.12|>=6.2. |
| | 0,<6.2.6 |
| Reported at | 2023-02-01T08:00:00+00:00 |
+-------------------+----------------------------------------------------------------------------------+
# Check for security issues "the drupal way" (outdated ?)
drush sec
[success] There are no outstanding security updates for Drupal projects.
# Check for security issues with owasp dependency check
docker run --rm -e user=$USER -u $(id -u ${USER}):$(id -g ${USER}) --volume dependency-check:/usr/share/dependency-check/data:z --volume $(pwd):/src:z owasp/dependency-check:latest --scan ./composer.lock --format "ALL" --project dependency-check scan: $(pwd) --out /src --enableExperimental
leaflet_views:2.2.12 cpe:2.3:a:drupal:views:2.2.12:*:*:*:*:*:*:* CVE-2008-6020
pear-core-minimal:1.10.11 cpe:2.3:a:pear:pear:1.10.11:*:*:*:*:*:*:* CVE-2009-4024
pear_exception:1.0.2 cpe:2.3:a:pear:pear:1.0.2:*:*:*:*:*:*:* CVE-2009-4024
rest_views:2.0.1 cpe:2.3:a:drupal:views:2.0.1:*:*:*:*:*:*:* CVE-2008-6020
views_attach_library:2.0.2 cpe:2.3:a:drupal:views:2.0.2:*:*:*:*:*:*:* CVE-2008-6020
views_bulk_operations:4.2.3 cpe:2.3:a:drupal:views:4.2.3:*:*:*:*:*:*:* CVE-2009-0575
cpe:2.3:a:drupal:views_bulk_operations:4.2.3:*:*:*:*:*:*:* CVE-2009-0575
views_data_export:1.2.0 cpe:2.3:a:drupal:data:1.2.0:*:*:*:*:*:*:* ????
cpe:2.3:a:drupal:views:1.2.0:*:*:*:*:*:*:* CVE-2008-6020
views_field_compare:1.0.0 cpe:2.3:a:drupal:views:1.0.0:*:*:*:*:*:*:* CVE-2008-6020
Pear and Views seems out of the Drupal scope.
views_bulk_operations is certainly due to the old Drupal version format, hence views_bulk_operations:4.2.3 match Drupal 4 version.
Comments
Comment #2
o'briatComment #3
cilefen commentedI can't reproduce the
composer auditfinding on branch 10.0.x by typingcomposer install && composer audit. And those Symfony library pins released in 10.0.3. I don't see how that one is valid. I think that section should be removed from the issue summary so as not to confuse everyone.I am glad someone is testing out the OWASP tool because I had been meaning to look at it. Thank you for using Docker so others can reproduce the results.
Is there a way to run the tool in a more verbose mode so we can understand how the software determines these very old issues exist?
Are you definitely sure that the tool is listing these as issues, or as any CVE ever to affect that project?
Comment #4
o'briatComment #5
larowlanI'm not sure why this is filed against Drupal core? Shouldn't it be against the OWASP tool instead?
Comment #6
cilefen commentedComment #7
o'briat@cilefen: This core issue should reproduce with a drupal/core 9.4.10.
@larowlan I add a comment on this issue: https://github.com/jeremylong/DependencyCheck/issues/1387
This current Drupal issue should be left open at least to track the problem (SEO) and I think some problem are unique to the Drupal way of version numbering: first locking major to core version as major, then free it again.
Maybe this wrong version matching could only be fixed by using specific options ?
Comment #8
o'briatComment #9
cilefen commentedDrupal 9.4.11 exists. I don’t understand the purpose of this issue.
Comment #10
o'briatThis point is NOT a security issue, it's about why depency-check returns false positive or miss vulnerabilities.
Some problems come from the tool itself but other are Drupal dependant (version numbering at least).
The goal is either to fix the Drupal side issues or to help depency-check to be more reliable since OWASP is the de-facto security standard.
My example above is just here to help to reproduce the problem.
Comment #11
cilefen commentedAh, understood. So in #7 you mean that there is in fact a library with a security bug in
symfony/http-kernelthatcomposer auditdetects, and yet the OWASP tool does not detectsymfony/http-kernel, and the OWASP tool detects different things which are false.Comment #12
o'briatYes, that what I mean(it could be due to my bad english :))
Once again this issue is mainly "for the record" and to keep track of the "OWASP" problem.
On the Drupal side, the first task IMHO will be to discover why this tool (or the CVE database) mixes packages names. How an issue opened on View 6.x-2.2 14 years ago (https://nvd.nist.gov/vuln/detail/CVE-2008-6020) matches with leaflet_views:2.2.12?
Maybe someone here could help the depency-check team to improve it ? Check the ComposerLockAnalyzer class:
https://github.com/jeremylong/DependencyCheck/blob/main/core/src/main/ja...
Comment #14
smustgrave commentedld this be reopened?
Comment #15
o'briatComment #16
smustgrave commentedFollowing up again if this should be re-open. If no reason to in D11 then will close in 3 months.
Comment #17
smustgrave commentedSince there's been no follow up going to close out. If still a valid task please re-open.