RE: CVE Request - Coin Widget serves code over plain http.

["Christey, Steven M." <coley () mitre org>]

Kurt Seifried said:

> The problem is not in the code, the problem is in how the code is
> served/distributed. CVE is traditionally for software and not for
> services. So under a simplistic reading of that strict definition I
> would say this doesn't deserve a CVE.

tl;dr I've looked into this issue some more and in general, I agree.

I suspect there are a couple issues here; note that these are some of my impressions and not anything "official" from 
CVE:

1) The downloading and execution of code from an "http://"; URL is subject to various attacks, including DNS spoofing 
and MITM.  To my way of thinking, the main issue is that the code is not downloaded in a way that preserves its 
integrity AND ensures that it was downloaded from a trusted source.  For CVE, a core question for inclusion is, "does 
this download of code WITHOUT an integrity check (CWE-494) happen automatically, or is there a documented manual step 
in which the administrator is expected to verify the integrity?"

2) With Coin Widget in particular, the widget is available in github, and people can download the code and install it 
on their own servers (see the "Download the Source Code" link from the main page at http://coinwidget.com/).  Thus Coin 
Widget can be offered as a customer-controlled "product" (not just a service) and, as a product, could qualify for a 
CVE, but read on...

3) However, from http://coinwidget.com/, it appears that the Coin Widget installation documentation tells the installer 
to modify widget/coin.js to point to an admin-controlled source.  This suggests that it's an admin-controlled 
configuration, which may exclude it from CVE.

4) The "Wizard" that generates Coin Widget code for people is out of scope - this is inherently "site-specific" in that 
there would be no customer actions to fix a vulnerability; the Coin Widget admins could modify their code to avoid use 
of http:// URLs entirely, without any action on behalf of customers.

5) One could argue that this issue is due to a fundamental problem in HTTP, and as such, HTTP should be "blamed" for 
not having integrity checks; but, to assign a CVE to every commonly-used protocol that doesn't use encryption is not 
necessarily appropriate, either.

All in all, for now, it seems to me that this particular Coin Widget issue is out of CVE's scope because of the 
software-as-a-service and configuration considerations, but the general issue of "reading and executing scripting code 
from http:// links without verification" may qualify.

> However the world is changing, for example a program that included an
> auto-updater component that was advertised as being "Secure" but went
> over HTTP would probably qualify for a CVE.

It probably would, but since this might theoretically affect any software that's 5 years old or more and downloads 
anything over unencrypted channels without integrity checks, the raw number of CVEs that could be assigned is rather 
daunting.

> Steve I'm bouncing this to you, I'm inclined to NOT assign a CVE since
> it opens up a huge can of worms (every single bit of JavaScript served
> from HTTP and not available via HTTPS ever), but I can also see how it
> should maybe get a CVE.

My gut reaction is that you might be treating this as a more complex issue than it really is.  Simple delivery of code 
over HTTP might affect Coin Widget and many other packages, regardless of whether *some* code is delivered over HTTPS.

> The good news is that future versions of Firefox are implementing a
> security policy that when loading a page from HTTPS they will not load
> page components from HTTP, which would fix this issue. Hopefully all
> the browsers do this.

While there are no formal rules, CVE generally considers "typical behavior of market-leading browsers" as acceptable 
considerations for determining a vulnerability; e.g., many XSS attack variants only apply to 1 or 2 browsers.

- Steve