Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

banyanops.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#61

Post by jgummaraju »

acdha wrote: post #34
dantiberian wrote: post #15

This isn't great, but it's not quite as terrible as its being made out to be for the official packages. The Mercurial bug is only relevant if you're using Mercurial with user supplied input on your production servers. Unlikely if you're not BitBucket. http://chargen.matasano.com/chargen/2015/3/17/this-new-vulne... Is a good read on the subject. The libtasn1 bug seems to be only relevant if you're using GnuTLS. Again,…

The take-home message is that you need to have a strategy for deploying updates. It's true that not all bugs are exploitable but there's a long history of people being catastrophically wrong in that kind of conclusion. More importantly, however, you want updates to be a routine frequent thing so you don't train people to ignore them or let the backlog build up to the point where the size itself becomes a deterrent to…

One of the authors here. I'd like to second this take-home message. The core of our work was to bring to the fore-front that package management using containers is important and we need to have sound operations management/security practices in place.

We think Docker, and containers in general, is a great way to deploy software -- the speed and agility is so much better than traditional approaches. This also means that we should have sound security practices in place from the very beginning, or else we could easily end up with insecure images floating around in several places (dev laptops to public cloud).

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#62

Post by yoshiotu »

phelmig wrote: post #31

Great article. We'll need a better integration of security tracking and handling in our containerized infrastructure soon. You have to be a little bit careful when it comes to version numbers and matching them to security issues. Most linux distributions for example apply security patches to older releases. E.g. Ubuntu 14.04LTS comes with Apache 2.4.7-1ubuntu4.4 which one might parse as 2.4.7 which has multiple secur…

Study co-author here. We did observe that it's essential to be careful about comparing package version numbers on a per-bistro basis, and there are some tricky cases such as the one you pointed out, and rpm epoch numbers as another example. I believe we handled them correctly in the study.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#63

Post by nickcano »

innguest wrote: post #56
jakozaur wrote: post #4

A bit overstated. They definition of security vulnerable == got package which is vulnerable. However, merely having some packages with vulnerabilities may not be enough. E.g. you have security in package manager (apt), but you never use it after building the image. Or even shellshock is no flyer, if you don't use CGI scripts and don't have ssh access. In Virtual Machines this problem also exists. I guess it is more a…

Tell me about it! Gotta love those security experts that your company hires when they say to you "your app has a security issue right here" and I say "alright then prove it, hack it, let's see if there really is a security issue" and they can't do it. If I don't want to worry about deployment, there's Heroku. If I don't want to worry about testing, there's Circle CI. If I don't want to worry about scaling, there's AW…

Security Guy: Hey, bank, it seems like your vault is accessible via some old sewage tunnels.

Bank: So what? Nobody knows about those tunnels.

Security Guy: But someone who finds them, like me, but with less morals, could rob you.

Bank: Prove it. Rob the vault.

Security Guy: ..... ?

Finding a vulnerability isn't the same thing as exploiting one, and a lack of exploitation doesn't imply a lack of vulnerability. You also have to consider that a small portion of vulnerabilities are actually exploitable, but it's a very hard problem to find out which ones are and which ones aren't. Exploiting a single vulnerability is typically harder, in fact, than patching a dozen of them (for example, you can easily start using a secure version of strcpy(), but exploiting it requires an attacker to smash the stack or ROP their way into full execution).

The bottom line is that you're not only naive if you believe what you just said, but you're doing a huge disservice to anybody who uses any code that you may write.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#64

Post by teacup50 »

pyre wrote: post #42
dredmorbius wrote: post #40

Earlier quoted context omitted.

If you're basing deploys on image builds, you're not "rolling back" anything, but are building a new host (or host image) based on the correct dependencies. That process relies on your platform's own dependency-resolution system, and I hope you're using something sane such as Debian/Ubuntu, or are building from source via Gentoo. RPM distros can work but tend to be far flakier. Start with a base install, have a packa…

I think that the "real" problem here is that Python's package management and apt/yum don't really interface well. I've built .debs for Python packages before, and it was a huge pain in the ass, even with the scripts and automations that I was able to find for it. It's 'simple' for me to build a virtualenv in a directory with `pip install -r requirements.txt` in my source repo, but everything I've read about making th…

The 'real' problem is that you shouldn't have to install dependencies in OS-level locations for an application-level product.

In other words, the app should be able to bundle dependencies without having to use a crazy opaque container system, and those dependencies should be easily auditable.

This is the case for Java, where dependencies are 1) bundled with the application, 2) declared explicitly, 3) signed, 4) centrally managed with maven repository software.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#65

Post by pyre »

teacup50 wrote: post #64
pyre wrote: post #42

Earlier quoted context omitted.

I think that the "real" problem here is that Python's package management and apt/yum don't really interface well. I've built .debs for Python packages before, and it was a huge pain in the ass, even with the scripts and automations that I was able to find for it. It's 'simple' for me to build a virtualenv in a directory with `pip install -r requirements.txt` in my source repo, but everything I've read about making th…

The 'real' problem is that you shouldn't have to install dependencies in OS-level locations for an application-level product. In other words, the app should be able to bundle dependencies without having to use a crazy opaque container system, and those dependencies should be easily auditable. This is the case for Java, where dependencies are 1) bundled with the application, 2) declared explicitly, 3) signed, 4) centr…

In Python, you get similar things with the exception of "bundled with the application" and IIRC "signed" only happens when uploading to the Python Package Index.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#66

Post by seanp2k2 »

jkyle wrote: post #58
Sleaker wrote: post #47

Earlier quoted context omitted.

