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.