|
(resending a slightly modified version because the email I sent from 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 |