Date: Mon, 13 Feb 2017 15:47:23 +0000 From: "Radzykewycz, T (Radzy)" <radzy@...driver.com> To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com> CC: "cve-assign@...re.org" <cve-assign@...re.org> Subject: RE: [security-vendor] Re: MITRE is adding data intake to its CVE ID process > C6. I want MITRE to send the https://cveform.mitre.org form data > to the oss-security list as soon as that data is entered (i.e., > before a CVE ID exists). This was one of the thoughts I had originally, but I decided against actually proposing it. (See below.) > R6. We have had internal discussions within MITRE about this. We > are not yet able to implement this easily. We may work on this if > the community requires this approach. However, our understanding > of CVE consumers is that they look to MITRE as a source of > vulnerability information after a CVE ID number exists, not before. Without commenting about the possible difficulty to implement this, it might make sense to have this under the control of the reporter: Add a check button for the requestor to send the contents automatically. (Note that if the check button is not checked, then the sender can send the data manually if they wish. So no need to consider any "what if they change their mind" type of question.) I suppose that one difficulty would be for the message to be sent apparently from the reporter's email address. Not doing this might be a way to subvert some email restrictions, which might be considered improper. So I suspect that this would actually require an email confirmation ("follow this link to have the message sent to the list"). But if that is required, then it's probably almost as easy to simply send a confirmation email to the reporter, which includes a brief comment about forwarding to the list. So on consideration, I suspect it would be best not to do this. I don't think that a "proper" implementation would actually save the reporter significant time/effort. Enjoy! -- radzy ________________________________________ From: cve-assign@...re.org [cve-assign@...re.org] Sent: Friday, February 10, 2017 7:59 PM To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: [security-vendor] [oss-security] Re: MITRE is adding data intake to its CVE ID process -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Thanks to all who have provided constructive and meaningful feedback on this change up to this point. This reply will hopefully answer all of the concerns so far. We are hearing 11 distinct concerns, listed below as C1 through C11, along with our responses of R1 through R11. If you have any ideas or suggestions for improvements to the CVE web form, we are completely open to this. C1. What exactly has changed after MITRE's 2017-02-09 announcement? R1. There are two changes. Each of the two changes is about the case where an oss-security participant is immediately ready to make a public disclosure, and wants an accompanying CVE ID. First, the person must visit https://cveform.mitre.org to make the CVE request (but can also send the vulnerability information to oss-security at the same time). Second, we would like a vulnerability description (i.e., a sentence or two about the product name, affected versions, problem type, impact, and attack methodology) so that we can publish the CVE on https://cve.mitre.org much more quickly. We recognize that, in a fraction of the cases (e.g., unanalyzed fuzzer results), a description would have very limited information. C2. Can I still obtain a CVE ID if I'm not yet willing to disclose what the vulnerability is, and cannot offer any public reference URL? R2. Yes, simply visit https://cveform.mitre.org and leave the "Reference(s)" box blank. Alternatively, you can enter a reference URL, and use the "Additional information" box to clarify that neither the reference nor the CVE should be public yet. This is not a change to how the oss-security list has be used. The oss-security list has always been about only public vulnerabilities. C3. MITRE currently has documentation such as https://cve.mitre.org/cve/request_id.html that recommends contacting DWF if an Open Source product does not appear on a certain list. R3. In all cases where our documentation suggests contacting DWF, please use https://cveform.mitre.org instead at this time. DWF is currently ramping up their operations. CVE is covering all Open Source software. There is no list that is excluding anything. C4. I have historically obtained CVE IDs from the CNA of a specific Linux distribution (e.g., Debian, Ubuntu, or Red Hat) and they are still willing to provide CVE IDs to me. May I continue? R4. Yes. C5. I want MITRE to send the https://cveform.mitre.org form data, and the CVE ID, to the oss-security list at the same time that these are sent to the requester. R5. We have had internal discussions within MITRE about this. We are able to implement this easily if the community requires this approach. At the moment, we are expecting the requester to resend this information to oss-security once they accept their CVE ID assignment. Please see http://www.openwall.com/lists/oss-security/2017/02/09/26 for an example. C6. I want MITRE to send the https://cveform.mitre.org form data to the oss-security list as soon as that data is entered (i.e., before a CVE ID exists). R6. We have had internal discussions within MITRE about this. We are not yet able to implement this easily. We may work on this if the community requires this approach. However, our understanding of CVE consumers is that they look to MITRE as a source of vulnerability information after a CVE ID number exists, not before. C7. When using the https://cveform.mitre.org site, it is unclear what a "vendor" is, e.g., must it be the name of a Linux distribution? R7. The vendor is the name of the upstream project or organization that maintains the Open Source software. If there isn't any project name or organization name, then the name of the software can be used as the vendor name. C8. A CAPTCHA makes it difficult to do high-volume vulnerability reporting. R8. We agree. The https://cveform.mitre.org use case is persons with low-volume reporting needs. We will announce other solutions for high-volume reporting. You can contact us, using the https://cveform.mitre.org "request type: Other" option, if you need a high-volume workaround now. C9. I want to obtain CVE IDs faster in the future. Is there a plan for that? R9. Yes, we anticipate that, in the future, hundreds of Open Source projects will become CNAs for their own vulnerabilities. This will be coordinated under DWF. In other words, an individual Open Source project will have a "sub-CNA" role. The initial documentation is on the https://github.com/distributedweaknessfiling/DWF-Documentation/blob/master/README.md web page. C10. I do not want to use Google docs. Is there any other option? R10. First, Google docs is applicable only to DWF, which is currently ramping up their operations, and is not a required entity for any CVE ID requests at present. Also, we do not expect that Google docs will be applicable to persons or organizations with a higher level of DWF participation, such as sub-CNA participation. At the higher levels, DWF currently uses GitHub, not Google docs. C11. The https://cveform.mitre.org X.509 certificate chain is incomplete. R11. Yes, we realize this and will be adding the missing item (Entrust Certification Authority - L1K) soon. Regards, - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJYnolXAAoJEHb/MwWLVhi25U8P/iFmLFMukKWRgurASnqee1IR hQTaRfu+KPn3yDPe7/PDhnGSirPJQoZ85GS954ac7/xTCmS/fnbRVIqCIsr8WhVe OpwAYHY2XyLKRCPslv7yMhXIOdK1mf9xak51A19nWgiDxxCToUOcJvxC9Gq0dmez +MhXDLfo2yy+LSsw1BNJhxVFqeI6Xpr007aIzedvUUXa4Q8oD1ifkSaVKFI0JONQ sbRpBBc4UJ2OyYcrj4nVDiH2/wHo1YzTFP09YwMXIL9cZuNUqX1ZXj5RDFfIFf4E FUUq4DU938TFJXl30YxIlYWu98physJ2MBtHIqXHaN6Q0RZQlv8esuLSfnN00Y2t j+Ki5biol4Eff8Zt+LGHdkpZj7JZHei6IDWsPVaaLdPWYwsR5MiZO2F/fm0Fb8zv ORbZHtCwnjl26OGqh08W/jxHKfoGPlruZHNHMHiYh84YOhMhjrtY4M/U6lxVB/rC 6q2PleMmh6/jfBWCQgM3N+c1luwXwY6MEdkEbt9U+X6fxXNQlNy8S5EbEPzx1U4J 4TTyWat4JsW/AKwAAjcI7R1qBPqkNvVEoKeKqIRpHKOnfKcqhtUTrq92KozNiVbH uKnsvuaxVWtjCc30onR0PUbi7ENeJZfVTQlAtBl3TN2Ku9ReASP/23KjTk4jnCZA Da1WB50SGz0ynSMY/fBZ =GKwE -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