[HN Gopher] Python 3.x: RCE in Python applications that accept f... ___________________________________________________________________ Python 3.x: RCE in Python applications that accept floats as untrusted input Author : bitshifta Score : 46 points Date : 2021-02-18 20:25 UTC (2 hours ago) (HTM) web link (cve.mitre.org) (TXT) w3m dump (cve.mitre.org) | duckerude wrote: | 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. | di wrote: | 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/ | lend000 wrote: | Does this affect standard json parsing libraries? | dividuum wrote: | 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)) <class | 'CArgObject'> | | 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/d9b8f138b7df3b455b54653ca59f4 | 91b4840d6fa#diff-4e23b3237d0aa08bf4c434d75fab19200a80837bd14705 | 1fefccd98b7f2480faL500-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 | chubot wrote: | 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 ... | duckerude wrote: | 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 | | `json` for example uses a native Python module `_json`, so it | doesn't use ctypes. ___________________________________________________________________ (page generated 2021-02-18 23:00 UTC)