13 ms·

The most popular docker images each contain at least 30 vulnerabilities

562 points by vinnyglennon 8y ago

aboutruby 8y ago
A lot of people say you don't need Heroku when you have Docker images, but Heroku actually takes care of the vast majority of vulnerabilities for you.
- mikepurvis 8y ago
  This has always been my hesitation with Docker— unless you have a proper pipeline in place to be constantly rebuilding your overlay from updated versions of the base image, you're basically just carrying a snapshot of unknown binaries into the future with you, indefinitely. Obviously, any reasonable shop will have such a pipeline in place, but DockerHub and the whole ecosystem of docker getting started tutorials seem to really encourage a "set it and forget it" mentality toward a container once it's built and working.
  - orf 8y ago
    Do they? The whole point is you'd rebuild your app every redeploy, which includes from the base image. Docker has a lot of problems but build repeatability is not one of them, in my experience. It makes it really really frictionless, in some cases way too frictionless
  - duxup 8y ago
    As someone just getting a feel for Docker I keep thinking: "Wait what is all th---" And then the tutorials or documentation just rolls on.... and doesn't really get back to what I should be doing to maintain / secure anything.
- driverdan 8y ago
  You're assuming a lot. Take a look through a popular buildpack source and you'll see how they work. They do version pinning which means someone has to be aware of a vuln, its patch, and update the buildpack. I'm not saying they don't do that, just that it still requires a person to make the necessary changes. It's not inherently more secure.
BossingAround 8y ago
Did you know Red Hat has a free container registry [1] which is being constantly watched for CVEs and CVEs are fixed like within a week of announcement? Just try "docker run -it registry.access.redhat.com/rhel7-minimal /bin/bash" and you're good to go... [1] https://access.redhat.com/containers https://access.redhat.com/containers
- bithavoc 8y ago
  I recently noticed Dockerhub is also reporting vulnerabilities in the Tags tab[0] [0]https://hub.docker.com/_/golang?tab=tags https://hub.docker.com/_/golang?tab=tags
- ihattendorf 8y ago
  What's the licensing status for these images?
  - e1ven 8y ago
    The slide at https://www.redhat.com/files/summit/session-assets/2017/LT122012-dherrman-rhcc-lightning-talk-final.pdf https://www.redhat.com/files/summit/session-assets/2017/LT12... says that the License will be displayed on the Get Image page. This page says (for the NodeJS image) "Before downloading or using this Certified Container, you must agree to both the Red Hat subscription agreement located at redhat.com/licenses and the Red Hat Connect Certified Container Partner’s terms which are referenced by URL in the Partner’s product description and/or included in the Certified Container. If you do not agree with these terms, do not download or use the Certified Container. If you have an existing Red Hat Enterprise Agreement (or other negotiated agreement with Red Hat) with terms that govern subscription services associated with Certified Containers, then your existing agreement will control."
    - indigodaddy 8y ago
      So I can't tell from this if you need a RHEL subscription or not to use the docker images? I guess the most salient question will be can the images yum install things or not? I'm guessing they will have that functionality without requiring a subscription but that's just speculation based on my reading of that blurb.
Thaxll 8y ago
I would be very cautious with those vulnerabilities reports, 95% of the time it's libraries from the Docker image that you will never use or don't have access to.
- vjeux 8y ago
  I am admin on a few high profile js projects. Github has enabled sending alerts for vulnerabilities, I haven’t yet seen one that was actually a real one. Lots of times there’s a deep dependency that we’re not even using that can accept a regex that may cause a DoS.
  - eunoia 8y ago
    The deep dependency regex vulnerability warnings are particularly annoying. Can anyone speak to what the actual attack vector is?
    - cyphar 8y ago
      There is a type of regex called a "pathological" regex which can be used to make certain regex implementations have exponential time complexity. If you exposed this in your application, someone could DoS you. Some libraries might have accidentally pathological regular expressions, and so some user input might be able to trigger the pathological case (Atom had a bug a few years ago where certain source files would cause the editor to lock up, and it was caused by a bad regex they used for parsing to figure out the auto indentation[1]). Russ Cox wrote an article about this in 2007[2], and the situation is still the same. Go doesn't have this problem since Russ Cox is one of the lead authors of Go, and wrote Go's regex library. [1]: http://davidvgalbraith.com/how-i-fixed-atom/ http://davidvgalbraith.com/how-i-fixed-atom/ [2]: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html
      - eunoia 8y ago
        Thanks for an excellent answer!
      - 8y ago
alexnewman 8y ago
How does this compare to vagrant?
- e1ven 8y ago
  One big difference is that (afaik) people aren't putting vagrant images into production, it's for local development.
  - alexnewman 8y ago
    sure they do. you are totally wrong. they just shouldn’t
- cronix 8y ago
  Do people use vagrant in production?
  - mikepurvis 8y ago
    One hopes not, though they kinda do support it: https://www.vagrantup.com/docs/push/ https://www.vagrantup.com/docs/push/
- adrianmsmith 8y ago
  In addition to the point others have raised that Vagrant is not designed to be used in production, Vagrant is a lot more stateful than Docker (long-lived VMs) so you can easily run “apt-get update && apt-get upgrade” or equivalent. Potentially from the Vagrantfile to make sure rebuilds get the updates as well.
  - alexnewman 8y ago
    you are totally wrong i know plenty of people who do. i also know people who think docker shouldn’t be used in production and that we should use containerd just like vagrant/packer
