4

[Originally posted on ServerFault, was told it would fit better here]

Our vulnerability scanner (AWS Inspector V2) in the last couple of weeks started reporting ~10 High severity CVEs with the Linux kernel in our version of Debian (Bookworm, upgraded to latest available kernel version - 6.1.76) used by our app's Docker image, along with dozens more Medium severity CVEs. All of these are unfixed / unpatched. There are also a couple affecting nss and expat packages, but most are Linux itself.

We've actually never seen multiple High severity CVEs go unpatched for this long before - not sure if in the past similar ones were just not yet triaged or reported by our scanner.

These vulnerabilities, as far as I can tell, seem to:

  1. Mostly affect essentially every version of the Linux kernel up to ones not available in any Debian version (or other major distro versions, like RHEL)
  2. Go back multiple years - most are from 2023/2024, but there's one High severity one from 2021, and multiple Medium severity ones from 2020

Here is the list of High severity Linux vulnerabilities we see (Debian CVE links included, but these are Linux kernel):

You can see one of these CVEs affecting all of the newer RHEL versions, for example (although they classify it as a Moderate severity rather than high): https://access.redhat.com/security/cve/CVE-2023-3640

We're getting closer to our internal SLAs for resolving High severity CVEs, and with no OS patch fixes in sight, and seemingly many other Linux distros similarly affected, are not quite sure what to do. So... my questions are:

  • Is our vulnerability scanner just being overly sensitive with these? Should we "suppress" them until fixes are available? Reading through a couple, I'm guessing exploits for most, given how our app works, are unlikely, but it's hard to really know if they are impossible
  • Is there some other course we should take here? Should we be trying to port our app to a different Linux distro? AWS was happy to tell us that Amazon Linux is mostly unaffected, but given they use the same Linux kernels as everyone else, they may just be ignoring the same CVEs rather than truly unaffected.
Improve this question
2
  • 1
    Fixes may arrive at the next kernel release, but then you'll need to wait for it to avalanche down through backport fixes
    – Nicolas Formichella
    Commented Feb 27 at 19:27
  • 1
    @NicolasFormichella Fixes for CVEs from 2021 are unlikely to arrive.
    – AlexD
    Commented Feb 27 at 19:59

1 Answer 1

Reset to default
2

CVEs are indicators that there are some vulnerabilities and you need to pay attention and take some action. The severity score is an indicator of how much priority you should give your actions.

As an ordinary user, your action is usually just to follow the vendor and update the system and software to the latest version.

If there is no fix from the vendor then you need to do your own assessment. You need to determine if this specific vulnerability is present and exploitable in your system.

For example, if you are not using nosuid mounts then you can ignore CVE-2021-3847 (it is also reported as WONTFIX by the OverlayFS maintainer). If you are not using NVMe over TCP then you can ignore CVE-2023-6535. If you are not using ATA over TCP then you can ignore CVE-2023-6270.

Moreover, as these reportings are made against your Docker image you can ignore all Linux kernel vulnerabilities. There is no kernel in docker images and even if you install one, it won't be used. For some reason, Amazon Inspector reports all these kernel CVEs findings against any docker image built from the base Debian image, see a GitHub issue

You can suppress these findings by creating a suppression rule with a match on a title (or package name = 'linux') and the resource type of ECR Image in Amazon Inspector - see the documentation.

TLDR - indicators aren't always correct. Not all CVEs apply to your system and need to be fixed. Not all CVE reportings by vulnerability scanners are correct. Not all CVEs will be fixed by vendors.

You can also find further reading here

Improve this answer
4
  • Very helpful - and makes sense on the Linux kernel vulnerabilities not being applicable to a Docker container image in the first place. For the rest, determining whether a CVE actually applies to our application use case certainly makes sense (although may potentially be difficult in some cases given the number of app / OS package dependencies any real production app has). In the past (really for years) we'd simply never had so many false positives / unfixed CVEs even showing up, so this was simply out of the ordinary for us.
    – laserslasers
    Commented Feb 28 at 15:55
  • "Moreover, as these reportings are made against your Docker image you can ignore all Linux kernel vulnerabilities" -- unless they apply to the kernel the container is actually running on.
    – multithr3at3d
    Commented Mar 3 at 16:20
  • @multithr3at3d, then they should be reported against the instance that runs the kernel, not a container image in the registry. You should notice that I recommended suppressing these findings for the resource type "ECR Image" only and not for all resources.
    – AlexD
    Commented Mar 3 at 17:28
  • We use Fargate to run the instance(s) the containers are on, and AWS handles managing those completely - there's no visibility of what distro/version of Linux those are running, etc. They handle patch fixes themselves and notify users if necessary for downtime: d1.awsstatic.com/whitepapers/…
    – laserslasers
    Commented Mar 4 at 17:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .