[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)