Docker-nginx: nginx:alpine CVE-2020-24977

[NicolasFloquet]

Hello,
nginx:1.19.2-alpine is affected by CVE-2020-24977, from libxml2

We detected this issue today using trivy.

[NicolasFloquet]

After a few tests, upgrading to alpine 3.12.0 fixes the CVE

[thresheek]

nginx:1.19.2-alpine is using alpine 3.12, so I guess this is fixed?

[NicolasFloquet]

Well sorry about that, it turns out that 3.12 does not fix the CVE

[calebmayeux]

The vulnerability isn't in the alpine layer - libxml2 is installed during the apk add libxslt-dev during the build for the nginx image. Doing that apk add now installs libxml2 2.9.10-r5 which has the fix for CVE-2020-24977 instead of the vulnerable 2.9.10-r4 version of libxml2, so probably rebuilding the image would fix it?

[NicolasFloquet]

Makes sense, I guess that's why my home built image would pass the security scan. What would be the process to make suche rebuilt image official?

[MrKrabat]

CVE-2020-8169 and CVE-2020-8177 are now also reported for libcurl / curl.

[allanchua101]

Does anybody have a sample dockerfile to resolve this issue?

[NicolasFloquet]

@allanchua101 When I rebuild the image locally, vulnerabilities are no longer detected.

What I would like to understand is, how would a new image release could be triggered without a code/Dockerfile change, and what the version of such an image would be?

[allanchua101]

Tnx @NicolasFloquet! You are superman :D I figured out that I utilized 1.19.0 which have 3 vulnerabilities. Tnx!

[yosifkit]

What I would like to understand is, how would a new image release could be triggered without a code/Dockerfile change, and what the version of such an image would be?

Tags in the library file are only built through an update to that library file or as a result of its base image being updated (ie, an image FROM debian:jessie would be rebuilt when debian:jessie is built). Only what is in the library file will be rebuilt when a base has updates.

- https://github.com/docker-library/official-images/tree/c88a72bc11ef231ba20731491647f1e9b58e450b#library-definition-files

So, the tag, like nginx:1.19.2-alpine, would be overwritten if the alpine:3.12 image is updated.

---

Note that, unfortunately, the alpine:3.x images seem to only be updated when the vulnerability is in packages included in the base image and they then make a patch release (like https://github.com/docker-library/official-images/pull/7867); see the changes in official-image PRs with the library/alpine label. On the other hand, all active debian:[suite] images are regenerated at least on a monthly basis (see also that last few paragraphs of our faq section on CVEs).

[freddGO]

@allanchua101 When I rebuild the image locally, vulnerabilities are no longer detected.

What I would like to understand is, how would a new image release could be triggered without a code/Dockerfile change, and what the version of such an image would be?

Hi @NicolasFloquet, could you please share the commands that run on your dockerfile to get the image rebuild locally?

[jeremyhayes]

According to the releases feed on http://nginx.org/, nginx mainline 1.19.3 was released 2020-09-29.

Presumably, an updated image would include the latest libxml among other changes, resolving this CVE.

[allanchua101]

Thanks for notifying me @jeremyhayes!!

[JfrogPrasanna]

Thanks @NicolasFloquet for bringing me here. Do we know when the images be updated?

[NicolasFloquet]

@JfrogPrasanna @jeremyhayes i've created pull request for Nginx version bump

[thresheek]

Will be fixed really once https://github.com/docker-library/official-images/pull/8838 is merged.

Thanks @NicolasFloquet !

[calebmayeux]

I just pulled nginx:1.19-alpine and confirmed tag refers to same as nginx:1.19.3-alpine. Ran image through our security scanning tool which validated that the CVE is resolved and libxml is updated to r5. Confirmed all good on dockerhub now.

[NicolasFloquet]

Fixed on my side too:

nginx:1.19.3-alpine (alpine 3.12.0)
===================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)