alpine:latest has CVE-2020-28928

[jerome-laforge]

musl : 1.1.24-r9 -
Layer: sha256:ace0eda3e3be35a979cec764a3321b4c7d0b9e4bb3094d20d3ff6782961a8d54

CVE-2020-28928
In musl libc through 1.2.1, wcsnrtombs mishandles particular combinations of destination buffer size and source character limit, as demonstrated by an invalid write access (buffer overflow).
Solution: Upgrade musl to 1.1.24-r10

References:
http://www.openwall.com/lists/oss-security/2020/11/20/4
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28928
https://lists.debian.org/debian-lts-announce/2020/11/msg00050.html
https://musl.libc.org/releases.html

[hairyhenderson]

/cc @ncopa - would it be possible to bump this? Not sure if there's any mechanism to upgrade single packages since this image is basically just "extract the minirootfs into scratch"...

Alternatively we'd need to wait for an Alpine 3.12.2 to be released with the patched musl package.

[hairyhenderson]

Also, as a workaround (in case anyone else reads this and needs to mitigate quickly for compliance reasons):

Add this line to your alpine-based Dockerfiles:

RUN apk --no-cache upgrade musl

Note: Generally running apk upgrade in a Dockerfile is unnecessary and will cause maintenance pain, but for cases like this, it's a serviceable temporary workaround...

[ncopa]

Thank you for the reminder. We should bump a 3.12.2 release ASAP. Let me see what I can do. (We should probably also update the kernel while at it, which will require some work)

[J0WI]

Please also update alpine:edge

[hairyhenderson]

Looks like 3.12.2 is out - https://alpinelinux.org/posts/Alpine-3.12.2-released.html Thanks @ncopa 🙇‍♂️

[tob123]

yes. it is fixed for CVE-2020-28928 but now there is also CVE-2020-1971 . i use a similar workaround:

RUN apk --no-cache upgrade

[hairyhenderson]

but now there is also CVE-2020-1971

Ouch. And this one's got a higher CVSS than before 😞.

$ docker scan alpine:3.12.2   

Testing alpine:3.12.2...

✗ High severity vulnerability found in openssl/libcrypto1.1
  Description: NULL Pointer Dereference
  Info: https://snyk.io/vuln/SNYK-ALPINE312-OPENSSL-1050745
  Introduced through: openssl/libcrypto1.1@1.1.1g-r0, openssl/libssl1.1@1.1.1g-r0, apk-tools/apk-tools@2.10.5-r1, libtls-standalone/libtls-standalone@2.9.1-r1
  From: openssl/libcrypto1.1@1.1.1g-r0
  From: openssl/libssl1.1@1.1.1g-r0 > openssl/libcrypto1.1@1.1.1g-r0
  From: apk-tools/apk-tools@2.10.5-r1 > openssl/libcrypto1.1@1.1.1g-r0
  and 4 more...
  Fixed in: 1.1.1i-r0



Organization:      undefined
Package manager:   apk
Project name:      docker-image|alpine
Docker image:      alpine:3.12.2
Platform:          linux/amd64

Tested 14 dependencies for known vulnerabilities, found 1 vulnerability.

The openssl package was updated yesterday, just a day after the 3.12.2 release was cut.

@ncopa is it worth releasing 3.12.3 for the openssl fix?

As an aside, I wonder if it might make sense to add some logic to the Dockerfile to be able to update individual packages more quickly, to avoid the upstream Alpine needing to go through the whole release process? For non-containerized use-cases of Alpine it's reasonable to expect users to run an apk update && apk upgrade regularly, but running an apk --no-cache upgrade in a Dockerfile is generally discouraged (reproducible builds, and all that)...

[ncopa]

CVE-2020-28928 is fixed.

Lets follow up CVE-2020-1971 in #125

[sinchmarcuslind]

Noticed that latest 3.13 image (e.g. alpine:3.13.1) contain vulnerability - CVE-2020-28928. Noticed that 3.12 image (alpine:3.12.3) contain a fix. Is there a plan to release a fix for 3.13 track as well?

[rjpearce]

@ncopa do you want us to raise a new issue for Alpine 3.13.1 or are you happy to re-open this one given alpine:latest is now 3.13.1

[hairyhenderson]

@sinchmarcuslind @rjpearce there may be an issue with the scanner you're using - I see it with docker scan (i.e. Snyk) but not with trivy. The CVE was fixed in musl v1.2.2, and yet Alpine 3.13.1 packages that version.

The scanner output may indicate a bug with Snyk:

$ docker scan alpine:3.13.1
Docker Scan relies upon access to Snyk, a third party provider, do you consent to proceed using Snyk? (y/N)
y

Testing alpine:3.13.1...

✗ Medium severity vulnerability found in musl/musl
  Description: Out-of-bounds Write
  Info: https://snyk.io/vuln/SNYK-ALPINE313-MUSL-1067865
