I'd be extremely impressed if someone actually managed to get RCE out of this, considering you'd only be able to use '0' through '9', or 0x30 through 0x39, in your payload.
Python 3.x: RCE in Python applications that accept floats as untrusted input
21–30 of 72 posts
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#22You 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 i…
“You would think converting floats to and from strings was a solved problem by now”
It is, but it is an extremely difficult problem. I think “How to print floating-point numbers accurately” (https://dl.acm.org/doi/10.1145/93548.93559) was the first correct implementation. That is from 1990 and, according to its authors “was almost 20 years in the making” (http://kurtstephens.com/files/p372-steele.pdf)
(Faster versions have since been published)
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#23I'd be extremely impressed if someone actually managed to get RCE out of this, considering you'd only be able to use '0' through '9', or 0x30 through 0x39, in your payload.
Perhaps . too?
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#24Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#25Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#26Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#27Remediation for this vulnerability basically caused complete gridlock for the internal tools at a certain FAANG company today.
hahha, I happen to be working on this at said faang...
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#28You 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 i…
“You would think converting floats to and from strings was a solved problem by now” It is, but it is an extremely difficult problem. I think “How to print floating-point numbers accurately” ( https://dl.acm.org/doi/10.1145/93548.93559 ) was the first correct implementation. That is from 1990 and, according to its authors “was almost 20 years in the making” ( http://kurtstephens.com/files/p372-steele.pdf ) (Faster ver…
...or at least knowing how long the result would be?
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#29Earlier quoted context omitted.
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
The python:3.8 and python:3.9 container images if used to build web services such as Django with GIS extensions may have an RCE until Python.org sources are updated.
Re: Python 3.x: RCE in Python applications that accept floats as untrusted input
#30This inspired me to grep the cpython code for sprintf.
I found one used with the return value from alloca (inside FindAddress in _ctypes.c). It checks alloca for NULL (does alloca ever return NULL?), but I could imagine it might expoitable. FindAddress is a static function that can be called during DLL loading. I imagine that there is very little code that accepts untrusted arguments to DLL loading though (if so, there are bigger problems...).
There is also a lot of use of fixed 32-byte buffers, for up-to-64 bit numbers, which is fine, but hopefully if in the future they can be 128-bit, people remember to fix it!
In other cases, like getnameinfo, the stack-allocated buffer is way too large! %d can never be 512 bytes, so it's just thrashing your cache for no reason.
Anyway surely this has been carefully audited, since grepping for sprintf is so simple!