definitions for what is CVE worthy with downloads/installs and containers

[Kurt Seifried <kseifried@redhat.com>]

So I've seen the classic "a CVE is for a security vulnerability, a security vulnerability is something that crosses a trust boundary". 

Obviously this is open to all sorts of interpretation, e.g. for passwords we can all agree a secret backdoor with a hard coded password is a CVE, but what about an app that has a default password that you are then forced to change once you login? What about an app that must be exposed to the network (introducing a race where an attacker can potentially get in first)? In general we have a good idea of where to draw the line for passwords (documented? changeable? is there a realistic secure way to deploy this products?). 

So first a quick story: my sons play Minecraft a lot, so I'm going to set them up a server. I found some software, setup of course is annoying (some weird dependencies that aren't packaged on my platforms of choice). So I thought "hey, let's find a docker container!" and luckily there are several:

https://github.com/5t111111/docker-pocketmine-mp/blob/master/Dockerfile

You will note it has the line:

RUN cd PocketMine-MP && wget -q -O - http://cdn.pocketmine.net/installer.sh | bash -s - -v beta

which is a fancy way of saying "go get http://cdn.pocketmine.net/installer.sh and run it" luckily this is slightly mitigated by an earlier 

USER pocketmine

statement which means the command is running as a user and not root. But a quick search of github reveals:

https://github.com/search?utf8=%E2%9C%93&q=RUN+bash+wget++http&type=Code&ref=searchresults

which for example shows:

https://github.com/wyvernnot/docker-minecraft-pe-server/blob/master/Dockerfile

which does not downgrade to a user but instead runs the script as root. So at point do we draw a line in the sand for "downloads random stuff and runs it" as being CVE worthy? My thoughts:

To make it less CVE worthy:

1) Documents mentioning what this is doing and that it is dangerous 

2) Downgrading to less privileged users

3) Uses HTTPS to serve the content

4) Uses a well known/trusted site to serve the content

To make it more CVE worthy:

1) no documents/mention of what it is doing

2) Runs commands as a privileged user (e.g. root)

3) Uses HTTP to download content (and has no end to end signing/checks)

4) Uses basically random servers nobody has ever heard of

5) is widely used (e.g. for containers something in the Docker Registry)

For example a Dockerfile from Nginx:

https://github.com/nginxinc/docker-nginx/blob/11fc019b2be3ad51ba5d097b1857a099c4056213/mainline/alpine/Dockerfile

TL;DR: They set the GPG key fingerprint as an env variable in the Dockerfile:

ENV GPG_KEYS B0F4253373F8F6F510D42178520A9993A1C052F8

They later download that key and use it to verify the nginx tarball they downloaded:

&& gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GPG_KEYS" \

&& gpg --batch --verify nginx.tar.gz.asc nginx.tar.gz \

so they are definitely trying to do the right thing (I need to confirm that this will actually error out during build if the key isn't available/wrong key is served/asc signature is bad) and assuming it works as expected (an error triggers the Docker build to abort) then obviously this is safe and no need for a CVE. 

But most containers are not doing anything like this, not even close, and I suspect we need to start assigning CVE's as it looks like a lot of popular container Dockerfiles are very insecure with how they build software. 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com