Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.9] gh-95778: CVE-2020-10735: Prevent DoS by very large int() #96502

Merged
merged 15 commits into from Sep 5, 2022

Conversation

gpshead
Copy link
Member

@gpshead gpshead commented Sep 2, 2022

Integer to and from text conversions via CPython's bignum int type is not safe against denial of service attacks due to malicious input. Very large input strings with hundred thousands of digits can consume several CPU seconds.

This PR comes fresh from a pile of work done in our private PSRT security response team repo.

This backports #96499 aka 511ca94

Signed-off-by: Christian Heimes [Red Hat] christian@python.org
Tons-of-polishing-up-by: Gregory P. Smith [Google] greg@krypto.org
Reviews via the private PSRT repo via many others (see the NEWS entry in the PR).

I wrote up a one pager for the release managers.

@tiran tiran added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Sep 2, 2022
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @tiran for commit 3e7eb9c 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Sep 2, 2022
@gpshead gpshead marked this pull request as ready for review September 2, 2022 16:52
@gpshead
Copy link
Member Author

gpshead commented Sep 2, 2022

I've been using the opening message text for the PR as the commit message when merging. The automatic one is gross.

@gpshead gpshead removed their assignment Sep 2, 2022
@gpshead
Copy link
Member Author

gpshead commented Sep 4, 2022

wait for #96537 to be integrated into this PR before merging, i'll remove the do-not-merge label then.

gpshead and others added 4 commits September 3, 2022 23:17
Per mdickinson@'s comment on the main branch PR.
…#96537)

Converting a large enough `int` to a decimal string raises `ValueError` as expected. However, the raise comes _after_ the quadratic-time base-conversion algorithm has run to completion. For effective DOS prevention, we need some kind of check before entering the quadratic-time loop. Oops! =)

The quick fix: essentially we catch _most_ values that exceed the threshold up front. Those that slip through will still be on the small side (read: sufficiently fast), and will get caught by the existing check so that the limit remains exact.

The justification for the current check. The C code check is:
```c
max_str_digits / (3 * PyLong_SHIFT) <= (size_a - 11) / 10
```

In GitHub markdown math-speak, writing $M$ for `max_str_digits`, $L$ for `PyLong_SHIFT` and $s$ for `size_a`, that check is:
$$\left\lfloor\frac{M}{3L}\right\rfloor \le \left\lfloor\frac{s - 11}{10}\right\rfloor$$

From this it follows that
$$\frac{M}{3L} < \frac{s-1}{10}$$
hence that
$$\frac{L(s-1)}{M} > \frac{10}{3} > \log_2(10).$$
So
$$2^{L(s-1)} > 10^M.$$
But our input integer $a$ satisfies $|a| \ge 2^{L(s-1)}$, so $|a|$ is larger than $10^M$. This shows that we don't accidentally capture anything _below_ the intended limit in the check.

<!-- gh-issue-number: pythongh-95778 -->
* Issue: pythongh-95778
<!-- /gh-issue-number -->

Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
@gpshead gpshead added 🔨 test-with-buildbots Test PR w/ buildbots; report in status section and removed DO-NOT-MERGE labels Sep 4, 2022
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @gpshead for commit a1247fd 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Sep 4, 2022
@ambv
Copy link
Contributor

ambv commented Sep 5, 2022

@tiran can wasm32 failures be ignored here? This is a 3.9 backport and that version is not supported on WASM?

Those fail to build with errors like FileNotFoundError: [Errno 2] No such file or directory: b'../../Tools/wasm/wasi-env', configure: error: cross build not supported for wasm32-unknown-emscripten, and emconfigure: error: (...) failed (returned 1).

@ambv
Copy link
Contributor

ambv commented Sep 5, 2022

The FeeBSD Shared PR failure is unrelated. It's an openssl test failure due to trying to use a protocol that is not supported on the machine:

ValueError: invalid or unsupported protocol version

In GH-95312 we did backport test changes that were supposed to fix this but apparently not. This is to be followed up separately.

@ambv ambv merged commit cec1e9d into python:3.9 Sep 5, 2022
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 FreeBSD Shared 3.9 has failed when building commit cec1e9d.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/151/builds/591) and take a look at the build logs.
  4. Check if the failure is related to this commit (cec1e9d) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/151/builds/591

Failed tests:

  • test_ssl

Failed subtests:

  • test__create_stdlib_context - test.test_ssl.ContextTests
  • test_session_stats - test.test_ssl.ContextTests
  • test_protocol - test.test_ssl.ContextTests

Summary of the results of the build (if available):

== Tests result: FAILURE then FAILURE ==

406 tests OK.

10 slowest tests:

  • test_tokenize: 8 min 37 sec
  • test_multiprocessing_spawn: 7 min 23 sec
  • test_lib2to3: 6 min 28 sec
  • test_gdb: 5 min 21 sec
  • test_multiprocessing_forkserver: 4 min 50 sec
  • test_concurrent_futures: 4 min 30 sec
  • test_unparse: 4 min 10 sec
  • test_asyncio: 3 min 49 sec
  • test_capi: 3 min 12 sec
  • test_pickle: 3 min 7 sec

1 test failed:
test_ssl

18 tests skipped:
test_dbm_gnu test_devpoll test_epoll test_idle test_ioctl
test_msilib test_spwd test_startfile test_tcl test_tix test_tk
test_ttk_guionly test_ttk_textonly test_turtle test_winconsoleio
test_winreg test_winsound test_zipfile64

1 re-run test:
test_ssl

Total duration: 33 min 15 sec

Click to see traceback logs
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 1718, in test__create_stdlib_context
    ctx = ssl._create_stdlib_context(ssl.PROTOCOL_TLSv1,
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/ssl.py", line 776, in _create_unverified_context
    context = SSLContext(protocol)
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/ssl.py", line 484, in __new__
    self = _SSLContext.__new__(cls, protocol)
ValueError: invalid or unsupported protocol version


Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 1144, in test_protocol
    ctx = ssl.SSLContext(proto)
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/ssl.py", line 484, in __new__
    self = _SSLContext.__new__(cls, protocol)
ValueError: invalid or unsupported protocol version


Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 1527, in test_session_stats
    ctx = ssl.SSLContext(proto)
  File "/usr/home/buildbot/python/3.9.koobs-freebsd-564d/build/Lib/ssl.py", line 484, in __new__
    self = _SSLContext.__new__(cls, protocol)
ValueError: invalid or unsupported protocol version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants