Vulnerability found by AWS ECR scan

[Bhavana-HK]

Hi, recently I found that a new vulnerability was found when trying to scan the docker image using ECR. I am using httpd:2.4.43-alpine. The vulnerability was classified as 'undefined' severity and had the name: CVE-2020-24977

I was wondering if there is any fix available that can rid of any vulnerabilities

[keioni]

latest release is httpd:2.4.46-alpine. try it.

[Bhavana-HK]

Based on your suggestion, i tried with the httpd:2.4.46-alpine. Sadly, the scan discovered the same vulnerability

[keioni]

I confirmed too.

    "imageScanFindings": {
        "findings": [
            {
                "name": "CVE-2020-24977",
                "uri": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24977",
                "severity": "UNDEFINED",
                "attributes": [
                    {
                        "key": "package_version",
                        "value": "2.9.10-r4"
                    },
                    {
                        "key": "package_name",
                        "value": "libxml2"
                    }
                ]
            }
        ],
        "imageScanCompletedAt": "2020-09-30T21:23:11+09:00",
        "vulnerabilitySourceUpdatedAt": "2020-09-30T09:54:24+09:00",
        "findingSeverityCounts": {
            "UNDEFINED": 1
        }
    },

latest libxml2 is 2.9.10-r5, but 2.9.10-r4 is used. see: https://pkgs.alpinelinux.org/package/edge/main/x86_64/libxml2

I think we need to rebuild official image for resolving this problem.

[wglambert]

https://security-tracker.debian.org/tracker/CVE-2020-24977 Debian Buster is still vulnerable and the Debian Security Team considers it a minor issue

But the Alpine package does have a patch for it at the latest 2.9.10-r5 version https://git.alpinelinux.org/aports/commit/main/libxml2?h=3.12-stable&id=d8bb86a854d343e8ec071584a1f43c32f0325cbe

Also see https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves And https://github.com/docker-library/postgres/issues/286#issuecomment-302512767 docker-library/openjdk#161, docker-library/openjdk#112, docker-library/postgres#286, docker-library/drupal#84, docker-library/official-images#2740, docker-library/ruby#117, docker-library/ruby#94, docker-library/python#152, docker-library/php#242, docker-library/buildpack-deps#46, docker-library/openjdk#185.

A CVE doesn't imply having an actual vulnerability, and often is even a false positive (given how most distributions handle versioning/security updates in stable releases). If there are actionable items we can resolve, we're happy to do so (and do so actively). We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images).

[Bhavana-HK]

will there be a new release in future to resolve this issue

[yosifkit]

will there be a new release in future to resolve this issue

See https://github.com/nginxinc/docker-nginx/issues/453#issuecomment-699214166. So there are two ways for the image to be rebuilt, if the Dockerfile changes, or its base image gets updated.

Since Alpine rarely updates their images (really only on a version bump like 3.12.0 to 3.12.1), this would need to be a change in the httpd Dockerfile. The change would have to be before or in the Dockerfile instruction that installs libxml2-dev. Given that it isn't fixed in Debian Buster because it is a "minor issue" and "is specific and restricted to xmllint" I don't think it is worth the effort of changing the Dockerfile just to pull in the new version for Alpine. Any Dockerfile change would just be a hack to break build cache and need to be reverted at the next httpd version bump or Alpine base image change.