[...]
  From: musl/musl@1.2.2-r0
  From: busybox/busybox@1.32.1-r2 > musl/musl@1.2.2-r0
  From: alpine-baselayout/alpine-baselayout@3.2.0-r8 > musl/musl@1.2.2-r0
  and 10 more...
  Fixed in: 1.2.2_pre2-r0
[...]

That Fixed in: 1.2.2_pre2-r0 line seems to indicate it was fixed in a pre-release, however musl is on the 1.2.2 release... Maybe there's a bug with the semver parsing?

For comparison, here's the trivy output:

$ trivy image alpine:3.13.1
2021-02-10T08:28:29.745-0500	INFO	Detecting Alpine vulnerabilities...
2021-02-10T08:28:29.746-0500	INFO	Trivy skips scanning programming language libraries because no supported file was detected

alpine:3.13.1 (alpine 3.13.1)
=============================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

[rjpearce]

@hairyhenderson thank you, and yes you are correct.

It was a false positive from Clair when using arminc/clair-db:2021-02-05

clair-scanner -c "http://127.0.0.1:6060" --ip host.docker.internal alpine:3.13.1
2021/02/10 15:44:37 [INFO] ▶ Start clair-scanner
2021/02/10 15:44:38 [INFO] ▶ Server listening on port 9279
2021/02/10 15:44:38 [INFO] ▶ Analyzing 065271f6ba27473148a86d60e1cbb1e734bbb6adb5aae1861651558ae80a2f68
2021/02/10 15:44:38 [WARN] ▶ Image [alpine:3.13.1] contains 1 total vulnerabilities
2021/02/10 15:44:38 [ERRO] ▶ Image [alpine:3.13.1] contains 1 unapproved vulnerabilities
+------------+--------------------+--------------+-----------------+---------------------------------------------------------------+
| STATUS     | CVE SEVERITY       | PACKAGE NAME | PACKAGE VERSION | CVE DESCRIPTION                                               |
+------------+--------------------+--------------+-----------------+---------------------------------------------------------------+
| Unapproved | Low CVE-2020-28928 | musl         | 1.2.2-r0        |                                                               |
|            |                    |              |                 | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28928 |
+------------+--------------------+--------------+-----------------+--------------------------------------------------------------+

Updating to the latest version for the clair-db (arminc/clair-db:2021-02-09) and re-running shows no vulnerabilities

clair-scanner -c "http://127.0.0.1:6060" --ip host.docker.internal alpine:3.13.1          
2021/02/10 15:49:09 [INFO] ▶ Start clair-scanner
2021/02/10 15:49:09 [INFO] ▶ Server listening on port 9279
2021/02/10 15:49:09 [INFO] ▶ Analyzing 065271f6ba27473148a86d60e1cbb1e734bbb6adb5aae1861651558ae80a2f68
2021/02/10 15:49:09 [INFO] ▶ Image [alpine:3.13.1] contains NO unapproved vulnerabilities

Thanks again.

[GrantBirki]

Not sure if this is a bug with Snyk or not but it looks like this issue is still present in alpine3.13 - https://snyk.io/vuln/SNYK-ALPINE313-MUSL-1067865

Specifically when using the python:3.9.4-alpine3.13 Docker image, this vuln is detected

[ncopa]

Not sure if this is a bug with Snyk or not but it looks like this issue is still present in alpine3.13 - https://snyk.io/vuln/SNYK-ALPINE313-MUSL-1067865

Specifically when using the python:3.9.4-alpine3.13 Docker image, this vuln is detected

Maybe report this to the python docker image, which builds python:* images. The alpine:* base images are all fixed so there is nothing more we can do from our side.

[GrantBirki]

Oops! I am in the wrong place.. I will reach out there. Thanks!

[schematis]

AWS ECR scan is showing this CVE for 3.14 even though Trivy does not. Snyk is also showing this in their database:

https://snyk.io/vuln/SNYK-ALPINE314-MUSL-1307176

[hairyhenderson]

@schematis I think maybe you should report this to AWS and Snyk. Alpine 3.14 contains musl 1.22-r3:

$ docker run -it --rm alpine:3.14.0 apk --no-cache info musl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
musl-1.2.2-r3 description:
the musl c library (libc) implementation

musl-1.2.2-r3 webpage:
https://musl.libc.org/

musl-1.2.2-r3 installed size:
608 KiB

As I mentioned above this is likely a version parsing issue with Snyk and AWS.

It's worth noting too that these versions aren't semver-compliant - 1.2.2_pre2-r0 won't parse as a semver pre-release version, and even though 1.2.2-r3 parses as a pre-release, it's not - it's the third revision of the released version 1.2.2. Many tools in the wild need repository-specific version parsing and my impression is that Trivy's parsing is correct, while Snyk gets it wrong.