Vulnerabilities on Dockerhub
from _Nemo_@lemmy.ml to selfhosted@lemmy.world on 27 Jun 19:02
https://lemmy.ml/post/49317864
from _Nemo_@lemmy.ml to selfhosted@lemmy.world on 27 Jun 19:02
https://lemmy.ml/post/49317864
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?
#selfhosted
threaded - newest
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.
Many exploits and vulnerabilities are not relevant within the scope the software is typically deployed, so remain unfixed for a long time, even if they are rated high severity.
Thank you! While that does allay most security concerns, it does beg the question how useful such a vulnerability tracker is if it doesn’t actually show any relevant vulnerabilies and you constantly have to second-guess what it says. Warning signs that aren’t actually warnings because it’s “just a false alarm” quickly teach personell to not take warnings seriously - unti, onel day, it’s not a false alarm…
I don’t know if I agree. I get it, but it’s kind of important that people know that if they do something weird with a piece of software, that it might expose them to remote code execution or root shell exploits. It certainly does make you numb to the word “critical”, but I don’t have a solution to that.
Those vulnerabilities are inherited from the Debian base image. Debian is extremely diligent about fixing high-risk vulnerabilities. A high severity CVE does not automatically mean that you are at severe risk. It’s more an indication of how fucked you can be IF the vulnerability is exploited to its 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 either gain access to a device (e.g. camera) you own, or 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.
Thanks for your detailed reply!
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.
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.
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.’