oss-sec mailing list archives
Re: A new class of security vulns?
From: cve-assign () mitre org
Date: Thu, 30 Jul 2015 12:32:33 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
https://fedorahosted.org/freeipa/ticket/5153
assuming there are no actual terminal escape sequences allowed, but just backspace characters/etc
there is an integrity impact (not a very big one mind you)
In this type of situation, the author of the software can choose to characterize the behavior as a vulnerability, based on their viewpoint about what type of "integrity" was intended. In this case, the report says "non-printable characters aren't check in every case of user data" and "need more string checks for non-printable characters." That might mean that character-set restrictions were an intentional protection mechanism, implemented correctly elsewhere in the product, and the author can definitely have a viewpoint that the incomplete protection mechanism requires a CVE ID. If there previously were no character-set restrictions at all, but the author believes that the original design goal was to have the user-entered name directly visible to the admin, then again the author can state that a CVE ID is required, We, of course, discourage anyone from asserting an original design goal when what they are really doing is adding an entirely new security feature. If this type of claim of a vulnerability finding is not originated or confirmed by the author, it becomes difficult to argue that a CVE ID is required. Maybe the product was actually intended to store non-alphabetic names (including the \10\10\10Doe types of names in 5153) in order to support a wide range of personal-identity choices, perhaps even the symbol of The Artist Formerly Known As Prince. - -- 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 iQEcBAEBCAAGBQJVulEMAAoJEKllVAevmvmsSyUH/AkZFfJA+27LdMYdZmtFrPfA oSTJlpN1Q0bSSu9Pzu/L52o7tdfUNFMYmQ1GYuBd85vt7W3am2a3VLo9OaxP8KRa oOas5zVTMO/63LTOP6sV8kTbwBkzoYR/OZc2XDbQNW0G9KAt3YqV7ReP+gHCMAXP QLaUwq84gH88mdbiejdUbDdKIBS5PNW9aqEXVFbTTm3zNUTCMnIRa28uEKFjqyza JlNKrxgxINJ4hvLckgFtdAlhI6WJDtK4Fm2bvK9N9eXoC7jQPWGFZo4pJ4U50HwM 8rvIioJhif7v4Ud/86T3PQzuxCDIGAJfmo3hKOkkeBEg6DvkGhxTFRFVyBqyqCc= =ezM2 -----END PGP SIGNATURE-----
Current thread:
- A new class of security vulns? Kurt Seifried (Jul 30)
- Re: A new class of security vulns? Scott Arciszewski (Jul 30)
- Re: A new class of security vulns? cve-assign (Jul 30)
- Re: A new class of security vulns? Joshua Rogers (Jul 30)