- fulafel 8y ago
SahAssar 8y ago
I really don't like these kinds of alarmist reports if they are not actually saying what the problems are and how they can lead to actual, real, serious attacks. A lot of claimed "high CVSS" vulnerabilities aren't when you put them in context, and sometimes vice versa. Yes, we should strive to be a lot better and maintaining dependencies is one thing that generally everyone in modern development does bad, but this sort of alarmist posts that have no concrete examples generally just lead to people ignoring the whole field/industry. If those images are exploitable in the ways they are intended to be used highlight that. If it's as bad as this post makes it sound then that should be easy.
- subcosmos 8y ago
  RSA time - this is where the sales pitches begin
- objectified 8y ago
  CVSS is a common and open approach. CVSS scores that are particularly high, are often directly exploitable. If they aren't, then probably their calculation was done wrong. You can try it for yourself here: https://www.first.org/cvss/calculator/3.0 https://www.first.org/cvss/calculator/3.0 Having said that, what can lead to a serious attack for your organization is often subject to a combination of factors. Say, there is an SSRF vulnerability in your own application, because the HTTP library you use doesn't parse the URL correctly, so now an attacker can let your application perform arbitrary HTTP requests. But fortunately, the connectivity of your application server is quite limited, so that an attacker can't reach internal systems, can't go to the internet, uses strong authentication to web services it does use, all the good stuff. So now the chance of a successful, serious attack is largely diminished. Also, it can be quite complicated to know what the exact, real dependencies of your application are. What is the transitive/recursive list of dependencies your application uses? Which of your application's dependencies actually use libraries on your system? And what are _their_ dependencies? I think that cost wise, it is cheaper to make sure your application dependencies, containers, host system libraries, container orchestration tools, etc. are always up to date. And yeah, I agree that the post doesn't do a good job at all to provide a sane rationale on _why_ you should update. Anyone who has ever administered an operating system knows that security vulnerabilities are found in them every day. But the awareness that a Docker container is subject to the same pace is definitely not present everywhere, and it probably should be.
coleifer 8y ago
Can't tell if this is fud or not. For example with node, typically you'd only be exposing port 80, right? So as long as your http server isn't vulnerable you're ok. Or same with Redis, which I hope isn't anywhere near the public internet?
- pas 8y ago
  Also popular, high-velocity projects have a lot of CVEs. That doesn't mean much. How fast these images get updated? How widespread these vulnerable images are?
- acdha 8y ago
  > So as long as your http server isn't vulnerable you're ok … and everything loaded by every dependency under any situation which doesn't require admin access. Your server can be fine but if e.g. you process images you have to follow libjpeg, libpng, zlib, littlecms, etc. Yes, it's a lot better than a full multiuser Unix system where you have to worry about background processes which aren't useful for a dedicated microservice but there's a long history of vulnerabilities in components being combined into successful exploits and it's usually far more expensive to try to analyze those chains than to upgrade. This brings me to: > Or same with Redis, which I hope isn't anywhere near the public internet? That's hopefully true in general but also consider chained attacks: say you're running a web app and I find a way to run code in the app process. That might be limited but if I can poke at Redis enough to run code there I can test whether you were as diligent about sandboxing it. That'll hurt if, say, there was a container exploit which someone delayed patching because they “knew” our app only runs as an unprivileged user.
DCKing 8y ago
Although vulnerability scanners can be a useful tool, I find it very troublesome that you can utter the sentence "this package contains XX vulnerabilities, and that package contains YY vulnerabilities" and then stop talking. You've provided barely any useful information! The quantity of vulnerabilities in an image is not really all that useful information. A large amount of vulnerabilities in a Docker image does not necessarily imply that there's anything insecure going on. Many people don't realize that a vulnerability is usually defined as "has a CVE security advisory", and that CVEs get assigned based on a worst-case evaluation of the bug. As a result, having a CVE in your container barely tells you anything about your actual vulnerability position. In fact, most of the time you will find that having a CVE in some random utility doesn't matter. Most CVEs in system packages don't apply to most of your containers' threat models. Why not? Because an attacker is very unlikely to be able to use vulnerabilities in these system libraries or utilities. Those utilities are usually not in active use in the first place. Even if they are used, you are not usually in a position to exploit these vulnerabilities as an attacker. Just as an example, a hypothetical outdated version of grep in one of these containers can hypothetically contain many CVEs. But if your Docker service doesn't use grep, then you would need to manually run grep to be vulnerable. And an attacker that is able to run grep in your Docker container has already owned you - it doesn't make a difference that your grep is vulnerable! This hypothetical vulnerable version of grep therefore makes no difference in the security of your container, despite containing many CVEs. It's the quality of these vulnerabilities that matters. Can an attacker actually exploit the vulnerabilities to do bad things? The answer for almost all of these CVEs is "no". But that's not really the product that Snyk sells - Snyk sells a product to show you as many vulnerabilities as possible. Any vulnerability scanner company thinks it can provide most business value (and make the most money) by reporting as many vulnerabilities as it can. For sure it can help you to pinpoint those few vulnerabilities that are exploitable, but that's where your own analysis comes in. I'm not saying there's not a lot to improve in terms of container security. There's a whole bunch to improve there. But focusing on quantities like "amount of CVEs in an image" is not the solution - it's marketing.
- tapland 8y ago
  'My image only has one vulnerability! (it's a terminal that's reachable from the public internet)'
