An issue was discovered in Python before 3.11.1. An unnecessary quadratic algorithm exists in one path when processing some inputs to the IDNA (RFC 3490) decoder, such that a crafted, unreasonably long name being presented to the decoder could lead to a CPU denial of service. Hostnames are often supplied by remote servers that could be controlled by a malicious actor; in such a scenario, they could trigger excessive CPU consumption on the client attempting to make use of an attacker-supplied supposed hostname. For example, the attack payload could be placed in the Location header of an HTTP response with status code 302. A fix is planned in 3.11.1, 3.10.9, 3.9.16, 3.8.16, and 3.7.16.
cpe:2.3:a:python:python:*:*:*:*:*:*:*:*
20A23D09-CFA7-4028-A5E9-7AD784C2B9D8
3.7.15
cpe:2.3:a:python:python:*:*:*:*:*:*:*:*
9E43ADF1-EABE-45A4-96BE-F1E018ADAEE3
3.8.15
3.8.0
cpe:2.3:a:python:python:*:*:*:*:*:*:*:*
0FB09E1E-A9D2-494E-9481-1BBA00D3CFEC
3.9.15
3.9.0
cpe:2.3:a:python:python:*:*:*:*:*:*:*:*
2415C537-F33F-496E-BD1C-65887C29FA0B
3.10.8
3.10.0
cpe:2.3:a:python:python:3.11.0:-:*:*:*:*:*:*
E533460B-E5D6-4C30-A36B-15E2DDF4121C
cpe:2.3:a:python:python:3.11.0:alpha1:*:*:*:*:*:*
514A577E-5E60-40BA-ABD0-A8C5EB28BD90
cpe:2.3:a:python:python:3.11.0:alpha2:*:*:*:*:*:*
83B71795-9C81-4E5F-967C-C11808F24B05
cpe:2.3:a:python:python:3.11.0:alpha3:*:*:*:*:*:*
3F6F71F3-299E-4A4B-ADD1-EAD5A1D433E2
cpe:2.3:a:python:python:3.11.0:alpha4:*:*:*:*:*:*
D9BBF4E9-EA54-41B5-948E-8E3D2660B7EF
cpe:2.3:a:python:python:3.11.0:alpha5:*:*:*:*:*:*
AEBFDCE7-81D4-4741-BB88-12C704515F5C
cpe:2.3:a:python:python:3.11.0:alpha6:*:*:*:*:*:*
156EB4C2-EFB7-4CEB-804D-93DB62992A63
cpe:2.3:a:python:python:3.11.0:alpha7:*:*:*:*:*:*
8CC972AE-16A8-4B74-A3E7-36BCDD7C1ED3
cpe:2.3:a:python:python:3.11.0:beta1:*:*:*:*:*:*
554015CB-0325-438B-8C11-0F85F54ABC50
cpe:2.3:a:python:python:3.11.0:beta2:*:*:*:*:*:*
8037C129-0030-455E-A359-98E14D1498D4
cpe:2.3:a:python:python:3.11.0:beta3:*:*:*:*:*:*
7C3DC43B-72CC-4FC5-8072-F051FB47F6D1
cpe:2.3:a:python:python:3.11.0:beta4:*:*:*:*:*:*
6657ED60-908B-48E6-B95B-572E57CFBB69
cpe:2.3:a:python:python:3.11.0:beta5:*:*:*:*:*:*
1EF628A1-82F5-403C-B527-388C13507CDF
cpe:2.3:a:python:python:3.11.0:rc1:*:*:*:*:*:*
3055A198-13F8-42C0-8FD7-316AA8984A8A
cpe:2.3:a:python:python:3.11.0:rc2:*:*:*:*:*:*
03591292-46A3-4F6C-9DC6-4C7BFC4C8743
OR
cpe:2.3:o:fedoraproject:fedora:35:*:*:*:*:*:*:*
80E516C0-98A4-4ADE-B69F-66A772E2BAAA
cpe:2.3:o:fedoraproject:fedora:36:*:*:*:*:*:*:*
5C675112-476C-4D7C-BCB9-A2FB2D0BC9FD
cpe:2.3:o:fedoraproject:fedora:37:*:*:*:*:*:*:*
E30D0E6F-4AE8-4284-8716-991DFA48CC5D
OR
cpe:2.3:a:netapp:active_iq_unified_manager:-:*:*:*:*:vmware_vsphere:*:*
3A756737-1CC4-42C2-A4DF-E1C893B4E2D5
cpe:2.3:a:netapp:active_iq_unified_manager:-:*:*:*:*:windows:*:*
B55E8D50-99B4-47EC-86F9-699B67D473CE
cpe:2.3:a:netapp:e-series_performance_analyzer:-:*:*:*:*:*:*:*
24B8DB06-590A-4008-B0AB-FCD1401C77C6
cpe:2.3:a:netapp:element_software:-:*:*:*:*:*:*:*
85DF4B3F-4BBC-42B7-B729-096934523D63
cpe:2.3:a:netapp:hci:-:*:*:*:*:*:*:*
8A6E548F-62E9-40CB-85DA-FDAA0F0096C6
cpe:2.3:a:netapp:management_services_for_element_software:-:*:*:*:*:*:*:*
86B51137-28D9-41F2-AFA2-3CC22B4954D1
cpe:2.3:a:netapp:ontap_select_deploy_administration_utility:-:*:*:*:*:*:*:*
E7CF3019-975D-40BB-A8A4-894E62BD3797
OR
cpe:2.3:o:netapp:bootstrap_os:-:*:*:*:*:*:*:*
95BA156C-C977-4F0C-8DFB-3FAE9CC8C02D
OR
cpe:2.3:h:netapp:hci_compute_node:-:*:*:*:*:*:*:*
AD7447BC-F315-4298-A822-549942FC118B
OR
AND
# Bug report