I thought the point of using docker containers was that they were pre-packaged apps. Not so you had to continually rebuild the container with your own updated packages. Doesn't having to rebuild the container to fix security vulns defeat one of the major reasons to have versioned docker images released for use? You could very well end up breaking dependencies.

I would say the primary benefit of docker is that you can build once, run the same everywhere. E.g. you have a consistent, reproducible application environment which _should_ be vetted through a gauntlet of continuous integration, testing, etc. that once created will run identically on any host running docker. If you have a "trusted source" to do all the grunt work for you, fine. But docker's promise isn't guaranteei…

Just like Java. We've seen how this one ends :)

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#67

Post by javajosh »

seanp2k2 wrote: post #66
jkyle wrote: post #58

Earlier quoted context omitted.

I would say the primary benefit of docker is that you can build once, run the same everywhere. E.g. you have a consistent, reproducible application environment which _should_ be vetted through a gauntlet of continuous integration, testing, etc. that once created will run identically on any host running docker. If you have a "trusted source" to do all the grunt work for you, fine. But docker's promise isn't guaranteei…

Just like Java. We've seen how this one ends :)

Well, sort of. Java was never really like Docker, and in fact always struggled architecturally to provide a good container abstraction for applications. The "servlet container" idea was (and is) a failure. Java never had the equivalent of the Docker daemon, and it only (relatively) recently got something like Dockerhub via Maven--and Maven repos aren't integrated with the JVM or the (non-existent) Java daemon.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#68

Post by evol262 »

jkyle wrote: post #60
evol262 wrote: post #50

Earlier quoted context omitted.

My primary contention with your post is that docker doesn't provide a package-manager-like way of ifnding out whether or not you're running older images. Everyone has their own homegrown way of doing it. 1. Don't use old shit 2. Docker should provide a way to tell you you're not running the latest tagged image so you stop running old shit 3. Don't use base images whose maintainers can't be bothered to rebuild when se…

Well, all docker containers are hashed and can be version tagged. If you do a pull and run the 'latest' tag, it'll always be the HEAD of the commit hash. This is assuming you want to trust some 3rd party with the maintenance and security of your production environment. Docker containers are, usually, just operating systems running a single logical application service. I don't think Docker promises a free Sys Admin. ;…

My complaint is primarily that there's no mechanism to let you know "hey, there's an update to this" in the same way as apt, yum, and other systems do.

It's not about trusting a 3rd party with the maintenance and security of your production environment as much as it is "Docker should provide a way to let the people handling the maintenance of your production environment to know shit may be happening". Rebuilding from the 'latest' tag is great. If you know you have to rebuild, and that there's an update available.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#69

Post by innguest »

nickcano wrote: post #63
innguest wrote: post #56

Earlier quoted context omitted.

Tell me about it! Gotta love those security experts that your company hires when they say to you "your app has a security issue right here" and I say "alright then prove it, hack it, let's see if there really is a security issue" and they can't do it. If I don't want to worry about deployment, there's Heroku. If I don't want to worry about testing, there's Circle CI. If I don't want to worry about scaling, there's AW…

Security Guy: Hey, bank, it seems like your vault is accessible via some old sewage tunnels. Bank: So what? Nobody knows about those tunnels. Security Guy: But someone who finds them, like me, but with less morals, could rob you. Bank: Prove it. Rob the vault. Security Guy: ..... ? Finding a vulnerability isn't the same thing as exploiting one, and a lack of exploitation doesn't imply a lack of vulnerability. You als…

Security Guy: Hey, bank, it seems like your vault is accessible via some old sewage tunnels. But fret not, I as a security expert that goes around making sure places such as banks and schools can't have specific places accessed by entrances other than designated the ones, have a solution for you. Just put your safe inside this chroot building. What this does is makes sure only sewage goes through sewage pipes (not people). So all you have to do is purchase this solution and we will guarantee that no one will come into your bank through sewage pipes.

Why does that never happen? Why are security experts always consultants and they never have a product to sell?

Naive is a person that thinks just because they are a security expert, programmers will care. No amount of shaming will change that. If you're a security expert your job is to make this so easy that I almost don't think about it. Like I almost don't think about databases, deployment, testing, scaling. Getting on your high horse and begging programmers changes nothing.

Just look at RSpec. All of a sudden everyone wants to write tests because it's fun and easy and looks sort of like English. Now we don't have to care much about tests, we just write them and RSpec runs them, collects and reports errors, formats them nicely, tells me the path and the line number where each error occurred, etc. Now imagine you're a "testing expert" and there's no RSpec and you keep yelling at programmers to change their ways, to write and maintain tests, and so on. No one would do it (like few did before the recent craze). So please, learn from that lesson, round up some peers, and contribute to your damn field by letting me forget about it.

Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities

#70

Post by jgummaraju »

jkyle wrote: post #41

I have a few contentions with the study. First, if you look at their own analysis the number drops from 30% to 23% when limited to only the latest tagged images in the official repository. I'd expect to see a higher rate of vulnerabilities in previous versions...that's why you rebuild. Find me a linux admin that would accept their OS is vulnerable if you're citing old, unpatched versions. Second, they seem to virtual…

Great points!

Just to clarify, our article was not meant to blame any particular party, but rather to provide awareness of the security vulnerabilities that exist even in the latest official images on Docker Hub.

As you point out, this study specifically focused on the OS package vulnerabilities -- including application-level packages and/or other types of vulnerabilities would increase the percentage of vulnerable images.

As we also mention in the article, rebuilding is a great way to solve some of the problems. However, rebuilding comes at a cost -- the overhead of redeploying the container infrastructure, managing audit trails, potential instability introduced to developer applications, etc. These need be balanced against the benefits of rebuilding constantly.

Post reply on HN