Which version of redis provided by https://packages.redis.io/deb fixes CVE-2022-0543?
Comment From: AdeshAtole
Ah, the issue is with how debian and derivatives package redis, and not redis itself. https://www.ubercomp.com/posts/2022-01-20_redis_on_debian_rce
Comment From: yossigo
@AdeshAtole You are correct, CVE-2022-0543 is not a Redis vulnerability and does not affect any of the packages shipped on https://packages.redis.io.
Comment From: mirekphd
So presumably an Alpine-based official container with redis would be free from this vulnerability? And yet some scanners (here: the user-friendly anchore/grype) seem to just test the package version and as soon as they find Redis server v=5.0.14, they report the following TWO critical vulnerabilities (including the one for Debian reported by OP, but also another one for... Windows of all places, and setting GRYPE_PLATFORM="linux/amd64" does not help)... for BOTH the Alpine-based and Debian-based images:
1) DEBIAN This one can be true, as Debian maintainers can be slow in patching (at least High CVEs, not sure about Critical ones):
$ ./scan-with-grype-dockerized.sh redis:6.2.13-bookworm
[0000] INFO grype version: 0.64.2
[0002] INFO identified distro: Debian GNU/Linux 12 (bookworm) from-lib=syft
[0002] INFO cataloging an image from-lib=syft
[0003] INFO found 176 vulnerabilities for 108 packages
1 error occurred:
* discovered vulnerabilities at or above the severity threshold
redis 6.2.13 CVE-2022-0543 Critical
redis 6.2.13 CVE-2022-3734 Critical
github.com/opencontainers/runc v1.1.0 GHSA-vpvm-3wq2-2wvm High
linux-libc-dev 6.1.38-1 CVE-2013-7445 High
linux-libc-dev 6.1.38-1 CVE-2019-19449 High
linux-libc-dev 6.1.38-1 CVE-2019-19814 High
linux-libc-dev 6.1.38-1 CVE-2021-3847 High
linux-libc-dev 6.1.38-1 CVE-2021-3864 High
linux-libc-dev 6.1.38-1 CVE-2023-2176 High
linux-libc-dev 6.1.38-1 CVE-2023-35827 High
linux-libc-dev 6.1.38-1 CVE-2023-3611 High
linux-libc-dev 6.1.38-1 CVE-2023-3640 High
linux-libc-dev 6.1.38-1 CVE-2023-3776 High
perl-base 5.36.0-7 CVE-2023-31484 High
github.com/opencontainers/runc v1.1.0 GHSA-f3fp-gc8g-vw66 Medium
github.com/opencontainers/runc v1.1.0 GHSA-g2j6-57v7-gm8c Medium
linux-libc-dev 6.1.38-1 CVE-2019-15213 Medium
linux-libc-dev 6.1.38-1 CVE-2019-16089 Medium
linux-libc-dev 6.1.38-1 CVE-2019-20794 Medium
linux-libc-dev 6.1.38-1 CVE-2020-14304 Medium
linux-libc-dev 6.1.38-1 CVE-2020-36694 Medium
linux-libc-dev 6.1.38-1 CVE-2022-4543 Medium
linux-libc-dev 6.1.38-1 CVE-2023-0160 Medium
linux-libc-dev 6.1.38-1 CVE-2023-0597 Medium
linux-libc-dev 6.1.38-1 CVE-2023-1206 Medium
linux-libc-dev 6.1.38-1 CVE-2023-23005 Medium
linux-libc-dev 6.1.38-1 CVE-2023-2898 Medium
linux-libc-dev 6.1.38-1 CVE-2023-31082 Medium
linux-libc-dev 6.1.38-1 CVE-2023-31083 Medium
linux-libc-dev 6.1.38-1 CVE-2023-37453 Medium
linux-libc-dev 6.1.38-1 CVE-2023-37454 Medium
linux-libc-dev 6.1.38-1 CVE-2023-3772 Medium
linux-libc-dev 6.1.38-1 CVE-2023-3773 Medium
linux-libc-dev 6.1.38-1 CVE-2023-3863 Medium
2) ALPINE ... but why also THIS - surely this must be a false positive from the CVE description ("a packaging issue [..] a (Debian-specific) Lua sandbox escape"):
$ ./scan-with-grype-dockerized.sh redis:6.2.13-alpine
Error response from daemon: No such container: anchore-grype
[0000] INFO grype version: 0.64.2
[0003] INFO identified distro: Alpine Linux v3.18 from-lib=syft
[0003] INFO cataloging an image from-lib=syft
[0004] INFO found 7 vulnerabilities for 19 packages
1 error occurred:
* discovered vulnerabilities at or above the severity threshold
redis 6.2.13 CVE-2022-0543 Critical
redis 6.2.13 CVE-2022-3734 Critical
So presumably such CVE scanners as Anchore Grype are pretty much "crying wolf" all day long, as they use databases of CVE's indexed by package names and versions alone, so in scenarios when versions are not enough like this (and system is the trigger) will be always giving you the worst-case scenario? Can't they be testing the actually compiled / patched binary you have installed in your container, comparing it with a database of binary signatures like Windows virus scanners do?