Vulnerabilities on Dockerhub

Submitted ⁨⁨2⁩ ⁨days⁩ ago⁩ by ⁨_Nemo_@lemmy.ml⁩ to ⁨selfhosted@lemmy.world⁩

Apologies if this is a rookie question, but I keep wondering what the vulnerabilities section on DockerHub is trying to tell me. Take nextcloud images for instance: The most current images seem to list 3 critical and 22 severe vulnerabilities. Does that mean those vulns are part of the image? If so, why would anyone want to run this?

original

Comments

Sort:hotnew top

irmadlad@lemmy.world ⁨2⁩ ⁨days⁩ ago

Apologies if this is a rookie question

That’s not a rookie question at all, and actually shows you’re paying attention to what you are deploying on your server…which is what you should be doing. In addition to what others have said so far, images like Nextcloud are often updated quickly, but scans lag in reality. A critical label reflects known vulnerabilities in a version, but not necessarily ‘this instance is definitely compromised.’

original
slazer2au@lemmy.world ⁨2⁩ ⁨days⁩ ago
Generally the images will be built with dependencies that have known issues but not all cves are actual problems.

Just because Next cloud uses a package, it may not use the function that has the issue.

original
rtxn@lemmy.world ⁨2⁩ ⁨days⁩ ago
Debian is extremely diligent about fixing high-risk vulnerabilities. A high severity CVE does not mean that you are at severe risk. It’s more an indication of how fucked you can be IF the vulnerability is exploited to the greatest potential.

One of the CVEs affects libraw, which is a library for handling RAW photograph files. If a RAW file contains a particular header, and that header is maliciously constructed in a particular way, extracting an embedded thumbnail can allow the attacker to execute arbitrary code on the server. To make that happen, the attacker must already have access to the server to upload and process the file, which means that security has already failed.

The Swiss cheese model applies to cybersecurity too.

original
- _Nemo_@lemmy.ml ⁨2⁩ ⁨days⁩ ago
  Thanks for your detailed reply!
  
  To make that happen, the attacker must […] already have access to the server to upload and process the file, which means that security has already failed.
  
  Do I correctly assume that by axis you mean shell or even root level access? If not, any of my regular users (turned rogue…) could upload a poisoned raw file which nextcloud would process to, for instance, generate a thumbnail.
  
  original
  - rtxn@lemmy.world ⁨2⁩ ⁨days⁩ ago
    I mean whatever level of access is required to upload an image. That can be access to the web app (with login), access through WebDAV, or access to the underlying OS or filesystem. If you can put a file on Nextcloud, it is sufficient access.
    
    I forgot to mention that the vulnerability can only be exploited if libraw is also compiled with a particular flag that enables the vulnerable feature. That flag is disabled on base Debian. Docker’s service doesn’t test whether the vulnerability is actually present in the image, only that the package version is listed as affected.
    
    original