Originally reported to the security address on September 9.

```python
('xn--016c'+'a'*5000).encode('utf-8').decode('idna')
```

The execution time is not linear in relation to the input string size, which can cause slowness with large inputs:

10 chars = 0.016 seconds
100 chars = 0.047 seconds
1000 chars = 2.883 seconds
2500 chars = 17.724 seconds
5000 chars = 1 min 10 seconds

Comment by @tiran:

> According to spec https://unicode.org/reports/tr46/ an IDNA label must not be longer than 63 characters. Python's idna module enforces the restriction, but too late.

This may be abused in some cases, for example by passing a crafted host name to `asyncio create_connection`:

```python
import asyncio

async def main():
    loop = asyncio.get_running_loop()

    await loop.create_connection(
        lambda: [], ('xn--016c'+'a'*5000).encode('utf-8'), 443
    )

asyncio.run(main())
```

# Your environment

- CPython versions tested on: CPython repository 'main' branch checkout, version 3.8.12, version 2.7.18
- Operating system and architecture: Ubuntu Linux x64

<!-- gh-pr-number: gh-99092 -->
* PR: gh-99092
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99222 -->
* PR: gh-99222
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99229 -->
* PR: gh-99229
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99230 -->
* PR: gh-99230
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99231 -->
* PR: gh-99231
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99232 -->
* PR: gh-99232
<!-- /gh-pr-number -->

Slow IDNA decoding with large strings [CVE-2022-45061]
This is a GitHub Issue
repo:cpython
owner:python
Title : Slow IDNA decoding with large strings [CVE-2022-45061]
Issue date:

--- start body ---
# Bug report

Originally reported to the security address on September 9.

```python
('xn--016c'+'a'*5000).encode('utf-8').decode('idna')
```

The execution time is not linear in relation to the input string size, which can cause slowness with large inputs:

10 chars = 0.016 seconds
100 chars = 0.047 seconds
1000 chars = 2.883 seconds
2500 chars = 17.724 seconds
5000 chars = 1 min 10 seconds

Comment by @tiran:

> According to spec https://unicode.org/reports/tr46/ an IDNA label must not be longer than 63 characters. Python's idna module enforces the restriction, but too late.

This may be abused in some cases, for example by passing a crafted host name to `asyncio create_connection`:

```python
import asyncio

async def main():
    loop = asyncio.get_running_loop()

    await loop.create_connection(
        lambda: [], ('xn--016c'+'a'*5000).encode('utf-8'), 443
    )

asyncio.run(main())
```

# Your environment

- CPython versions tested on: CPython repository 'main' branch checkout, version 3.8.12, version 2.7.18
- Operating system and architecture: Ubuntu Linux x64

<!-- gh-pr-number: gh-99092 -->
* PR: gh-99092
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99222 -->
* PR: gh-99222
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99229 -->
* PR: gh-99229
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99230 -->
* PR: gh-99230
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99231 -->
* PR: gh-99231
<!-- /gh-pr-number -->


<!-- gh-pr-number: gh-99232 -->
* PR: gh-99232
<!-- /gh-pr-number -->

--- end body ---

comments :
--- start comments ---

--- end comments ---