Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cve.mitre.org

Post reply on HN
Print view View original

1–10 of 72 posts

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

#2

Post by di »

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 or lower, these versions are no longer receiving security fixes and will not be patched: https://python-release-cycle.glitch.me/

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

#4

Post by duckerude »

Minimal example:

  >>> import ctypes
  >>> x = ctypes.c_double.from_param(1e300)
  >>> repr(x)
  Segmentation fault
This happens when getting the string representation of a foreign function float. It doesn't affect the standard builtin float type. So it's not extremely common.

But I can imagine this cropping up if you e.g. find a way to cause an exception that formats a value. Or if there's aggressive logging.

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

#5

Post by chubot »

lend000 wrote: post #3

Does this affect standard json parsing libraries?

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/ctypes-buffer-ov...

I use one ctypes binding for convenience (a single function for CommonMark) but I prefer to use C APIs for this reason ... it's a lot of complexity and unsafety. Using ctypes wrong can crash your process due to invoking undefined behavior.

It would be nice to have a list of bindings created with ctypes, since I think most consumers probably have no idea. I thought that PyOpenGL is done with ctypes but don't quote me on that ...

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

#6

Post by duckerude »

chubot wrote: post #5
lend000 wrote: post #3

Does this affect standard json parsing libraries?

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

#7

Post by dividuum »

lend000 wrote: post #3

Does this affect standard json parsing libraries?

No guarantee, but from what I understand the issue is with objects created by ctypes parsing only. I doubt that any json parser would use that:

    >>> import ctypes;x = ctypes.c_double.from_param(1e300);print(type(x))
When repr'd, an sprintf call with a statically sized buffer of 256 bytes is used to produce a string:

   https://github.com/python/cpython/commit/d9b8f138b7df3b455b54653ca59f491b4840d6fa#diff-4e23b3237d0aa08bf4c434d75fab19200a80837bd147051fefccd98b7f2480faL500-L507
With 1e300, the resulting string doesn't fit into 256 bytes, thus overflowing the buffer. Exploitation might be interesting, as you (probably?) can only use numbers (ascii range 0x30-0x39):

    >>> len("%f" % 1e300)
    308

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

#9

Post by mkl100 »

LennyWhiteJr wrote: post #8

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!

Post reply on HN