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
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:3466 https://access.redhat.com/errata/RHSA-2024:3466
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:3543 https://access.redhat.com/errata/RHSA-2024:3543
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Via RHSA-2024:3552 https://access.redhat.com/errata/RHSA-2024:3552
This issue has been addressed in the following products: Red Hat Ansible Automation Platform 2.4 for RHEL 9 Red Hat Ansible Automation Platform 2.4 for RHEL 8 Via RHSA-2024:3781 https://access.redhat.com/errata/RHSA-2024:3781
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:3846 https://access.redhat.com/errata/RHSA-2024:3846
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:4260 https://access.redhat.com/errata/RHSA-2024:4260
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extended Lifecycle Support Via RHSA-2024:8365 https://access.redhat.com/errata/RHSA-2024:8365