[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How does string.format handle undefined behavior?
- From: Philippe Verdy <verdyp@...>
- Date: Sun, 5 Sep 2021 13:32:02 +0200
The Lua implementation should not pass "%#c" from Lua call to string.format() directly to a C *printf() function.
It should parse all "%*" placeholders itself, and should not even need to use any *printf() function and not depend on it. It will reject "%#c" as invalid in Lua format strings (providing its own fallback or error). In such case, there will be no UB at all.
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 <email@example.com>
> 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?