tofflos 8y ago
How about the Distroless containers from Google? https://github.com/GoogleContainerTools/distroless/blob/master/base/README.md https://github.com/GoogleContainerTools/distroless/blob/mast....
- alpb 8y ago
  Similarly, Google Cloud has managed "base container images" for debian, centos and ubuntu: https://cloud.google.com/container-registry/docs/managed-base-images https://cloud.google.com/container-registry/docs/managed-bas...
LunaSea 8y ago
Oh surprise, surprise, another click bait, low effort Node.js security blog by Snyk.io.
ganoushoreilly 8y ago
Anyone else think this was Synack at first with a short url?
- ganoushoreilly 8y ago
  Why would someone downvote an observation that this product was confused with another cyber security firm?
  - ganoushoreilly 8y ago
    Let's make a threepeat.
haroldp 8y ago
I'm a little appalled at the general attitude here. "These issues are probably nothing," is just not a good approach to security. "My app only exposes port 80 so I don't care about local exploits," is not a good approach to security. "Docker images always have a bunch of junk installed that you don't actually use," is not a good approach to security. Am I crazy? What does this tell us about Docker as an ecosystem? It's amazing tech, to be sure, but I feel like a lot of projects are leaning on, "just install the docker image," to avoid the hassles of making flexible, compatible, installable, readable software. If people out in the world can't install your software because it's not compatible with a library they have updated to patch a security vulnerability, they you will hear about it, and maybe get a patch. If people just install your docker image... eh, it works, why bother looking behind the curtain and see how? That's a ecosystem where I would expect to see a lot of bloat and security vulnerabilities creeping in and getting worse over time.
- dentemple 8y ago
  The general attitude is not that the issues are "probably nothing". The general attitude is that, if you're not saying what the issues actually are, then counting them doesn't tell you anything meaningful.
- dwild 8y ago
  > I'm a little appalled at the general attitude here. "These issues are probably nothing," is just not a good approach to security. "My app only exposes port 80 so I don't care about local exploits," is not a good approach to security. "Docker images always have a bunch of junk installed that you don't actually use," is not a good approach to security. We aren't saying that it was the good approach to security, we are just saying that fear-mongering articles like that aren't the good approach to security. That remind me of the anti-virus software that listed each cookies as a virus. If to exploit a security vulnerability in a software you need a security vulnerability that give the same right as that software that contains the vulnerability... yeah you don't have to care about this. I would be happy to be shown wrong on that statement. Does that apply to all the vulnerabilities they count? Probably not, but it certainly inflate the number, just like cookies in an anti-virus count, both give a wrong idea of what's actually happening and aren't the solution to a safer world. Am I crazy to think that we don't have to lie to give security suggestion? > If people out in the world can't install your software because it's not compatible with a library they have updated to patch a security vulnerability, they you will hear about it, and maybe get a patch. If people just install your docker image... eh, it works, why bother looking behind the curtain and see how? That's your definition of a good approach to security?
stevebmark 8y ago
Most of these "vulnerabilities" are in the operating system that aren't run when you run 99% of Docker containers...
- ben509 8y ago
  Okay, what about the 1%? And how do you find out which 1% apply to you?
  - stevebmark 8y ago
    I'm guessing you would know because you're doing a lot of specific work in the container to boot an OS, like get a full Ubuntu instance up and running in a container
ricardobeat 8y ago
The node:10-alpine image is a better option [...] while no vulnerabilities were detected in the version of the Alpine image we tested Note that Docker Hub offers no way of verifying download statistics per tag, so we don't know how many containers are using the base node image - in my experience everyone uses alpine.
- tracker1 8y ago
  I tend to build on default/full and release in alpine.
jrockway 8y ago
Docker's concept of base images is quite useful. You can build your application in a convenient container, then copy the resulting binary into a container with nothing else (except SSL certificates and the time zone database, for Go code anyway). https://gist.github.com/jrockway/cceef8bb5dcef62743f8bcbc044cd2ad https://gist.github.com/jrockway/cceef8bb5dcef62743f8bcbc044... I started doing this around the time we started doing vulnerability scanning and now the containers are both tiny and free of scannable security issues. I recommend that others take this approach if possible, as having too much stuff in your container increases app startup time, storage costs, and your attack surface.
- curtis 8y ago
  I've been doing something similar, but I've been taking it one step further: Alpine's apk package manager will let you treat a subdirectory as "root" and you can install packages there. Then you can write the root out as a tar file and use that as the file system for a "FROM scratch" Docker build. One deficiency is that every package seems to depend on the Busybox shell, so the only way to get rid of that is to delete it after it's installed. So far this approach seems to work OK, but it feels unnecessarily hacky, and I wish there was better tool support for this kind of thing.
