Live data from Hacker News

Python 3.x: RCE in Python applications that accept floats as untrusted input

cve.mitre.org

11–20 of 72 posts

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#11

Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.

I bet it’d be an even bigger deal at a couple financial services companies if they took security updates to internal codebases seriously.

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#12

Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.

FAANG?

Facebook, Apple, Amazon, Netflix, Google

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#13

Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.

FAANG?

In the early 2000s COBRA reorganized as FAANG in response to changing geopolitical realities.

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#14
post #2

Already fixed in Python 3.6, 3.7, 3.8 and 3.9: https://bugs.python.org/issue42938 3.6.13 and 3.7.10 have already been released with the fix: https://www.python.org/downloads/release/python-3613/ https://www.python.org/downloads/release/python-3710/ The 3.8.8 and 3.9.2 release candidates with the fix will be promoted on Monday March 1st: https://discuss.python.org/t/python-3-9-2rc1-and-3-8-8rc1-ar... If you're on 3.5…

Surely delaying an RCE fix for two weeks on supported versions of Python is a mistake.

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#15
post #5

Earlier quoted context omitted.

I am not sure, but since the files affected in are ctypes, I think it can only affect applications with bindings that are written with ctypes. As far as I know, ALL bindings in CPython are written with the C APIs and not ctypes, including the JSON library. (I can't guarantee that but it shouldn't be that hard to audit.) The official page is not any more clear on this: https://python-security.readthedocs.io/vuln/ctype…

With a quick grep I find this: - `uuid` used ctypes until 3.9 to get information like the IP address (without floats, so it's not vulnerable) - `platform` uses ctypes in 2.7 to get the Windows version (without floats) - `multiprocessing` uses ctypes for interoperability with ctypes That's everything, on the versions I checked. `json` for example uses a native Python module `_json`, so it doesn't use ctypes.

Django's GIS extensions use c_double, that's a large surface area.

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#17
post #2

Already fixed in Python 3.6, 3.7, 3.8 and 3.9: https://bugs.python.org/issue42938 3.6.13 and 3.7.10 have already been released with the fix: https://www.python.org/downloads/release/python-3613/ https://www.python.org/downloads/release/python-3710/ The 3.8.8 and 3.9.2 release candidates with the fix will be promoted on Monday March 1st: https://discuss.python.org/t/python-3-9-2rc1-and-3-8-8rc1-ar... If you're on 3.5…

Surely delaying an RCE fix for two weeks on supported versions of Python is a mistake.

Distros are backporting security patches into their releases, so no harm done. If you rely on the python.org releases and don't build from source, then yes, that is a bit sad.

Case in point: The Debian security tracker, see their notes section referencing each commit.

https://security-tracker.debian.org/tracker/CVE-2021-3177

Re: Python 3.x: RCE in Python applications that accept floats as untrusted input

#19
You would think converting floats to and from strings was a solved problem by now...

I'm surprised noone ever looked at that code --- even when writing it --- and thought "how long can a %f get?" I've been writing C for a long time and that's just something which comes naturally, being ingrained into memory since the beginning. If I see a fixed-size buffer I will always question whether it's big enough (and also if it's perhaps even too big.)

The "psychology" around buffer overflows has always seemed strange to me; a real-world analogy is someone who has no idea how big his car is, finds a parking spot that "looks big enough", and just rams it in without a second thought, sometimes crashing into the surroundings. Not many people would do that in the real world. Yet countless programmers seemingly can't get something simple like this right?

Edit: downvoters, care to state your case?

Post reply on HN