A specially crafted argument to the idna.encode() function could consume significant resources. This may lead to a denial-of-service. Reference: https://github.com/kjd/idna/security/advisories/GHSA-jjg7-2v4v-x38h
Created mingw-python-idna tracking bugs for this issue: Affects: fedora-all [bug 2274782] Created python-idna tracking bugs for this issue: Affects: fedora-all [bug 2274780] Created python-idna-ssl tracking bugs for this issue: Affects: epel-8 [bug 2274783] Affects: fedora-all [bug 2274781]
I don't know how to reproduce the issue. Even the changelog of idna does not mention it, the fix seems to be this commit: https://github.com/kjd/idna/commit/5beb28b9dd77912c0dd656d8b0fdba3eb80222e7 I'm able to create something like this: ``` zwnj = '\u200c' latin = '\u0061' idna.encode(latin * 10 + zwnj) ``` With that input, the first for loop in the valid_contextj function runs 10 times (v3.6) instead of just once (v3.7). However, I'm not able to prepare an input where a significant difference between 3.6 and 3.7 would be visible when it comes to consumed resources or processing time. So far, I'm only able to reproduce and verify the issue using cProfiler from Python. The following line: idna.encode(latin * 1000 + zwnj) Produces the following output of cProfiler for idna 3.6: $ python3 -m cProfile -s ncalls poc.py | head 14231 function calls (14181 primitive calls) in 0.005 seconds Ordered by: call count ncalls tottime percall cumtime percall filename:lineno(function) 5007 0.000 0.000 0.000 0.000 {built-in method builtins.ord} 2003 0.000 0.000 0.000 0.000 intranges.py:35(_decode_range) 1096/1095 0.000 0.000 0.000 0.000 {built-in method builtins.len} 1024 0.000 0.000 0.000 0.000 {method 'get' of 'dict' objects} 1002 0.001 0.000 0.001 0.000 intranges.py:39(intranges_contain) and for idna 3.7: $ python3 -m cProfile -s ncalls poc.py | head 9337 function calls (9284 primitive calls) in 0.018 seconds Ordered by: call count ncalls tottime percall cumtime percall filename:lineno(function) 2003 0.000 0.000 0.000 0.000 intranges.py:35(_decode_range) 1096/1095 0.000 0.000 0.000 0.000 {built-in method builtins.len} 1011 0.000 0.000 0.000 0.000 {built-in method builtins.ord} 1002 0.001 0.000 0.001 0.000 intranges.py:39(intranges_contain) 1002 0.000 0.000 0.000 0.000 intranges.py:32(_encode_range) See the difference in the total function calls caused mostly by 5007 calls to ord function in the vulnerable version.
Reproducer has been provided in my issue: https://github.com/kjd/idna/issues/175