Christian Heimes added the comment:
The IDNA RFC contains additional rules for wildcard matching ... very well
hidden indead!
http://tools.ietf.org/html/rfc6125#section-6.4.3
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset b9b521efeba3 by Antoine Pitrou in branch '3.2':
Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service
using certificates with many wildcards (CVE-2013-2099).
http://hg.python.org/cpython/rev/b9b521efeba3
New changeset
Antoine Pitrou added the comment:
Ok, this should be fixed now. Thanks a lot for reporting!
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Changes by Bohuslav Slavek Kabrda bkab...@redhat.com:
--
nosy: +bkabrda
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
___
STINNER Victor added the comment:
Are multiple wildcards per fragment even specified?
I don't know the standard, but it sounds strange to have more than one wildcard
per part of an URL. *.*.*.google.com looks valid to me, whereas
*a*a*a*.google.com looks very suspicious.
Said differently, I
Florian Weimer added the comment:
* pattern is replace with '[^.]+' regex, so I may not cause the exponential
complexity issue. (I didn't check.)
A possessive quantifier might also help, that is [^.]+?.
--
___
Python tracker
Marc-Andre Lemburg added the comment:
SSL certificate hostname matching is defined in RFC 2818:
* http://www.ietf.org/rfc/rfc2818.txt
It's not very verbose on how exactly matching should be done:
Names may contain the wildcard
character * which is considered to match any single domain
Antoine Pitrou added the comment:
Non-greedy matching actually makes things worse :-)
$ ./python -m timeit -s import re; pat = re.compile('\A*a*a*a\Z'.replace('*',
'[^.]+'), re.IGNORECASE) pat.match('a' * 100 +'z')
100 loops, best of 3: 3.31 msec per loop
$ ./python -m timeit -s import re;
Antoine Pitrou added the comment:
Florian, I'm actually surprised by your assertion that OpenSSL supports a
single wildcard character. Last I looked, I couldn't find any hostname matching
function in OpenSSL (which is why I had to write our own). Could you point me
to the relevant piece of
Florian Weimer added the comment:
Antoine, support for OpenSSL host name matching is quite new:
http://www.openssl.org/docs/crypto/X509_check_host.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
Antoine Pitrou added the comment:
libcurl supports a single wildcard for the whole domain name pattern (not even
one per fragment), as per lib/hostcheck.c
(this is when linked against OpenSSL; when linked against GnuTLS, curl will use
the GnuTLS-provided matching function)
Based on all the
Antoine Pitrou added the comment:
Antoine, support for OpenSSL host name matching is quite new
Ah, thanks. I was looking in 1.0.1e.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
Marc-Andre Lemburg added the comment:
Here's another long discussions about SSL hostname matching that may provide
some useful insights:
* https://bugzilla.mozilla.org/show_bug.cgi?id=159483
Note how RFC 2595 doesn't even allow sub-string matching. It only allows '*' to
be used as
Antoine Pitrou added the comment:
Attached patch forbidding more than one wildcard per fragment.
--
stage: needs patch - patch review
Added file: http://bugs.python.org/file30292/ssl_wildcard_dos2.patch
___
Python tracker rep...@bugs.python.org
Christian Heimes added the comment:
I still think that sub string wildcard should not match the IDN xn-- prefix.
With current code the rules x*.example.de gives a positive match for
götter.example.de.
ugötter.example.de.encode(idna)
'xn--gtter-jua.example.de'
--
Antoine Pitrou added the comment:
I still think that sub string wildcard should not match the IDN
xn-- prefix. With current code the rules x*.example.de gives a
positive match for götter.example.de.
You should open a separate issue for this (possibly with a patch).
--
Christian Heimes added the comment:
#17997
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
___
Python-bugs-list mailing list
Jan Lieskovsky added the comment:
The CVE identifier of CVE-2013-2099 has been assigned:
http://www.openwall.com/lists/oss-security/2013/05/16/6
to this issue.
--
nosy: +iankko
title: ssl.match_hostname() trips over crafted wildcard names - CVE-2013-2099
ssl.match_hostname() trips
Changes by Antoine Pitrou pit...@free.fr:
--
stage: - needs patch
type: - security
versions: +Python 3.2, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
Antoine Pitrou added the comment:
This is caused by the regex engine's performance behaviour:
http://bugs.python.org/issue1662581
http://bugs.python.org/issue1515829
http://bugs.python.org/issue212521
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
I would like to know what is the expected scenario:
- does the attacker only control the certificate?
- or does the attacker control both the certificate and the hostname being
validated?
The reason is that the matching cost for a domain name fragment seems to
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +christian.heimes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
___
Python-bugs-list
Christian Heimes added the comment:
RFC 2818 doesn't say anything about the maximum amount of wildcards. I'm going
to check OpenSSL's implementation now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
Florian Weimer added the comment:
OpenSSL supports only a single wildcard character.
In my tests, I used a host name like
.example.org, and a dNSName like
a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*.example.org. Quadratic
behavior wouldn't be
Changes by Apostolis Bessas mpes...@gmail.com:
--
nosy: +mpessas
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Indeed, two wildcards seem to be ok with a 255-character domain name:
$ ./python -m timeit -s import ssl; cert = {'subject': ((('commonName',
'*a*a.com'),),)} try: ssl.match_hostname(cert, 'a' * 250 +'z.com') except
ssl.CertificateError: pass
1000 loops, best
Antoine Pitrou added the comment:
In my tests, I used a host name like
.example.org, and a dNSName
like a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*.example.org.
Quadratic behavior wouldn't be too bad because the host name is
necessarily rather
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
Florian Weimer added the comment:
The host name is looked up to get the IP address to connect to. The lookup
will fail if the host name is longer than 255 characters, and the crafted
certificate is never retrieved.
--
___
Python tracker
Christian Heimes added the comment:
I think a malicious user could abuse SNI to craft a longer host name and
trigger the pathological case.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
Antoine Pitrou added the comment:
In GnuTLS, _gnutls_hostname_compare() (lib/gnutls_str.c) uses a trivial
recursive approach with a maximum number of 5 wildcards.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
Changes by Jeffrey C. Jacobs timeho...@users.sourceforge.net:
--
nosy: +timehorse
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
___
Tim Peters added the comment:
Wildcard matching can easily be done in worst-case linear time, but not with
regexps. doctest.py's internal _ellipsis_match() shows one way to do it
(doctest can use ... as a wildcard marker).
--
nosy: +tim_one
___
Christian Heimes added the comment:
We could use an algorithm that doesn't need regexp for most cases.
pseudo code:
value = value.lower()
hostname = hostname.lower()
if '*' not in value:
return value == hostname
vparts = valuesplit(.)
hparts = hostname.split(.)
if len(vparts) !=
Antoine Pitrou added the comment:
Wildcard matching can easily be done in worst-case linear time, but
not with regexps. doctest.py's internal _ellipsis_match() shows one
way to do it (doctest can use ... as a wildcard marker).
Thanks, this may be a nice enhancement for 3.4.
For 3.2 and
Antoine Pitrou added the comment:
Here is a patch allowing at most 2 wildcards per domain fragment. Georg, do you
think this should go into 3.2?
--
keywords: +patch
nosy: +georg.brandl
Added file: http://bugs.python.org/file30288/ssl_wildcard_dos.patch
Georg Brandl added the comment:
It's certainly a security fix, but probably not one that warrants an immediate
release.
If you commit it to the 3.2 branch, that's fine, it will get picked up by
coming releases.
--
___
Python tracker
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
___
Python-bugs-list
Gregory P. Smith added the comment:
Indeed, doing this _without a regexp_ is preferred. :)
--
nosy: +gregory.p.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17980
___
Christian Heimes added the comment:
Are multiple wildcards per fragment even specified? I'm unable to find
information if the wildcard is supposed to be a greedy or a non-greedy match.
By the way Chromium does more fancy checks. For example it requires * to match
at least on character and it
40 matches
Mail list logo
