Security vulnerability with redis:7.0.4-alpine3.16

[subhankarc]

Hi,

We are scanning the image with tag redis:7.0.4-alpine3.16 and it has the following vulnerabilities reported.

https://nvd.nist.gov/vuln/detail/CVE-2020-15888 https://nvd.nist.gov/vuln/detail/CVE-2022-28805 https://nvd.nist.gov/vuln/detail/CVE-2022-33099

Could you please let us know if there is a plan to fix this?

Regards, Subhankar

[wglambert]

Those CVE's are related to lua https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33099

An issue in the component luaG_runerror of Lua v5.4.4 and below leads to a heap-buffer overflow when a recursive error occurs.

https://nvd.nist.gov/vuln/detail/CVE-2022-28805

singlevar in lparser.c in Lua from (including) 5.4.0 up to (excluding) 5.4.4 lacks a certain luaK_exp2anyregup call, leading to a heap-based buffer over-read that might affect a system that compiles untrusted Lua code.

https://nvd.nist.gov/vuln/detail/CVE-2020-15888

Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.

But that package isn't in the image

$ docker run -it --rm redis:7.0.4-alpine3.16 ash

/data # apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x86_64/APKINDEX.tar.gz
v3.16.2-176-g217b4b6f4b [https://dl-cdn.alpinelinux.org/alpine/v3.16/main]
v3.16.2-182-g8e0ba1a637 [https://dl-cdn.alpinelinux.org/alpine/v3.16/community]
OK: 17030 distinct packages available

/data # apk info -vv | grep -i lua

/data # apk info -vv
alpine-baselayout-data-3.2.0-r22 - Alpine base dir structure and init scripts
musl-1.2.3-r0 - the musl c library (libc) implementation
busybox-1.35.0-r17 - Size optimized toolbox of many common UNIX utilities
alpine-baselayout-3.2.0-r22 - Alpine base dir structure and init scripts
alpine-keys-2.4-r1 - Public keys for Alpine Linux packages
ca-certificates-bundle-20220614-r0 - Pre generated bundle of Mozilla certificates
libcrypto1.1-1.1.1q-r0 - Crypto library from openssl
libssl1.1-1.1.1q-r0 - SSL shared libraries
ssl_client-1.35.0-r17 - EXternal ssl_client for busybox wget
zlib-1.2.12-r3 - A compression/decompression Library
apk-tools-2.12.9-r3 - Alpine Package Keeper - package manager for alpine
scanelf-1.3.4-r0 - Scan ELF binaries for stuff
musl-utils-1.2.3-r0 - the musl c library (libc) implementation
libc-utils-0.7.2-r3 - Meta package to pull in correct libc
su-exec-0.2-r1 - switch user and group id, setgroups and exec
tzdata-2022a-r0 - Timezone data
.redis-rundeps-20220810.015157 - virtual meta package

/data # find / | grep -i lua
/usr/share/zoneinfo/Africa/Luanda
/usr/share/zoneinfo/right/Africa/Luanda

See https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves And https://github.com/docker-library/openjdk/issues/449#issuecomment-763027011, 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).

[subhankarc]

Hi @wglambert ,

The lua version packaged with redis itself seem to be the problem, as it is 5.1.5 as per this.

[wglambert]

Ah my mistake. Yeah it seems that Redis desires Lua 5.1 compatibility so even if they decide to use Lua 5.4 it would still require 5.1 as well, which in terms of potential vulnerabilities against 5.1 wouldn't really change much

https://github.com/redis/redis/pull/8180#issuecomment-911265500

Lua 5.4 is not backwards compatible with 5.1, so if we wanna support it, we'll need to support both, and we eventually concluded that the shortcomings of 5.1 are not worth that complication. instead we considered to switch to Lua JIT, which is 5.1 compatible and more maintained, but we don't have a plan for doing that anytime soon either.

[subhankarc]

Thanks @wglambert for the reply.

I see in https://github.com/redis/redis/issues/7715, that this talks about some vulnerabilities including CVE-2020-15888 from our list, but it says that As for the other reported Lua vulnerabilities, they seem to have been introduced (and solved) by newer versions of Lua only (Redis uses Lua 5.1).

In https://github.com/redis/redis/issues/10628, also it is mentioned that CVE-2022-28805 was only introduced in later versions, it does not seem to affect Lua 5.1.x.

Can we say that these are not applicable for redis in that case ?

For https://nvd.nist.gov/vuln/detail/CVE-2022-33099, there is nothing mentioned though.

From versions affected perspective,

CVE	from version	upto version	description
https://nvd.nist.gov/vuln/detail/CVE-2022-33099	5.4.2	5.4.4	An issue in the component luaG_runerror of Lua v5.4.4 and below leads to a heap-buffer overflow when a recursive error occurs.
https://nvd.nist.gov/vuln/detail/CVE-2022-28805	5.4.0	5.4.4	singlevar in lparser.c in Lua from (including) 5.4.0 up to (excluding) 5.4.4 lacks a certain luaK_exp2anyregup call, leading to a heap-based buffer over-read that might affect a system that compiles untrusted Lua code.
https://nvd.nist.gov/vuln/detail/CVE-2020-15888		5.4.0	Lua through 5.4.0 mishandles the interaction between stack resizes and garbage collection, leading to a heap-based buffer overflow, heap-based buffer over-read, or use-after-free.

[wglambert]

I would say the best security practice for redis is to not expose it publicly, only have it be accessible from intranet containers https://github.com/docker-library/docs/tree/master/redis#security. Doing so would also heavily curb attempts to exploit any of those potential vulnerabilities since they're related to executing lua scripts on the redis instance

[tooptoop4]

CVE-2022-29162 and CVE-2021-43784. --> /usr/local/bin/gosu (in docker image) has github.com/opencontainers/runc v1.0.1

[yosifkit]

CVE-2022-29162 and CVE-2021-43784. --> /usr/local/bin/gosu (in docker image) has github.com/opencontainers/runc v1.0.1

https://github.com/tianon/gosu/issues/104

[jmthomas]

Please bump your gosu version to 1.16 to address various CVEs

[tianon]

There are no CVEs actually fixed by upgrading gosu to 1.16, but it does allow govulncheck to scan the binary correctly so that CVEs can be reported more correctly in the future.