It was thus said that the Great Coda Highland once stated:
> On Fri, Jul 5, 2019 at 6:51 PM Sean Conner <sean@conman.org> wrote:
> If I had a proof of concept of a critical security flaw in Lua, I would be
> submitting a patch for it. The concern isn't about the bugs that the good
> guys can find. It's a practice of defense-in-depth, so that if a heretofore
> unknown bug is discovered then the damage it can deal is limited.
Okay, so was this *ever* brought up about tostring()? Because:
[spc]lucy:/tmp>lua-51
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
> print(print)
function: 0x8ff9020
>
[spc]lucy:/tmp>lua-52
Lua 5.2.4 Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print(print)
function: 0x805c804
>
[spc]lucy:/tmp>lua-53
Lua 5.3.5 Copyright (C) 1994-2018 Lua.org, PUC-Rio
> print(print)
function: 0x805f3f8
>
[spc]lucy:/tmp>lua-54
Lua 5.4.0 Copyright (C) 1994-2019 Lua.org, PUC-Rio
> print(print)
function: 0x8063954
>
[spc]lucy:/tmp>
It goes back a @#%@!#$@#$ long way, and only NOW are people freaking out
about it because string.format() got a "%p" format specifier? I would
expect that if there was an issue about obtaining an address, it would have
shown itself in the past, oh, thirteen years or so. It's not like ASLR
wasn't known back then (hint---it was).
But so far, all I've seen is "OMG! ASLR is VIOLATED! Burn the feature!"
which to me comes across as cargo cult security, of which I seem to be in
the minority. So let's neuter both tostring() and string.format() to save
ASLR!
-spc (And request, nay! Demand! That all modules in C avoid printing an
address as part of the __tostring() metamethod ...)
It had been mentioned before, in passing, but it had never really become a focus of conversation. Then again, security in Lua has rarely been a focus of conversation except for a few discussions about sandboxing.
And the difference has already been pointed out in this thread: most sandboxes exclude print(), and tostring() can be overridden easily, but dealing with string.format isn't quite as simple.
Also, I'm not making any demands. My own use case really doesn't care; I don't have need to run untrusted scripts. I'm making an academic discussion: trying to provide information about the subject at hand so that informed decisions can be made instead of jumping straight on either the "kill it!" or "keep it!" bandwagons. In my personal opinion, the most straightforward solution to this problem would be an option to disable pointer rendering for the cases where it's a problem but leave it enabled by default because it's usually more helpful than hurtful. I wouldn't want to completely remove it because its usefulness in debugging C extensions is far too valuable.
(Also, where do you draw the line between "cargo cult" and "best practices"? Because I've certainly seen you describing the "right" way to do things before.)
/s/ Adam
