Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150730163233.D9D986C0179@smtpvmsrv1.mitre.org>
Date: Thu, 30 Jul 2015 12:32:33 -0400 (EDT)
From: cve-assign@...re.org
To: kseifried@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: A new class of security vulns?

-----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-----

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.