A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int("text"), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.from_bytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability.
## Problem

A Denial Of Service (DoS) issue was identified in CPython because we use binary bignum’s for our `int` implementation. A huge integer will always consume a near-quadratic amount of CPU time in conversion to or from a base 10 (decimal) string with a large number of digits. No efficient algorithm exists to do otherwise.

It is quite common for Python code implementing network protocols and data serialization to do `int(untrusted_string_or_bytes_value)` on input to get a numeric value, without having limited the input length or to do `log("processing thing id %s", unknowingly_huge_integer)` or any similar concept to convert an `int` to a string without first checking its magnitude. (`http`, `json`, `xmlrpc`, `logging`, loading large values into integer via linear-time conversions such as hexadecimal stored in `yaml`, or anything computing larger values based on user controlled inputs… which then wind up attempting to output as decimal later on). All of these can suffer a CPU consuming DoS in the face of untrusted data.

Everyone auditing all existing code for this, adding length guards, and maintaining that practice everywhere is not feasible nor is it what we deem the vast majority of our users want to do.

This issue has been reported to the Python Security Response Team multiple times by a few different people since early 2020, most recently a few weeks ago while I was in the middle of polishing up the PR so it’d be ready before 3.11.0rc2.

## Mitigation
After discussion on the Python Security Response Team mailing list the conclusion was that we needed to limit the size of integer to string conversions for non-linear time conversions (anything not a power-of-2 base) by default. And offer the ability to configure or disable this limit.

The Python Steering Council is aware of this change and accepts it as necessary.


<!-- gh-linked-prs -->
### Linked PRs
* gh-100627
* gh-100628
* gh-101065
* gh-101066
* gh-101630
* gh-101631
<!-- /gh-linked-prs -->

CVE-2020-10735: Prevent DoS by large int<->str conversions
This is a GitHub Issue
repo:cpython
owner:python
Title : CVE-2020-10735: Prevent DoS by large int<->str conversions
Issue date:

--- start body ---
## Problem

A Denial Of Service (DoS) issue was identified in CPython because we use binary bignum’s for our `int` implementation. A huge integer will always consume a near-quadratic amount of CPU time in conversion to or from a base 10 (decimal) string with a large number of digits. No efficient algorithm exists to do otherwise.

It is quite common for Python code implementing network protocols and data serialization to do `int(untrusted_string_or_bytes_value)` on input to get a numeric value, without having limited the input length or to do `log("processing thing id %s", unknowingly_huge_integer)` or any similar concept to convert an `int` to a string without first checking its magnitude. (`http`, `json`, `xmlrpc`, `logging`, loading large values into integer via linear-time conversions such as hexadecimal stored in `yaml`, or anything computing larger values based on user controlled inputs… which then wind up attempting to output as decimal later on). All of these can suffer a CPU consuming DoS in the face of untrusted data.

Everyone auditing all existing code for this, adding length guards, and maintaining that practice everywhere is not feasible nor is it what we deem the vast majority of our users want to do.

This issue has been reported to the Python Security Response Team multiple times by a few different people since early 2020, most recently a few weeks ago while I was in the middle of polishing up the PR so it’d be ready before 3.11.0rc2.

## Mitigation
After discussion on the Python Security Response Team mailing list the conclusion was that we needed to limit the size of integer to string conversions for non-linear time conversions (anything not a power-of-2 base) by default. And offer the ability to configure or disable this limit.

The Python Steering Council is aware of this change and accepts it as necessary.


<!-- gh-linked-prs -->
### Linked PRs
* gh-100627
* gh-100628
* gh-101065
* gh-101066
* gh-101630
* gh-101631
<!-- /gh-linked-prs -->

--- end body ---