nivenhuh 8y ago
Looks like Alpine-based images were found to be "ok". Not sure why folks would use non-alpine based images unless you really have some odd dependencies?
vbernat 8y ago
Currently, "node:10" is based on Stretch. The image is not totally up-to-date. Despite what the article says, Debian Jessie is still maintained, part of Debian LTS effort. After pulling "node:10-jessie", "apt update", "apt list --upgradable" says: curl/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libcurl3/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libcurl3-gnutls/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libcurl4-openssl-dev/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libpq-dev/oldstable 9.4.21-0+deb8u1 amd64 [upgradable from: 9.4.20-0+deb8u1] libpq5/oldstable 9.4.21-0+deb8u1 amd64 [upgradable from: 9.4.20-0+deb8u1] libsystemd0/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] libtiff5/oldstable 4.0.3-12.3+deb8u8 amd64 [upgradable from: 4.0.3-12.3+deb8u7] libtiff5-dev/oldstable 4.0.3-12.3+deb8u8 amd64 [upgradable from: 4.0.3-12.3+deb8u7] libtiffxx5/oldstable 4.0.3-12.3+deb8u8 amd64 [upgradable from: 4.0.3-12.3+deb8u7] libudev1/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] systemd/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] systemd-sysv/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] udev/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] There shouldn't be 500 vulnerabilities here. Of course, node itself may pull many outdated libraries outside of Debian (which is a common practice with software using bundled copies instead of system libraries), but without details, it's hard to know what is accounted for a vulnerability. Moreover, if the Alpine version has 0 vulnerability, it would mean all the vulnerabilities come from Debian. The article mentions backports of fixes, so I suppose they just don't compare blindly package version numbers with the versions provided in the CVE report. For Debian, they could use the security tracker to know if a CVE is fixed and in which version (something Alpine is lacking, so it's difficult to assess the security of Alpine). However, many CVE are not fixed because the security issue is deemed to be too minor. A bit more details about the 500 vulnerabilities would help to understand.
- rixrax 8y ago
  Docker Hub has been providing 3rd party component details for some years now. And based on my limited exposure, they've been pretty spot on in regard to what 3rd party code is included, CVEs impacting shown components (meaning they appear to mostly correctly show backported patches to otherwise vulnerable libs). See below (requires DockerHub account): URL: https://hub.docker.com/_/node/scans/library/node/current-slim https://hub.docker.com/_/node/scans/library/node/current-sli... URL: https://hub.docker.com/_/mongo/scans/library/mongo/4.1 https://hub.docker.com/_/mongo/scans/library/mongo/4.1
mrweasel 8y ago
Generally speaking people should be much more careful about just pulling down images from Docker Hub. So many image are extremely popular, but also very wrong. For instance there are images that contain some web-framework, a webserver and a supervisor process, ignoring the fact that it goes completely against Dockers own documentation. You also find image that contain some weird little tool, apparently solely because author of the Dockerfile wrote it himself, not because you actually need it. I would wish that more people would build packages for their distribution of choice and simply install via the package manager, rather than pulling down compile time dependencies and rebuilding things like webservers, databases or frameworks in containers. We reach the point where I'm concern when people around me use images that aren't just base OS images. The quality of image from Docker hub is all over the place.
cheald 8y ago
FWIW, we use Gitlab to help protect against this: we use its CI scheduling to rebuild our base images on a regular basis. Our Docker image builds are managed via CI, and we have a schedule set up to rebuild them with --no-cache. This keeps our base images fresh without slowing down most marginal builds during the workday. You could obviously do this with cron, as well, but if you already have a CI pipeline managing your base images, it makes sense to set up a recurring build.
finchisko 8y ago
I have an idea how to solve problem with outdated images. What about building service, then will automatically rebuilds your image, when there is a update base image and automatically publish it to docker hub (or private hub). What do you guys think? Is there any interest in such a thing?
zeristor 8y ago
At a previous employee they were quite chuffed to have a Windows 2000 locked down build provided by the NSA
musicale 8y ago
If only there were a technology where you could fix a vulnerability (or other bug) once and it would automatically propagate to all of your applications without having to rebuild them. Maybe we could call it a "base OS image" or maybe "shared libraries."
pawar 8y ago
Rafghts as gthxd true ended uwdhddfi
je42 8y ago
things like https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless should help to reduce the attack surface of your containers.
- collinmanderson 8y ago
  Interesting. So instead of using a package manager inside the container, it downloads .debs from debian, parses and extracts the files, and then uses bazel to build the container directly.
bayesian_horse 8y ago
Most of these vulnerabilities won't matter to most users. Privilege escalation, inside a docker container (mostly) doesn't go very far, and developers should avoid providing code execution to users in the first place. With docker, you will attempt a defense in depth. Even if someone breaks into an app in a container, it can be very hard to break into other containers or the host. I suspect that many, maybe most developers have lower hanging fruits on the security tree than upgrading deployed docker containers daily. The removal of a vulnerability which can't be used as a link in the "kill chain" of a hacker attacking your system isn't improving security that much.
PeterHK 8y ago
if you have issue with having updated packages and or dont like unneeded stuff in your containerbuild. use nixos `dockerTools.buildImage` (builder needs to be nixos machine but that should not be a problem) also i like `skopeo` to upload the image
g105b 8y ago
Can we have a new tab on Hacker News? "ask", "show", "jobs" and "marketing"?

