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

[Pascal Meunier <pmeunier@cerias.purdue.edu>]

I have difficulties with some statements:

"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 can be very difficult to "consult with the vendor".  It's much, much 
easier to just disclose the vulnerability without a CVE.  I'm afraid 
that the above policy is a strong incentive against using CVE 
identifiers.

Also, I'm confused by the paragraph with the ASUS example as it seems 
to 
contradict the preceding one.

Pascal



On 06/07/2016 11:14 PM, Common Vulnerabilities & Exposures wrote:
> 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:
>
> 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<http://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<mailto:secalert@redhat.com>
>