Live data from Hacker News

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

cve.mitre.org

41–50 of 72 posts

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

#41
post #30

This 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, the…

> Anyway surely this has been carefully audited, since grepping for sprintf is so simple!

That is rarely a safe assumption.

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

#43

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 i…

Didn't downvote, but I agree, nobody wants to work on the low level stacks anymore, not as sexy as CRUD apps.

I would have expected this issue to be a solved problem too, and now we get extremely insecure Python 3 codebases as a result of this vuln.

So much for moving from Python 2 to 3, will now wait for Python 4.

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

#44
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.

The release candidates are already available to use if you don't want to wait 2 weeks.

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

#45
post #9

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

The "elite" engineers are using ctypes in production? ctypes has never been considered even remotely secure, it can call any library function, including, drumroll, sprintf!

There's hints elsewhere it's Amazon.

Their build system is interesting. One of the quirks is you define your application, and every library/package that you depend on. They don't depend on system libraries for their application code. The idea is to get as consistent an operating environment where possible. It's both generally amazing, and an absolute pain in the arse (usually when you least want it to be, because some upstream package changed their dependencies and you end up with version conflicts to unpick).

When Heartbleed came out, the patches landed in the Amazon build system for the OpenSSL package something like midnight. By the time I got in to the office in the morning, almost every service had been fully rebuilt with patches, and services that do CI/CD had already had the patches deployed. Services that didn't have CI/CD were already kicking off deployments of their front end fleets. IIRC they were paging teams when relevant packages were complete to make sure deployments got kicked off ASAP.

So in this case, someone will have patched Python packages for relevant versions, built an updated version, and everything that depends on it will have immediately recompiled, and from there all the packages that depend on those, and so on down the line. Given how python is used a lot for operations etc. I wouldn't be surprised to find a significant chunk of Amazon got rebuilt today, even in cases where Python wasn't being exposed to external users, or even used by the service directly. That's a lot of components, and probably left zero capacity left for anything unrelated, and no doubt there will be quibbles about the ordering in which things got built.

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

#48

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.

If the float is part of an error message or logging message, the attacker may control portions of the string that appear after the float. This would let them inject a much larger range of bytes, perhaps even UTF-8.

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

#49
post #16

Are Flask/Django APIs that take floats as parameters vulnerable to this under any circumstances? Any POC code that can be used for testing?

If it eventually (or a transitive dependency) passes it to the ctypes module.

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

#50

We need to delete 'sprintf' forever.

Deleting sprintf by itself wouldn't work, even the "safe" replacement functions rely on the developer providing the safety information manually. C needs a string type. Sadly large parts of the C standard are build around turning plain character arrays into exploits by pretending that they are a sane choice for string manipulation.
Post reply on HN