3 ms·

Does this affect standard json parsing libraries?

chubot 6y ago
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-overflow-pycarg_repr.html 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 6y ago
  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.
  - AaronFriel 6y ago
    Django's GIS extensions use c_double, that's a large surface area.
dividuum 6y ago
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/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

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-overflow-pycarg_repr.html 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 6y ago
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.
- AaronFriel 6y ago
  Django's GIS extensions use c_double, that's a large surface area.

dividuum 6y ago

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/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