Docker Image Vulnerabilities: example changes to assignment rules

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Docker Image Vulnerabilities: example changes to assignment rules

Pascal Meunier-2
(resending a slightly modified version because the email I sent from [hidden email] on 1/12 wasn't sent to the list)


Thank you to Jonathan for the slides summarizing the issues and questions.
There are 3 discussion topics highlighted in the slides:

1. Should publicly distributed Docker images be considered products per the CNA
Rules?
2. Should an insecure default configuration (e.g., default password for the
admin user) be considered a vulnerability?
3. Should inherited insecure defaults share the same CVE ID?

Below are considerations and changes to the assignment rules, in the hope they
might help the discussion.

Definitions.  For the purposes of CVE assignment, a "virtual image" can either
be an artifact that can be imported directly into the virtual environment for
execution (e.g., via "docker load" or "docker import", or via a download
managed by the virtual environment, e.g., from a Docker registry), or a set of
specifications and data to be used by the virtual environment to recreate such
an artifact (e.g., a Dockerfile, optionally specifying a parent image, and
including any files needed for the creation of the image).  A parent image is a
virtual image used as a basis for constructing a virtual image under
consideration, e.g., with the "FROM" Dockerfile instruction.  The virtual image
under consideration is then considered a "dependent" image.  Virtual images
further up the chain are "ancestor" images.

1. Should publicly distributed Docker images be considered products per the CNA
Rules?

Yes, there is significant utility in doing so, if the affected virtual images
can be identified accurately. For example, virtual images can include code not
distributed by other means.  I believe the following rule would be helpful to
support that activity:

7.1.4 For publicly distributed virtual images to be considered products to
which CVEs can be assigned, the images must have unique identifiers or be
accurately identifiable by a combination of public metadata such as date,
author or name.

2. Should an insecure default configuration (e.g., default password for the
admin user) be considered a vulnerability?

Classic software products have expected use case scenarios where the deployed
product needs to be configured appropriately, depending on how the product will
be used and its environment.  Assignment rule 7.2.5 recognizes that "contract"
when referring to a "secure method of using the functionality or
specification".  It codifies that classic software products are not
ready-to-use as delivered until those "secure methods" are examined and setup
appropriately.  

However, the value of virtual images is typically provided by their
"ready-to-use" quality.  They are usually provided and used with the
understanding that most of the configuration tasks have already been done
appropriately, and that the required configuration will be limited to and
focused on a subset of interest.  The configuration that was done is part of
the product and may indeed be most of the value provided by the virtual image,
with an implied trust that the configuration is secure.  Consequently, the
contract is different from the one applicable to classic software products.
There are widespread use case scenarios where virtual images are trusted to be
configured securely;  the breach of that trust must be considered a
vulnerability.  The fact that there may be ways to change or override
configurations in a virtual image doesn't change the breach.  This would be
different if virtual images were distributed with instructions or warnings
stating that the security-related configuration tasks remain to be done.

Proposed solution:  Modify rules under 7.2.4 and 7.2.5 to take into account the
differences in the trust contracts of classic software products and virtual
images (see below)


3. Should inherited insecure defaults share the same CVE ID?

The rules under 7.2.4 are appropriate for classic software products.  However,
the notion of "what is code" is not useful in the case of virtual images,
because it is irrelevant to the trust contract described in the answer to
question #2.  One could also argue that dependent virtual images are not independent
implementations, and are affected by the same independently fixable vulnerability.  
In their case, what matters is that they share the same parent, instead of sharing
the same code.  However, it has been mentioned that rules based on whether an image
is dependent of another are difficult to implement because this information is not
obvious;  it may be more practical to treat all images with the same flawed content
the same way.

Proposed solution:  modify the rules under 7.2.4 and 7.2.5 so that the notion
of "what is code" does not apply to all CVE assignments.

The rules could be modified like this:

7.2.4 If multiple products are affected by the same independently fixable
vulnerability, then the CNA:

    a. MUST NOT assign more than one CVE ID if the products are affected,
because they share the vulnerable code, or in the case of virtual images,
because they share the same contents that make it vulnerable (including
configurations). The assigned CVE ID will be shared by the affected products.
    b. MUST assign different CVE IDs if the products do not share affected code,
or in the case of virtual images, if they do not share the same content that makes
them vulnerable.
    c. SHOULD assign different CVE IDs if the CNA is uncertain whether the products
share code, or in the case of virtual images, if the CNA is uncertain whether
they share the same content that makes them vulnerable.


7.2.5 If a product is affected by a vulnerability because it uses the
functionality or specification of another product, then a CNA:

    a. MUST assign a CVE ID to each known vulnerable implementation if there is
a secure method of using the functionality or specification, except for virtual images.
    b. MUST assign a single CVE ID if there is no option to use the functionality or
specification in a secure manner.
    c. SHOULD assign different CVE IDs to each known vulnerable codebase if the CNA
is uncertain whether there is a secure option.

Example used in the slides:
CVE-2019-5021 (blank root password)
The affected official Alpine Linux Docker images can be identified uniquely.
There was no CVE for that issue in related virtual images, so creating the CVE
was justified.  According to the above proposed rules, the related CVEs
(CVE-2020-29581, etc, etc...) should not have been issued, and instead the images
should be added to the list of known affected software in the
NVD and other databases, in their description of CVE-2019-5021.

Regards,
Pascal

Reply | Threaded
Open this post in threaded view
|

Re: Docker Image Vulnerabilities: example changes to assignment rules

Art Manion

Thanks Pascal for the for the detailed writeup.  I missed at least one major board discussion on this topic.

On 2021-01-19 10:03, Pascal Meunier wrote:

> 1. Should publicly distributed Docker images be considered products per the CNA
> Rules?

Yes.

> 2. Should an insecure default configuration (e.g., default password for the
> admin user) be considered a vulnerability?

Yes, and I'd argue that the distinction between container and "classic" software is not terribly important -- shipping with insecure defaults should be treated as a vulnerability per CVE.

> 3. Should inherited insecure defaults share the same CVE ID?

Yes, and this brings up a larger concern we've struggled with, which I'll summarize as the lack of formal relationships between CVE IDs.  I'd suggest that 7.2 (in particular some of the "independently fixable" and "same code" language) be discussed and revised.  This discussion I think is fundamentally a question of abstraction, e.g., do CVE IDs apply to "a somewhat abstract vulnerability" or do IDs apply to "literally the exact same block of code."

Just a couple examples of this struggle:

Vendor CNA maps their "child" CVE IDs to the "parent" CVE IDs (table above Recommendations heading):

   https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00295.html

Multiple vulnerabilities, multiple vendors, too much effort to assign CVE IDs per vendor X per vulnerability, arguably the same abstract/conceptual vulnerability but in most cases different code:

   https://vuls.cert.org/confluence/pages/viewpage.action?pageId=56393752

CERT/CC is willing to start a discussion topic at the Feb 3 or 17 board meetings.

Regards,

  - Art