[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Kurt –

 

As you are well aware, CVE assignment is never an exact science. The following is a description of our current practice:

 

·         The question of whether it is "software acting exactly as it is designed" depends on who sends the CVE ID request. For example, it is plausible for a vendor's server to offer the same executable code (or update service) through both HTTP and HTTPS, and the URL hardcoded into a client-side product was -- by design -- supposed to start with https, but it started with http by accident. Thus, if it is a vendor-initiated request for a CVE ID to tag a required security update for their customers, then the CVE ID request is always accepted.

·         If the origin of the CVE ID request seems unrelated to the party that wrote the code, then (sometimes but not 100% of the time) the CVE ID request is rejected with a suggestion to consult with the vendor.

·         It would be hard to achieve 100% rejections, even if a CNA wanted to, because the person sending the CVE ID request may neglect to mention, or may be unwilling to mention, the precise nature of the problem. A large fraction of the population believes that it is always a vulnerability for any product to continuously make requests for executable code over unencrypted HTTP, with no other integrity protection, and execute code whenever a response is received. Because that much is obvious in their world view, their vulnerability description may focus on other details, such as file-format manipulation, etc.

·         Our prevailing opinion is that, for this HTTP/executable-code scenario, the best a CNA can do is assign CVE IDs in cases where they believe CVE consumers want those IDs to exist. If the requester sends a credible description of high exploitation likelihood, and there is no counterclaim from the vendor itself that this is "software acting exactly as it is designed," then it qualifies for a CVE ID.

 

This matches what happened for ASUS (the vendor refused to respond at all). If another requester does not describe exploitation likelihood or asserts that there is essentially no exploitation likelihood, and there is no clarification from the vendor, then the request can be rejected on the "software acting exactly as it is designed" grounds.

 

In other words, existence of a CVE ID should depend a little less on a comprehensive theory of what a vulnerability is, and depend a little more on judgment about whether the ID will help real-life organizations with risk management. This requires a little more work from the CNA, but makes CVE more useful than with either the 100% accept or 100% reject options.

 

Regards,

 

The CVE Team

 

 

 

 

From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of Kurt Seifried
Sent: Monday, June 06, 2016 12:18 PM
To: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: definitions for what is CVE worthy with downloads/installs and containers

 

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:

 

 

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:

 

 

which for example shows:

 

 

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:

 

 

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

Page Last Updated or Reviewed: June 16, 2016