[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201406131705.s5DH4wkn027926@linus.mitre.org>
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.
