Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.
Python 3.x: RCE in Python applications that accept floats as untrusted input
11–20 of 72 posts
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#12Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#13Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#14Already 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…
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#15Earlier 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.
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#16Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#17Already 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.
Case in point: The Debian security tracker, see their notes section referencing each commit.
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#18Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#19I'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?
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#20Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.