562 points by vinnyglennon 8y ago

A lot of people say you don't need Heroku when you have Docker images, but Heroku actually takes care of the vast majority of vulnerabilities for you.

mikepurvis 8y ago
This has always been my hesitation with Docker— unless you have a proper pipeline in place to be constantly rebuilding your overlay from updated versions of the base image, you're basically just carrying a snapshot of unknown binaries into the future with you, indefinitely. Obviously, any reasonable shop will have such a pipeline in place, but DockerHub and the whole ecosystem of docker getting started tutorials seem to really encourage a "set it and forget it" mentality toward a container once it's built and working.
- orf 8y ago
  Do they? The whole point is you'd rebuild your app every redeploy, which includes from the base image. Docker has a lot of problems but build repeatability is not one of them, in my experience. It makes it really really frictionless, in some cases way too frictionless
- duxup 8y ago
  As someone just getting a feel for Docker I keep thinking: "Wait what is all th---" And then the tutorials or documentation just rolls on.... and doesn't really get back to what I should be doing to maintain / secure anything.
driverdan 8y ago
You're assuming a lot. Take a look through a popular buildpack source and you'll see how they work. They do version pinning which means someone has to be aware of a vuln, its patch, and update the buildpack. I'm not saying they don't do that, just that it still requires a person to make the necessary changes. It's not inherently more secure.

BossingAround 8y ago

Did you know Red Hat has a free container registry [1] which is being constantly watched for CVEs and CVEs are fixed like within a week of announcement? Just try "docker run -it registry.access.redhat.com/rhel7-minimal /bin/bash" and you're good to go... [1] https://access.redhat.com/containers https://access.redhat.com/containers

bithavoc 8y ago
I recently noticed Dockerhub is also reporting vulnerabilities in the Tags tab[0] [0]https://hub.docker.com/_/golang?tab=tags https://hub.docker.com/_/golang?tab=tags
ihattendorf 8y ago
What's the licensing status for these images?
- e1ven 8y ago
  The slide at https://www.redhat.com/files/summit/session-assets/2017/LT122012-dherrman-rhcc-lightning-talk-final.pdf https://www.redhat.com/files/summit/session-assets/2017/LT12... says that the License will be displayed on the Get Image page. This page says (for the NodeJS image) "Before downloading or using this Certified Container, you must agree to both the Red Hat subscription agreement located at redhat.com/licenses and the Red Hat Connect Certified Container Partner’s terms which are referenced by URL in the Partner’s product description and/or included in the Certified Container. If you do not agree with these terms, do not download or use the Certified Container. If you have an existing Red Hat Enterprise Agreement (or other negotiated agreement with Red Hat) with terms that govern subscription services associated with Certified Containers, then your existing agreement will control."
  - indigodaddy 8y ago
    So I can't tell from this if you need a RHEL subscription or not to use the docker images? I guess the most salient question will be can the images yum install things or not? I'm guessing they will have that functionality without requiring a subscription but that's just speculation based on my reading of that blurb.

Thaxll 8y ago

I would be very cautious with those vulnerabilities reports, 95% of the time it's libraries from the Docker image that you will never use or don't have access to.

vjeux 8y ago
I am admin on a few high profile js projects. Github has enabled sending alerts for vulnerabilities, I haven’t yet seen one that was actually a real one. Lots of times there’s a deep dependency that we’re not even using that can accept a regex that may cause a DoS.
- eunoia 8y ago
  The deep dependency regex vulnerability warnings are particularly annoying. Can anyone speak to what the actual attack vector is?
  - cyphar 8y ago
    There is a type of regex called a "pathological" regex which can be used to make certain regex implementations have exponential time complexity. If you exposed this in your application, someone could DoS you. Some libraries might have accidentally pathological regular expressions, and so some user input might be able to trigger the pathological case (Atom had a bug a few years ago where certain source files would cause the editor to lock up, and it was caused by a bad regex they used for parsing to figure out the auto indentation[1]). Russ Cox wrote an article about this in 2007[2], and the situation is still the same. Go doesn't have this problem since Russ Cox is one of the lead authors of Go, and wrote Go's regex library. [1]: http://davidvgalbraith.com/how-i-fixed-atom/ http://davidvgalbraith.com/how-i-fixed-atom/ [2]: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html
    - eunoia 8y ago
      Thanks for an excellent answer!
    - 8y ago

alexnewman 8y ago

How does this compare to vagrant?

e1ven 8y ago
One big difference is that (afaik) people aren't putting vagrant images into production, it's for local development.
- alexnewman 8y ago
  sure they do. you are totally wrong. they just shouldn’t
cronix 8y ago
Do people use vagrant in production?
- mikepurvis 8y ago
  One hopes not, though they kinda do support it: https://www.vagrantup.com/docs/push/ https://www.vagrantup.com/docs/push/
adrianmsmith 8y ago
In addition to the point others have raised that Vagrant is not designed to be used in production, Vagrant is a lot more stateful than Docker (long-lived VMs) so you can easily run “apt-get update && apt-get upgrade” or equivalent. Potentially from the Vagrantfile to make sure rebuilds get the updates as well.
- alexnewman 8y ago
  you are totally wrong i know plenty of people who do. i also know people who think docker shouldn’t be used in production and that we should use containerd just like vagrant/packer
