Re: tostring userdata

[David Heiko Kolf <david@...>]

Roberto Ierusalimschy wrote:
>> Is ASLR worth it or just some useless obfuscation we don't need to care
>> about? I can't judge.
> 
> I may be completely wrong here, but as far as I know the main motivation
> for ASLR were attacks like stack overflow in C. As far as I know, in
> C it is trivial (actually a non-op) to take the address of anything:
> functions, data structures, the stack, etc. So, if taking addresses were
> really that big problem, ASLR would be dead before starting.
> 
> The whole idea of ASLR was to avoid knowing addresses *before* being
> able to execute code in the machine. Once you can execute code, things
> get pretty hard.
> 
> For instance, I could agree with a complain that an error message is
> showing a memory address. That is something someone can provoke
> and see from outside, without running its own code in the machine.

To be honest, I don't know of any application where Lua gets executed
like JavaScript in a web browser. So yes, this might be completely academic.

But I assume now there is an application that opens documents and
executes Lua scripts in those documents, expecting that everything is in
a nice sandbox. In this sandbox there is access to a broken userdata.
The userdata has a setvalue function that writes an integer to an array.
Whoever wrote it, missed a bounds check.

Now I am not a security expert. But as far as I understand, without
knowing where the userdata is and where some executable code might be,
an attacker could place code on some random memory position and hope
that it replaced a soon-to-be-called function -- more by chance and
probably the application would rather crash.

But with the address known, the following is possible:

  -- 'weakuserdata' provides access to a 32-bit integer array where
someone forgot bound checking

  targetaddress = tonumber(("%p"):format(print):sub(3), 16)
  openingaddress = tonumber(("%p"):format(weakuserdata):sub(3), 16)
  d = (targetaddress - openingaddress) // 4
  -- The following hex numbers are supposed to resemble machine code
  weakuserdata:setvalue(d + 0, 0xabcdef01)
  weakuserdata:setvalue(d + 1, 0x23456789)
  weakuserdata:setvalue(d + 2, 0xabcdef01)
  -- ...
  print() -- execute our own machine code

But again, I do not know of an application that executes Lua in
documents. And yes, some other bug would already need to exist. But
still I am thankful for those who point out that we need to be careful
around certain functions.

> Attack-resistant sand boxes are hard and tricky (even with hardward
> support!). The string library is particularly problematic, because
> they provide the only functions that can be called even in an empty
> environment, and these functions can greatly ease a DoD attack.  (DoD
> attacks in pure Lua can be stopped by debug hooks, but slow C functions
> do not go through hooks.)  Should we remove string methods too, in favor
> of "better security"?

Of course not, but the functions string.rep and the pattern matching
functions are already known and I would replace them with a
resource-limited edition if I were ever to write software where a Lua
code DoS might be an issue.

Same with the pointer issue, it is quite convenient and I actually
wished myself in the past that I had some kind of "rawtostring". But I
do find it helpful when people mention that there is a trade-off that
especially those who would write sandboxes need to know.

Best regards,

David