Vulnerabilities CVE-2023-23914, CVE-2023-23916 & CVE-2023-23915

[hitendramalviya]

Vulnerabilities CVE-2023-23914, CVE-2023-23916 & CVE-2023-23915

These vulnerabilities occurred due to libraries curl & libcurl, I truly understand security advisory posted along with this repo, but at the same time it is hard to explain to customers, this is happening very often since last few weeks.

To reproduce

Steps to reproduce the behavior:

Run trivy image nginxinc/nginx-unprivileged:1.23.3-alpine

Environment

• nginxinc/nginx-unprivileged:1.23.3-alpine
• macOS Ventura

Proposed solution

Can we scan image regularly & through some job & as soon as we encounter vulnerabilities for non direct dependency, we can trigger the build to rebuild the tag? This small automation can solve the pain for many who are relying on this image in many production environments.

[Jandrov]

is any fix expected here, like pushing a new version to Docker registry with versions of the library where this is fixed? We have also seen the same issue

[mello-r]

Trivy don't have any issues with the nginxinc/nginx-unprivileged:1.23.3-alpine-slim image

[alessfg]

I'm rebuilding the images right now 😄 -- some thoughts on the matter:

1. For the most secure image, I would always suggest using the Alpine slim image. It strips down the image to the bare essentials required to run NGINX so it's less likely to run into critical CVEs.
2. Many times some of the fixes for these CVEs take more than a few days (and weeks tbh) to make their way into the Alpine package registry, sometimes it takes more than a few days for the CVEs to be addressed in the first place! Re triggering a new build job if a CVE is detected:
   1. The images are already rebuilt on a weekly basis and for the most part that tends to be enough, but every once in a while we get a situation like the one raised in this issue.
   2. Detecting that there is a CVE would not be enough, we would also need to detect if a fix for the CVE has made its way to the Alpine (or Debian for that matter) package repositories.

That being said, can something like the solution you proposed be accomplished? I can't see why not. But, I don't have the cycles to work on it at the moment and any ETA I could mention here is bound to slip. Might I suggest opening a new issue with your suggestion as a feature request and hopefully either me or some community member will work on it at some stage? (PRs are always more than welcome!)

[alessfg]

Images did get rebuilt but there might be an issue with the caching system not detecting there's a new version of curl available. I might not get around to fixing it today but this is definitely a "bug". I'll try to figure out a good solution asap, in the meantime, I would suggest manually updating curl or using the Alpine slim image.

[alessfg]

Ok I went ahead and deleted the whole cache and I'm rebuilding everything from scratch as a temporary workaround. New images should be live within the next day.

I'll try to do some more digging to see if there's an "easy" way to force a cache refresh (there might be if Docker created easily identifiable cache keys, albeit it does not). If I can't find anything within the next couple weeks I'll just remove the cache for the time being -- Docker GH caching is in preview mode for now so I don't want to necessarily spend to much time trying to figure out a solution for something that might get addressed by the time it goes GA.

[alessfg]

Closing this issue, tracking the feature request on #136. curl would not make it to the list of what I would consider "critical" CVEs since it's not directly used by NGINX nor is it an NGINX dependency (see https://github.com/nginxinc/docker-nginx-unprivileged/blob/main/.github/SECURITY.md), but having a CVE scanner trigger image rebuilds under certain circumstances is a good idea all around.