Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False negative: vulns in AL2023 rpm packages were reported but then disappeared #2333

Open
sparrowt opened this issue Dec 16, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@sparrowt
Copy link
Contributor

What happened:

One day our nightly audit run flagged 4 x rpm vulns in an Amazon Linux 2023 based image (13 Dec 2024, ~21:00)

+ grype -o template -t grypeoutput.tmpl --fail-on low my-image:myversion

TYPE    NAME                    INSTALLED               VULN                  SEVERITY      FIXED?     FIXED IN              UPSTREAM PACKAGE           DATASOURCE
python  Django                  4.2.16                  GHSA-m9g8-fxxm-xg86   High          fixed      4.2.17                                           https://github.com/advisories/GHSA-m9g8-fxxm-xg86
python  Django                  4.2.16                  GHSA-8498-2h75-472j   Medium        fixed      4.2.17                                           https://github.com/advisories/GHSA-8498-2h75-472j
rpm     libxml2                 2.10.4-1.amzn2023.0.6   ALAS-2024-783         Medium        fixed      2.10.4-1.amzn2023.0.7                             https://alas.aws.amazon.com/AL2023/ALAS-2024-783.html
rpm     python3                 3.9.16-1.amzn2023.0.9   ALAS-2024-770         High          fixed      3.9.20-1.amzn2023.0.1  {python3.9 3.9.16-1.amzn2023.0.9}  https://alas.aws.amazon.com/AL2023/ALAS-2024-770.html
rpm     python3-libs            3.9.16-1.amzn2023.0.9   ALAS-2024-770         High          fixed      3.9.20-1.amzn2023.0.1  {python3.9 3.9.16-1.amzn2023.0.9}  https://alas.aws.amazon.com/AL2023/ALAS-2024-770.html
rpm     python3-pip-wheel       21.3.1-2.amzn2023.0.9   ALAS-2024-781         Medium        fixed      21.3.1-2.amzn2023.0.10  {python-pip 21.3.1-2.amzn2023.0.9}  https://alas.aws.amazon.com/AL2023/ALAS-2024-781.html
--
Results for:    my-image:myversion
Scanned by:     grype v0.74.6
Vuln DB date:   2024-12-13 01:32:17 +0000 UTC
--
discovered vulnerabilities at or above the severity threshold

but then the next day on the same code, those reported vulns were no longer reported (14 Dec 2024, ~21:00)

+ grype -o template -t grypeoutput.tmpl --fail-on low my-image:myversion

TYPE    NAME                    INSTALLED               VULN                  SEVERITY      FIXED?     FIXED IN              UPSTREAM PACKAGE           DATASOURCE
python  Django                  4.2.16                  GHSA-m9g8-fxxm-xg86   High          fixed      4.2.17                                           https://github.com/advisories/GHSA-m9g8-fxxm-xg86
python  Django                  4.2.16                  GHSA-8498-2h75-472j   Medium        fixed      4.2.17                                           https://github.com/advisories/GHSA-8498-2h75-472j
--
Results for:    my-image:myversion
Scanned by:     grype v0.74.6
Vuln DB date:   2024-12-14 01:31:37 +0000 UTC
--
discovered vulnerabilities at or above the severity threshold

However the vulnerable package versions e.g. libxml2 version 2.10.4-1.amzn2023.0.6 are still present in the image.

(The Django vulns are irrelevant to this bug report)

I have checked with latest grype v0.86.4 and the rpm vulns are still not reported, so it seems like the Vuln DB is the only thing that changed between these 2 runs above.

What you expected to happen:

The vulnerabilities should still be reported by grype, until we patch them.

How to reproduce it (as minimally and precisely as possible):

I believe the following command repros it, though I can't go back in time to check if it would have shown the libxml2 and other vulns on 13th December, but this does not report any vulns, whereas I think it should:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock anchore/grype:v0.86.1 amazonlinux:2023.6.20241121.0

For comparison, Docker Scout does find the vulns which grype previously reported (but no longer does)
image

Anything else we need to know?:

Environment:

  • Output of grype version: see above, it occurred on v0.74.6 but still repros on:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock anchore/grype:v0.86.1 version
Application:         grype
Version:             0.86.1
BuildDate:           2024-12-13T19:32:52Z
GitCommit:           5c4fee7b1170976ab435de052fc3611bc955f1f1
GitDescription:      v0.86.1
Platform:            linux/amd64
GoVersion:           go1.23.4
Compiler:            gc
Syft Version:        v1.18.1
Supported DB Schema: 5
  • OS (e.g: cat /etc/os-release or similar): Windows 11 but running grype in Docker Desktop linux container using official grype image