fulafel 8y ago

SahAssar 8y ago

I really don't like these kinds of alarmist reports if they are not actually saying what the problems are and how they can lead to actual, real, serious attacks. A lot of claimed "high CVSS" vulnerabilities aren't when you put them in context, and sometimes vice versa. Yes, we should strive to be a lot better and maintaining dependencies is one thing that generally everyone in modern development does bad, but this sort of alarmist posts that have no concrete examples generally just lead to people ignoring the whole field/industry. If those images are exploitable in the ways they are intended to be used highlight that. If it's as bad as this post makes it sound then that should be easy.

subcosmos 8y ago
RSA time - this is where the sales pitches begin
objectified 8y ago
CVSS is a common and open approach. CVSS scores that are particularly high, are often directly exploitable. If they aren't, then probably their calculation was done wrong. You can try it for yourself here: https://www.first.org/cvss/calculator/3.0 https://www.first.org/cvss/calculator/3.0 Having said that, what can lead to a serious attack for your organization is often subject to a combination of factors. Say, there is an SSRF vulnerability in your own application, because the HTTP library you use doesn't parse the URL correctly, so now an attacker can let your application perform arbitrary HTTP requests. But fortunately, the connectivity of your application server is quite limited, so that an attacker can't reach internal systems, can't go to the internet, uses strong authentication to web services it does use, all the good stuff. So now the chance of a successful, serious attack is largely diminished. Also, it can be quite complicated to know what the exact, real dependencies of your application are. What is the transitive/recursive list of dependencies your application uses? Which of your application's dependencies actually use libraries on your system? And what are _their_ dependencies? I think that cost wise, it is cheaper to make sure your application dependencies, containers, host system libraries, container orchestration tools, etc. are always up to date. And yeah, I agree that the post doesn't do a good job at all to provide a sane rationale on _why_ you should update. Anyone who has ever administered an operating system knows that security vulnerabilities are found in them every day. But the awareness that a Docker container is subject to the same pace is definitely not present everywhere, and it probably should be.

coleifer 8y ago

Can't tell if this is fud or not. For example with node, typically you'd only be exposing port 80, right? So as long as your http server isn't vulnerable you're ok. Or same with Redis, which I hope isn't anywhere near the public internet?

pas 8y ago
Also popular, high-velocity projects have a lot of CVEs. That doesn't mean much. How fast these images get updated? How widespread these vulnerable images are?
acdha 8y ago
> So as long as your http server isn't vulnerable you're ok … and everything loaded by every dependency under any situation which doesn't require admin access. Your server can be fine but if e.g. you process images you have to follow libjpeg, libpng, zlib, littlecms, etc. Yes, it's a lot better than a full multiuser Unix system where you have to worry about background processes which aren't useful for a dedicated microservice but there's a long history of vulnerabilities in components being combined into successful exploits and it's usually far more expensive to try to analyze those chains than to upgrade. This brings me to: > Or same with Redis, which I hope isn't anywhere near the public internet? That's hopefully true in general but also consider chained attacks: say you're running a web app and I find a way to run code in the app process. That might be limited but if I can poke at Redis enough to run code there I can test whether you were as diligent about sandboxing it. That'll hurt if, say, there was a container exploit which someone delayed patching because they “knew” our app only runs as an unprivileged user.

DCKing 8y ago

Although vulnerability scanners can be a useful tool, I find it very troublesome that you can utter the sentence "this package contains XX vulnerabilities, and that package contains YY vulnerabilities" and then stop talking. You've provided barely any useful information! The quantity of vulnerabilities in an image is not really all that useful information. A large amount of vulnerabilities in a Docker image does not necessarily imply that there's anything insecure going on. Many people don't realize that a vulnerability is usually defined as "has a CVE security advisory", and that CVEs get assigned based on a worst-case evaluation of the bug. As a result, having a CVE in your container barely tells you anything about your actual vulnerability position. In fact, most of the time you will find that having a CVE in some random utility doesn't matter. Most CVEs in system packages don't apply to most of your containers' threat models. Why not? Because an attacker is very unlikely to be able to use vulnerabilities in these system libraries or utilities. Those utilities are usually not in active use in the first place. Even if they are used, you are not usually in a position to exploit these vulnerabilities as an attacker. Just as an example, a hypothetical outdated version of grep in one of these containers can hypothetically contain many CVEs. But if your Docker service doesn't use grep, then you would need to manually run grep to be vulnerable. And an attacker that is able to run grep in your Docker container has already owned you - it doesn't make a difference that your grep is vulnerable! This hypothetical vulnerable version of grep therefore makes no difference in the security of your container, despite containing many CVEs. It's the quality of these vulnerabilities that matters. Can an attacker actually exploit the vulnerabilities to do bad things? The answer for almost all of these CVEs is "no". But that's not really the product that Snyk sells - Snyk sells a product to show you as many vulnerabilities as possible. Any vulnerability scanner company thinks it can provide most business value (and make the most money) by reporting as many vulnerabilities as it can. For sure it can help you to pinpoint those few vulnerabilities that are exploitable, but that's where your own analysis comes in. I'm not saying there's not a lot to improve in terms of container security. There's a whole bunch to improve there. But focusing on quantities like "amount of CVEs in an image" is not the solution - it's marketing.

