DevOps to DevOops: Docker Hub proves so secure that 430 Docker images out of 2,500 have no vulnerabilities Back in 2015, security biz BanyanOps found that about 40 per cent of Docker images distributed through Docker Hub had high-priority vulnerabilities. That was when the Docker Hub repository stored about 95,000 Docker images. Docker images are sets of instructions for creating a functioning Docker container. Instantiating a …
Because unless someone remembers to update every Docker image on a regular schedule, it's just going to be out of date.
But if they do, it's going to screw lots of people over if there are changes / bugs beyond the security update, people who would have been working fine without the update.
Docker is really just a bunch of "other people's VM's" in essence, anyway. It's no more secure than anything else, because of that.
You'd think there'd be some kind of automated dependency/security tool by now that realises that a dependency is out of date, updates it and rebuilds everything that was reliant on it (or contains an unannounced copy of it, which is far more likely!). But no.
Docker - like all similar containerisation technologies - just pushes software updates behind another layer of obscurity and complexity, it doesn't actually fix them.
"Docker is really just a bunch of "other people's VM's" in essence,"
Sharing docker images is sharing config files, but Docker Hub'esq sites cram the bins in there too when they shouldn't. I can see if you have some specialty embedded IoT'ish thing, but otherwise share only the configs and let the user add the bins. Either way will still lead to abandonment but, at least it's easier/lighter to update a config.
You'd think there'd be some kind of automated dependency/security tool by now that realises that a dependency is out of date, updates it and rebuilds everything that was reliant on it (or contains an unannounced copy of it, which is far more likely!). But no.
You mean like dependabot or renovate? Combined with trivy for SAST scanning? Running on a schedule so you're aware of new vulnerabilities in existing code? No?
Docker doesn't hide things behind complexity/obscurity, its simply a tool for packaging an application as an immutable container. Once you've got this container, you can apply things like trivy to it very simply. It actually makes all this stuff a lot easier.
I hang out on a database server forum. VAST majority of the Docker users who show up with problems related to the database server are COMPLETELY clueless about systems administration, networking, software in general, and have built their world by stuffing other peoples black boxes (eg, docker containers) together, without ANY idea how any of it works. its all magic to them. devops cargocult style.
now, sure, there's some who use docker as a deployment tool, and these guys generally build their OWN containers from scratch, and know what they are doing, but they are way outnumbered by the clueless.
> The worst offender is the jackson-databind-2.4.0 package...
IIRC 2.4 is pretty old (for the modern software release cadence) and is known to be an insecure pile of trouble. In fairness to Tatu and company newer versions are more secure. It seems a bit disingenuous to point at such packages and say "oh no, insecure code!".
I use docker for testing code against known configurations. Even if there is a security issue with a configuration I still need to test the code against it.
(+ add a new configuration to the test set with any security fix applied).
I'd be very concerned if tagged base images were being changed.
Once tagged that should be it. Have an update, use a new tag.
Unless the vulnerability is exploitable from outside any proxy or firewall a problem in a Docker container can be hidden. Most exploits only work if you're on the same OS instance as the container. If your container is accessible in such a way from outside you have much greater issues to worry about.
Exactly, what is the criteria for "contains a vulnerability" when you are basically scanning an entire OS image which is likely to only execute a single binary?
Some of the major images have been stripped down to the minimal number of executables and libraries for the application to run, but even then they do not compile a custom version of every shared library that only includes the functions that are actually likely to get called..
You could for example create a Dockerfile that starts off by importing an entire debian base system, then add a standard full apache install and PHP interpreter. You then bundle in your 'application' which consists of a single PHP script with a single line that echos the requesting users IP address.
Let's say that the base debian image contains an outdated version of apt which has a buffer overflow vulnerability. If the apt-get dist-upgrade command is executed with the -y flag then a malicious mirror can send a specially crafted response that executes arbitrary code... I assume that image contains a severe vulnerabily (arbitrary code execution as root!)?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
