51–60 of 72 posts
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.
Earlier quoted context omitted.
“You would think converting floats to and from strings was a solved problem by now” It is, but it is an extremely difficult problem. I think “How to print floating-point numbers accurately” ( https://dl.acm.org/doi/10.1145/93548.93559 ) was the first correct implementation. That is from 1990 and, according to its authors “was almost 20 years in the making” ( http://kurtstephens.com/files/p372-steele.pdf ) (Faster ver…
...or at least knowing how long the result would be?
I think it is unfortunately that %f, the easiest to remember type field for floating point number, is used for this behavior. Most of the time, you’ll want to use %g, which uses scientific notation if it is shorter.
I guess linters should warn about bare %f without length fields.
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.
Extremely misleading title. This only affects code that puts untrusted floats into ctypes. An relatively very uncommon case. Please stop the clickbait!
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.
FWIW this also crashes Python 2.7 on macOS Catalina.
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.
>>> repr(x)
""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.
FWIW this also crashes Python 2.7 on macOS Catalina.
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.
Only issue is that the default string type requires heap allocations