tapland 8y ago
'My image only has one vulnerability! (it's a terminal that's reachable from the public internet)'

tofflos 8y ago

How about the Distroless containers from Google? https://github.com/GoogleContainerTools/distroless/blob/master/base/README.md https://github.com/GoogleContainerTools/distroless/blob/mast....

alpb 8y ago
Similarly, Google Cloud has managed "base container images" for debian, centos and ubuntu: https://cloud.google.com/container-registry/docs/managed-base-images https://cloud.google.com/container-registry/docs/managed-bas...

LunaSea 8y ago

Oh surprise, surprise, another click bait, low effort Node.js security blog by Snyk.io.

ganoushoreilly 8y ago

Anyone else think this was Synack at first with a short url?

ganoushoreilly 8y ago
Why would someone downvote an observation that this product was confused with another cyber security firm?
- ganoushoreilly 8y ago
  Let's make a threepeat.

haroldp 8y ago

I'm a little appalled at the general attitude here. "These issues are probably nothing," is just not a good approach to security. "My app only exposes port 80 so I don't care about local exploits," is not a good approach to security. "Docker images always have a bunch of junk installed that you don't actually use," is not a good approach to security. Am I crazy? What does this tell us about Docker as an ecosystem? It's amazing tech, to be sure, but I feel like a lot of projects are leaning on, "just install the docker image," to avoid the hassles of making flexible, compatible, installable, readable software. If people out in the world can't install your software because it's not compatible with a library they have updated to patch a security vulnerability, they you will hear about it, and maybe get a patch. If people just install your docker image... eh, it works, why bother looking behind the curtain and see how? That's a ecosystem where I would expect to see a lot of bloat and security vulnerabilities creeping in and getting worse over time.

dentemple 8y ago
The general attitude is not that the issues are "probably nothing". The general attitude is that, if you're not saying what the issues actually are, then counting them doesn't tell you anything meaningful.
dwild 8y ago
> I'm a little appalled at the general attitude here. "These issues are probably nothing," is just not a good approach to security. "My app only exposes port 80 so I don't care about local exploits," is not a good approach to security. "Docker images always have a bunch of junk installed that you don't actually use," is not a good approach to security. We aren't saying that it was the good approach to security, we are just saying that fear-mongering articles like that aren't the good approach to security. That remind me of the anti-virus software that listed each cookies as a virus. If to exploit a security vulnerability in a software you need a security vulnerability that give the same right as that software that contains the vulnerability... yeah you don't have to care about this. I would be happy to be shown wrong on that statement. Does that apply to all the vulnerabilities they count? Probably not, but it certainly inflate the number, just like cookies in an anti-virus count, both give a wrong idea of what's actually happening and aren't the solution to a safer world. Am I crazy to think that we don't have to lie to give security suggestion? > If people out in the world can't install your software because it's not compatible with a library they have updated to patch a security vulnerability, they you will hear about it, and maybe get a patch. If people just install your docker image... eh, it works, why bother looking behind the curtain and see how? That's your definition of a good approach to security?

stevebmark 8y ago

Most of these "vulnerabilities" are in the operating system that aren't run when you run 99% of Docker containers...

ben509 8y ago
Okay, what about the 1%? And how do you find out which 1% apply to you?
- stevebmark 8y ago
  I'm guessing you would know because you're doing a lot of specific work in the container to boot an OS, like get a full Ubuntu instance up and running in a container

ricardobeat 8y ago

The node:10-alpine image is a better option [...] while no vulnerabilities were detected in the version of the Alpine image we tested Note that Docker Hub offers no way of verifying download statistics per tag, so we don't know how many containers are using the base node image - in my experience everyone uses alpine.

tracker1 8y ago
I tend to build on default/full and release in alpine.

jrockway 8y ago

Docker's concept of base images is quite useful. You can build your application in a convenient container, then copy the resulting binary into a container with nothing else (except SSL certificates and the time zone database, for Go code anyway). https://gist.github.com/jrockway/cceef8bb5dcef62743f8bcbc044cd2ad https://gist.github.com/jrockway/cceef8bb5dcef62743f8bcbc044... I started doing this around the time we started doing vulnerability scanning and now the containers are both tiny and free of scannable security issues. I recommend that others take this approach if possible, as having too much stuff in your container increases app startup time, storage costs, and your attack surface.

curtis 8y ago
I've been doing something similar, but I've been taking it one step further: Alpine's apk package manager will let you treat a subdirectory as "root" and you can install packages there. Then you can write the root out as a tar file and use that as the file system for a "FROM scratch" Docker build. One deficiency is that every package seems to depend on the Busybox shell, so the only way to get rid of that is to delete it after it's installed. So far this approach seems to work OK, but it feels unnecessarily hacky, and I wish there was better tool support for this kind of thing.

nivenhuh 8y ago

Looks like Alpine-based images were found to be "ok". Not sure why folks would use non-alpine based images unless you really have some odd dependencies?

vbernat 8y ago

