First of all, I am new to vulnerability scanning and don't have an experience working with any tooling outside of container specific. So, I don't know if it is a normal behavior for scanners. Please correct me if I am wrong, but the following seems like an issue to me:
- I downloaded the base image for envoy proxy from docker hub, and ran vulnerability scans using 3 different scanners (Twistlock, Trivy, and Snyk). The result came out with a number of vulnerabilities of various levels. However, I want to focus on these 4 issues with gnu libc (all are low level threads, but it doesn't matter for the context):
- I looked up all the shared library dependencies of envoy executable
root@ee5974211008:/# ldd $(which envoy)
linux-vdso.so.1 (0x00007ffdb6bf8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f282d755000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f282d54d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f282d349000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f282d12a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f282cd39000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2830e62000)
Notice: libc is one of them.
- I extracted envoy binary, and all the shared libraries from the official image into my host filesystem:
❯ tree
.
├── bin
│ └── envoy
├── lib
│ └── x86_64-linux-gnu
│ ├── libc.so.6
│ ├── libdl.so.2
│ ├── libm.so.6
│ ├── libpthread.so.0
│ └── librt.so.1
└── lib64
└── ld-linux-x86-64.so.2
4 directories, 8 files
- Next, I created my own Docker container "from scratch", packaging envoy binary and all the shared libraries:
FROM scratch
COPY bin /bin
COPY lib /lib
COPY lib64 /lib64
ENTRYPOINT ["/bin/envoy"]
- Finally, I ran vulnerability scans against the container from the previous step. Not a single scanner from the 3 mentioned above managed to detect vulnerable version of libc. One thing to note is I was using the paid version of Twistlock, and the other scanners were free.