[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150521184650.AFDABB2E2B0@smtpvbsrv1.mitre.org>
Date: Thu, 21 May 2015 14:46:50 -0400 (EDT)
From: cve-assign@...re.org
To: mprpic@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: ssl.match_hostname(): sub string wildcard should not match IDNA prefix
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> https://bugs.python.org/issue17997
> https://hg.python.org/cpython/rev/10d0edadbcdd/
Our perspective on issue17997 is that the "multiple wildcards" issue
can have a CVE ID but the "IDNA prefix" issue probably cannot.
RFC 2818 says "Names may contain the wildcard character * which is
considered to match any single domain name component or component
fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com.
f*.com matches foo.com but not bar.com." It isn't completely clear
whether multiple instances of '*' such as *.*.com were considered
valid. Also, https://bugs.python.org/msg194950 says "For security
reasons matching rules like *.*.com should be not supported." Use
CVE-2013-7440 for this issue.
The IDNA report seems to be about wanting to change the specification
from RFC 2818 to RFC 6125. https://bugs.python.org/msg189454 mentions
that the old behavior 'can result into false positive matches for a
rule like "x*.example.de"' but, in practice, it seems unlikely that
anyone would have a need for rules beginning with x* or xn* or xn-*
(these are essentially the only three cases). It seems more likely
that someone would have created a rule for xn--*.example.de because
they specifically wanted to match all IDNA names but did not want to
match www.example.de (which might be separately administered). In
other words, the IDNA aspect of 10d0edadbcdd doesn't seem to be a
vulnerability fix; it seems to be a policy change that, relative to
existing deployments, sometimes strengthens security and sometimes
weakens security. The policy change (i.e., adopting a more recent RFC)
does, of course, seem appropriate for new deployments. Similarly,
https://bugs.python.org/msg227895 says "I won't apply this for 3.2
since at this point a behavior change might do more harm than good."
In any case, because RFC 2818 was intended when the code was written,
we feel that 'false positive matches for a rule like "x*.example.de"'
is not a vulnerability and should not have a CVE.
- --
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)
iQEcBAEBAgAGBQJVXielAAoJEKllVAevmvmsOiAH/ihqkIzpYITVkDisLMRfcvyz
M3NxEbB2l7PozcWTmupMQ7CSyG6lSPjzB/eBA7sJgzDkPnbJRQu6OD0YHLsQ7H9O
DUMq77w9utEy+KbrMOKaYqu4uRAWY8s7zmRlumqO6nJ8YTMhqbHj+laaVJK/VIon
7Yr83n8H6BLSse67n9khcxmmxyhwPaQRMNVg5Bpk4A3S2E6jpPQUXiSTSreHGwfU
jemrbYn9bPosy0Ga7zl8HUzWVHFkEP1zexXcI3Ruk/lRVqhRlcwOEKXHsz0RpfAx
vrF70GHR3kGg+lPi6DGZGW4rmEkk4shemg/fCy55j7p2YxxDnufIxClaUJmDmoE=
=68Zt
-----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.