@sparrowt sparrowt added the bug Something isn't working label Dec 16, 2024
@popey
Copy link
Contributor

popey commented Dec 16, 2024

Trying to reproduce this on my local machine, which has no had a grype db update since last week.

What version of DB do I have?

grype db status
Location:  /home/alan/.cache/grype/db/5
Built:     2024-12-12 01:32:26 +0000 UTC
Schema:    5
Checksum:  sha256:12498468d2fe3a45c23e35d681e9b9b3a80e1590782b257bf2ee8561417af043
Status:    valid

Check with the currently installed DB.

GRYPE_DB_AUTO_UPDATE=false grype amazonlinux:2023.6.20241121.0
 ✔ Loaded image amazonlinux:2023.6.20241121.0
 ✔ Parsed image sha256:4e24a4e616bb9928209da85eb4d989dc91cbf785c4687947d51fd75fde578dd9
 ✔ Cataloged contents 177870a058c8f8b2c6907144bce7a332dacb84a757318790492e4cc757f27d01
   ├── ✔ Packages                        [109 packages]
   ├── ✔ File digests                    [5,056 files]
   ├── ✔ File metadata                   [5,056 locations]
   └── ✔ Executables                     [272 executables]
 ✔ Scanned for vulnerabilities     [4 vulnerability matches]
   ├── by severity: 0 critical, 2 high, 2 medium, 0 low, 0 negligible
   └── by status:   4 fixed, 0 not-fixed, 0 ignored
NAME               INSTALLED              FIXED-IN                TYPE  VULNERABILITY  SEVERITY
libxml2            2.10.4-1.amzn2023.0.6  2.10.4-1.amzn2023.0.7   rpm   ALAS-2024-783  Medium
python3            3.9.16-1.amzn2023.0.9  3.9.20-1.amzn2023.0.1   rpm   ALAS-2024-770  High
python3-libs       3.9.16-1.amzn2023.0.9  3.9.20-1.amzn2023.0.1   rpm   ALAS-2024-770  High
python3-pip-wheel  21.3.1-2.amzn2023.0.9  21.3.1-2.amzn2023.0.10  rpm   ALAS-2024-781  Medium

Update the database.

grype db update
 ✔ Vulnerability DB                [updated]
Vulnerability database updated to latest version!
grype db status
Location:  /home/alan/.cache/grype/db/5
Built:     2024-12-16 01:31:49 +0000 UTC
Schema:    5
Checksum:  sha256:ac1801a30dd386afde62d76f1cb138649133bb2f8aa09ad19c4a92954ab67ae4
Status:    valid

Try the test again.

grype amazonlinux:2023.6.20241121.0
 ✔ Loaded image amazonlinux:2023.6.20241121.0
 ✔ Parsed image sha256:4e24a4e616bb9928209da85eb4d989dc91cbf785c4687947d51fd75fde578dd9
 ✔ Cataloged contents 177870a058c8f8b2c6907144bce7a332dacb84a757318790492e4cc757f27d01
   ├── ✔ Packages                        [109 packages]
   ├── ✔ File digests                    [5,056 files]
   ├── ✔ File metadata                   [5,056 locations]
   └── ✔ Executables                     [272 executables]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found

Confirmed they're gone.

@sparrowt
Copy link
Contributor Author

Interesting, seems like it is indeed a regression in the Vuln DB then 🤔

@popey
Copy link
Contributor

popey commented Dec 16, 2024

Indeed. Grype gets the data via vunnel, pulled from the upstream provider, where these vulnerabilities disappear. We've contacted the security team there to find out what's happening. Stand by :)

@willmurphyscode
Copy link
Contributor

No word from maintainers of the data yet, but https://alas.aws.amazon.com/alas2023.html shows that ALAS-2024-783 and ALAS-2024-781 are back.

Today's grype db now has those:

$ grype -q amazonlinux:2023.6.20241121.0 | rg -e NAME -e  ALAS-2024-783 -e ALAS-2024-770 -e ALAS-2024-781
NAME               INSTALLED              FIXED-IN                TYPE  VULNERABILITY  SEVERITY
libxml2            2.10.4-1.amzn2023.0.6  2.10.4-1.amzn2023.0.7   rpm   ALAS-2024-783  Medium
python3-pip-wheel  21.3.1-2.amzn2023.0.9  21.3.1-2.amzn2023.0.10  rpm   ALAS-2024-781  Medium

Grype now finds ALAS-2024-783 and ALAS-2024-781 again. Interestingly, ALAS-2024-770 is still listed at its own URL, just not in the index; I suppose grype could just guess URLs instead of trusting the index, but I'd like to wait to hear from the maintainers of this data before making such a change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: No status
Development

No branches or pull requests

3 participants