0

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:

  1. 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):
  1. 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.

  1. 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
  1. 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"]
  1. 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.
Improve this question

1 Answer 1

Reset to default
0

Scans are based on the different packages installed on the operating system using the package manager (apk, apt, yum, etc...).

In this case you are using Scratch image, minimal image and does not contain a package manager, can be the reason why no vulnerability was found (Trivy detect function for Ubuntu that compare installed packages on the image with the known vulnerable packages).

It can be confirmed by creating a Docker image based on the latest Ubuntu,Debian or Alpine, replace the libc.so with the vulnerable file and scan the container.

Improve this answer
2
  • Huh interesting. So if I build my libraries from source, vulnerability scanners are useless against them? Are there any tools that can discover vulnerabilities in shared libraries? Commented Aug 17, 2021 at 17:02
  • @ArtemA. Ask yourself how would a scanner identify a library version? There is no common standard to encode a version into a library. Some may contain the version as string and export a function returning it. Other libraries have no version string included and detecting a version based on compiled code is difficult as there are quite a few compilers available with a large number of options changing the compiled output and last but not least each compiler is available in multiple versions for different architectures. Hence collecting hashes of libraries is next to useless. Commented Aug 17, 2021 at 17:53

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.