Investigation of an OpenSSL CVE found in aspnet:5.0 image

While writing a separate article on setting up automated image scans in a CI pipeline I stumbled on a reported critical vulnerability in the aspnet:5.0 base image. This made a very good use case and sample for my article, but I was curious as why a critical vulnerability was present in a such widely used base image so I decided to dig further.

Note: I didn’t try to analyze if the vulnerability is really exploitable in this image. My goal is simply to demonstrate with a real-life use case how you can investigate where a CVE is coming from and your options to fix it. I specified the dates where I ran the scans because you will probably get different results if you run this later as we are scanning the `latest` tag and not a specific digest, so the images will change.

A Trivy scan of the `mcr.microsoft.com/dotnet/aspnet:5.0` image on 2021/09/01 show the critical CVE-2021–3711.

This vulnerability was reported on 2021/08/24 and it affects openssl/libssl. We see as part of the output that our installed affected version of the package is “libssl1.1/now 1.1.1d-0+deb10u6”.

By scanning the Alpine version of the same image we see that the vulnerability is not present.

From Docker Hub we see that the aspnet:5.0 image is based on Debian 10 and was built on August 17 (i.e. before the vulnerability was reported).

If you wonder, the debian:buster-slim image was also built two weeks ago but doesn’t contain the vulnerability.

So let’s pull the aspnet:5.0 image and inspect it.

docker pull mcr.microsoft.com/dotnet/aspnet:5.0
docker image history --no-trunc mcr.microsoft.com/dotnet/aspnet:5.0

We see that some packages are installed in the image, including libssl1.1. This explains why the base Debian image is not vulnerable, this package is specifically installed in the aspnet image.

Let’s confirm the installed version

docker run --rm mcr.microsoft.com/dotnet/aspnet:5.0 apt list libssl1.1

We see that the installed package version is `libssl1.1/now 1.1.1d-0+deb10u6`, which is the version reported as vulnerable in the CVE.

In summary the vulnerability is still in the dotnet:5.0 image because it was not rebuilt in the last two weeks. The next time the image will be rebuilt it will pick the latest version of the package and the vulnerability will be fixed.

You can find detailed information on Microsoft process of updating images to address vulnerabilities in the Staying safe with .NET containers article (I highly recommend the read, it is a very detailed piece and the author also reference other posts were he goes through the analysis of some vulnerabilities). In this case because the base Debian image was not updated (it didn’t need to), it did not trigger a rebuild of the dotnet image.

As explained in the referenced article currently there is no process to proactively rebuild an image based on a package update.

There are cases where our team should be re-building images due to package updates. We do not have a system in place to discover when we should rebuild container images due to patched CVEs in newer packages. We’d like a system where our publishing system auto-rebuilds images when a fix is available for a CVE that has a certain severity or higher. Instead, we rely on base image updates as the .NET image rebuild signal and install the newest package updates as a side-effect of that operation. In the general case, this doesn’t matter since base images and .NET are updated frequently (at least once per month). In some cases, it likely does.

Conclusion

This shows the importance of having an establish process to scan your own images before deploying them and not to rely only on the upstream providers of base images for vulnerability fixes.

It also shows the importance of correctly selecting your base image. Best practices is to avoid the `latest` tag and pin to a specific version or even a specific digest. That way you are certain of what you will get.

The Alpine versions by being smaller typically have a limited attack surface. However in that case it was still vulnerable, it just so happen that a change in the base Alpine image triggered a new build of the aspnet:5.0-alpine image sooner (August 27th) than the Debian one.