[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How does string.format handle undefined behavior?
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Sun, 5 Sep 2021 11:50:53 +0200
On 04/09/2021 21:41, Philippe Verdy wrote:
string.format() in Lua does not suffer of any buffer overflow in C/C++
nul-terminated strings with most "*printf"-like functions, and does not
expose any "%p" and pointer- or memory related fields.
It just mimics *some* of its behavior but processes each field with its own
rule and uses safe (and immutable) Lua strings only, with known length and
bound checks of indices everywhere for every operation on strings.
There's no "dragon" left behind.
I didn't examine Lua source, but if a format string that causes UB is
passed to C, then *there are dragons left*.
If I got it right from this thread, specifying something as "%#c" will
end up with C printf (o fprintf) receiving a "%#c" format string, which
is clearly (well, if you know how to dig in the standard) marked as UB
in the standard, as Roberto pointed out and as I provided the reference
to earlier in the thread.
If this is the case, you definitely could have dragons.
Le sam. 4 sept. 2021 à 15:54, Egor Skriptunoff <firstname.lastname@example.org>
a écrit :
On Fri, Aug 27, 2021 at 10:31 PM Lorenzo Donati wrote:
UB is just dragons waiting to wreak havoc
on your machine.
How dangerous are string.format() dragons?
Should string.format() be inaccessible to untrusted Lua code?
Or, maybe Lua protects safely from the main threat (buffer overflow),
and all other dragons are small and acceptable?