Date: Fri, 13 Jun 2014 13:04:58 -0400 (EDT) From: cve-assign@...re.org To: d.cauquil@...dream.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: Proxmox VE < 3.2 user enumeration vulnerability -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > We would like to request 1 CVE for this vulnerability. In general, there might be arguments in favor of either 0, 1, or 2 CVEs for this. > https://git.proxmox.com/?p=pve-access-control.git;a=commit;h=6126ab75a0837298427491ea64b9b2e1139c6ba6 The PVE/API2/AccessControl.pm change mentions both: to prevent user enumeration attacks to prevent timing attacks but these don't seem to be independently relevant. The issue is that an attacker could determine that they have discovered a valid username because either: the error message changes (i.e., CWE-204) or the response occurs more slowly (i.e., CWE-208) It seems that there would be hardly any point in fixing the CWE-208 issue unless the CWE-204 issue were also fixed. That may be an argument for combining the two into a single CVE. The more controversial question is whether this type of a CWE-204 instance should continue to have a CVE ID in all future cases. http://cwe.mitre.org/data/definitions/204.html mentions "Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not." However, some authors outside MITRE have recently made an apparently opposite assertion, e.g., "It is time to accept that account existence is something an attacker can easily learn, and gain the usability benefits of telling real people that they've misspelled their account identifier." ("Threat Modeling: Designing for Security," ISBN 978-1-118-80999-0, page 262) In this case, the commit message of "prevent user enumeration attacks" might be considered close enough to a vendor statement that "the Proxmox security policy is that authentication components must have CWE-204 countermeasures, and lack of these countermeasures was an implementation error." - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTmy6PAAoJEKllVAevmvmsFKMH/3jwDJilv21+F5GWYlj9+Jz0 kaQ/4OuW/woZuz719rwaXld/k6cITRsN6f72CJCP/Zeq55cS8Gc8i3Twq5uUVLcA +wUk6r6/Ci2EglShbknLad0DzzqDDSZCWBI1UHxjANFhC8m7cp+qfD16/nnp4Nxk yKJK3BnVsKG3vr/x5iVNQSUf/0mkP56UrVHgNMgwUg77hKFBIYX9gvL9xnAhuZaW Q+Z+9uEEbCOXsItPmnDJdaHYXOsTGt0Fo3JHtthxRpS8gZSkA/lKnjSSQ6+V4jxP JXu+lIiPzj69YJupmMGM4kFibRISX95wO2xe4otOHcwiTD1xwiGWpw6Ex635SMQ= =WyiO -----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.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.