search

anchore / grype

A vulnerability scanner for container images and filesystems
Apache License 2.0
8.86k stars 574 forks source link

Mariner Linux "util-linux" package FP #2181

Open Atharex opened 1 month ago

Atharex commented 1 month ago

What happened:

$ grype mcr.microsoft.com/openjdk/jdk:11-mariner
NAME        INSTALLED  FIXED-IN        TYPE  VULNERABILITY   SEVERITY
util-linux  2.37.4     0:2.37.4-1.cm2  rpm   CVE-2022-0563   Medium
util-linux  2.37.4     0:2.37.4-9.cm2  rpm   CVE-2024-28085  Low

Looking at the container composition:

$ sudo docker run -ti mcr.microsoft.com/openjdk/jdk:11-mariner rpm -qa | grep -i util
elfutils-libelf-0.186-2.cm2.x86_64
coreutils-8.32-7.cm2.x86_64
findutils-4.8.0-5.cm2.x86_64
util-linux-libs-2.37.4-9.cm2.x86_64
shadow-utils-4.9-13.cm2.x86_64

Util-linux package is not present in the image, only util-linux-libs. We still get flagged as vulnerable from this finding

What you expected to happen: The package is not present and should not be a finding. The lib package associated with it is the proper version, so should also not trigger a finding

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

Anything else we need to know?:

Environment:

spiffcs commented 1 month ago

Hey @Atharex I generated the syft SBOM for the image you mentioned above: mcr.microsoft.com/openjdk/jdk:11-mariner

Here is what I found:

      "name": "util-linux",
      "version": "2.37.4",
      "type": "rpm",
      "foundBy": "elf-binary-package-cataloger",
      "locations": [
        {
          "path": "/usr/lib/libblkid.so.1.1.0",
          "layerID": "sha256:57c9ba677d71db86854586da682243f01c4d6b9bb684ef632f8d1ab1749c1e4e",
          "accessPath": "/usr/lib/libblkid.so.1.1.0",
          "annotations": {
            "evidence": "primary"
          }
        },
        {
          "path": "/usr/lib/libfdisk.so.1.1.0",
          "layerID": "sha256:57c9ba677d71db86854586da682243f01c4d6b9bb684ef632f8d1ab1749c1e4e",
          "accessPath": "/usr/lib/libfdisk.so.1.1.0",
          "annotations": {
            "evidence": "primary"
          }
        },
        {
          "path": "/usr/lib/libmount.so.1.1.0",
          "layerID": "sha256:57c9ba677d71db86854586da682243f01c4d6b9bb684ef632f8d1ab1749c1e4e",
          "accessPath": "/usr/lib/libmount.so.1.1.0",
          "annotations": {
            "evidence": "primary"
          }
        },
        {
          "path": "/usr/lib/libsmartcols.so.1.1.0",
          "layerID": "sha256:57c9ba677d71db86854586da682243f01c4d6b9bb684ef632f8d1ab1749c1e4e",
          "accessPath": "/usr/lib/libsmartcols.so.1.1.0",
          "annotations": {
            "evidence": "primary"
          }
        },
        {
          "path": "/usr/lib/libuuid.so.1.3.0",
          "layerID": "sha256:57c9ba677d71db86854586da682243f01c4d6b9bb684ef632f8d1ab1749c1e4e",
          "accessPath": "/usr/lib/libuuid.so.1.3.0",
          "annotations": {
            "evidence": "primary"
          }
        }
      ],

util-linux was not found by the rpm cataloger. It was found by the elf-binary-package-cataloger. The paths in the above json were used as the primary bits of evidence.

readelf -x .note.package /usr/lib/libblkid.so.1.1.0

Hex dump of section '.note.package':
  0x00000224 04000000 84000000 7e1afeca 46444f00 ........~...FDO.
  0x00000234 7b0a2022 6d6f6475 6c655665 7273696f {. "moduleVersio
  0x00000244 6e223a20 22322e33 372e342e 30222c0a n": "2.37.4.0",.
  0x00000254 20226e61 6d65223a 20227574 696c2d6c  "name": "util-l
  0x00000264 696e7578 222c0a20 226f7322 3a20226d inux",. "os": "m
  0x00000274 6172696e 6572222c 0a20226f 73566572 ariner",. "osVer
  0x00000284 73696f6e 223a2022 322e3022 2c0a2022 sion": "2.0",. "
  0x00000294 74797065 223a2022 72706d22 2c0a2022 type": "rpm",. "
  0x000002a4 76657273 696f6e22 3a202232 2e33372e version": "2.37.
  0x000002b4 34220a7d                            4".}

So while these binaries may not have been installed via rpm, they contain a .note.package section signifying their association with util-linux@2.37.4

Do you think it may be the case that the metadata in the binaries is incorrect and they should be associated with util-linux-libs?

The hard part about this is that CVE for this package have been filed against the meta package rather than the individual utilities which is a scoping problem when trying to pinpoint vulnerabilities.

Given the details of CVE-2022-0563 and CVE-2024-28085 our recommendation would be to use grype's ignore functionality here.

Let me know if you have any questions or if you think anything I wrote above is in error regarding our identification and usage of elf binary metadata to include packages in the SBOM we generate for vulnerability analysis.

eric-desrochers commented 1 month ago

We (Azure Linux dev team) looked at it, and the package version in the note is only as granular as the base package (source). So, any binary in the util-linux-libs subpackage will have a note that indicates that it comes from util-linux.

This seems like this behaviour is by-design, I don't think we can change it.

The things we don't understand: why is the CVE no longer reported after linux-utils is installed ? Any ideas ?

eric-desrochers commented 1 month ago

@spiffcs do you have similar situation with other Linux distributions using .note metapackage ?

spiffcs commented 1 month ago

@eric-desrochers this is the first time I've run into a case where the .note information conflicts in this example.

As to your question:

The things we don't understand: why is the CVE no longer reported after linux-utils is installed ? Any ideas ?

I can think of a reason, but let me try and do some investigation to find out.

If we install linux-utils and find that the binaries found overlap or share files with that package THEN we would use different rpm matches in the upstream data? Checking this now.

My guess here is that when linux-utils is installed we "upgrade" to the rpm --> vuln feed matching and there is some fixed information that informs grype to drop the result.

If linux-utils is NOT installed then we just go off the metadata .note section which might not have the enriched information that the direct rpm install has.