Currently, "node:10" is based on Stretch. The image is not totally up-to-date. Despite what the article says, Debian Jessie is still maintained, part of Debian LTS effort. After pulling "node:10-jessie", "apt update", "apt list --upgradable" says: curl/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libcurl3/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libcurl3-gnutls/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libcurl4-openssl-dev/oldstable 7.38.0-4+deb8u14 amd64 [upgradable from: 7.38.0-4+deb8u13] libpq-dev/oldstable 9.4.21-0+deb8u1 amd64 [upgradable from: 9.4.20-0+deb8u1] libpq5/oldstable 9.4.21-0+deb8u1 amd64 [upgradable from: 9.4.20-0+deb8u1] libsystemd0/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] libtiff5/oldstable 4.0.3-12.3+deb8u8 amd64 [upgradable from: 4.0.3-12.3+deb8u7] libtiff5-dev/oldstable 4.0.3-12.3+deb8u8 amd64 [upgradable from: 4.0.3-12.3+deb8u7] libtiffxx5/oldstable 4.0.3-12.3+deb8u8 amd64 [upgradable from: 4.0.3-12.3+deb8u7] libudev1/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] systemd/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] systemd-sysv/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] udev/oldstable 215-17+deb8u10 amd64 [upgradable from: 215-17+deb8u9] There shouldn't be 500 vulnerabilities here. Of course, node itself may pull many outdated libraries outside of Debian (which is a common practice with software using bundled copies instead of system libraries), but without details, it's hard to know what is accounted for a vulnerability. Moreover, if the Alpine version has 0 vulnerability, it would mean all the vulnerabilities come from Debian. The article mentions backports of fixes, so I suppose they just don't compare blindly package version numbers with the versions provided in the CVE report. For Debian, they could use the security tracker to know if a CVE is fixed and in which version (something Alpine is lacking, so it's difficult to assess the security of Alpine). However, many CVE are not fixed because the security issue is deemed to be too minor. A bit more details about the 500 vulnerabilities would help to understand.

rixrax 8y ago
Docker Hub has been providing 3rd party component details for some years now. And based on my limited exposure, they've been pretty spot on in regard to what 3rd party code is included, CVEs impacting shown components (meaning they appear to mostly correctly show backported patches to otherwise vulnerable libs). See below (requires DockerHub account): URL: https://hub.docker.com/_/node/scans/library/node/current-slim https://hub.docker.com/_/node/scans/library/node/current-sli... URL: https://hub.docker.com/_/mongo/scans/library/mongo/4.1 https://hub.docker.com/_/mongo/scans/library/mongo/4.1

mrweasel 8y ago

Generally speaking people should be much more careful about just pulling down images from Docker Hub. So many image are extremely popular, but also very wrong. For instance there are images that contain some web-framework, a webserver and a supervisor process, ignoring the fact that it goes completely against Dockers own documentation. You also find image that contain some weird little tool, apparently solely because author of the Dockerfile wrote it himself, not because you actually need it. I would wish that more people would build packages for their distribution of choice and simply install via the package manager, rather than pulling down compile time dependencies and rebuilding things like webservers, databases or frameworks in containers. We reach the point where I'm concern when people around me use images that aren't just base OS images. The quality of image from Docker hub is all over the place.

cheald 8y ago

FWIW, we use Gitlab to help protect against this: we use its CI scheduling to rebuild our base images on a regular basis. Our Docker image builds are managed via CI, and we have a schedule set up to rebuild them with --no-cache. This keeps our base images fresh without slowing down most marginal builds during the workday. You could obviously do this with cron, as well, but if you already have a CI pipeline managing your base images, it makes sense to set up a recurring build.

finchisko 8y ago

I have an idea how to solve problem with outdated images. What about building service, then will automatically rebuilds your image, when there is a update base image and automatically publish it to docker hub (or private hub). What do you guys think? Is there any interest in such a thing?

zeristor 8y ago

At a previous employee they were quite chuffed to have a Windows 2000 locked down build provided by the NSA

musicale 8y ago

If only there were a technology where you could fix a vulnerability (or other bug) once and it would automatically propagate to all of your applications without having to rebuild them. Maybe we could call it a "base OS image" or maybe "shared libraries."

pawar 8y ago

Rafghts as gthxd true ended uwdhddfi

je42 8y ago

things like https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless should help to reduce the attack surface of your containers.

collinmanderson 8y ago
Interesting. So instead of using a package manager inside the container, it downloads .debs from debian, parses and extracts the files, and then uses bazel to build the container directly.

bayesian_horse 8y ago

Most of these vulnerabilities won't matter to most users. Privilege escalation, inside a docker container (mostly) doesn't go very far, and developers should avoid providing code execution to users in the first place. With docker, you will attempt a defense in depth. Even if someone breaks into an app in a container, it can be very hard to break into other containers or the host. I suspect that many, maybe most developers have lower hanging fruits on the security tree than upgrading deployed docker containers daily. The removal of a vulnerability which can't be used as a link in the "kill chain" of a hacker attacking your system isn't improving security that much.

PeterHK 8y ago

if you have issue with having updated packages and or dont like unneeded stuff in your containerbuild. use nixos `dockerTools.buildImage` (builder needs to be nixos machine but that should not be a problem) also i like `skopeo` to upload the image

g105b 8y ago

Can we have a new tab on Hacker News? "ask", "show", "jobs" and "marketing"?