The security of function load

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

The security of function load

Yongheng Chen

The function load accepts a binary chunk as argument. I wonder if is it memory-safe against malformed binary chunks? I couldn’t find related materials about it.

 

Best,

Yongheng Chen

 

Reply | Threaded
Open this post in threaded view
|

Re: The security of function load

Rena
On Wed, Sep 23, 2020 at 4:24 PM Yongheng Chen <[hidden email]> wrote:

>
> The function load accepts a binary chunk as argument. I wonder if is it memory-safe against malformed binary chunks? I couldn’t find related materials about it.
>
>
>
> Best,
>
> Yongheng Chen
>
>

It is not. Previous efforts to harden it against such attacks proved
more work than it was worth. You can prevent loading binary chunks
entirely, but in general you must trust the code being loaded.

--
Sent from my Game Boy.
Reply | Threaded
Open this post in threaded view
|

RE: The security of function load

Yongheng Chen

So if the load function causes memory corruption, it is not considered as bugs?

 

Best,

Yongheng Chen

 

From: [hidden email]
Sent: Wednesday, September 23, 2020 5:11 PM
To: [hidden email]
Subject: Re: The security of function load

 

On Wed, Sep 23, 2020 at 4:24 PM Yongheng Chen <[hidden email]> wrote:

> 

> The function load accepts a binary chunk as argument. I wonder if is it memory-safe against malformed binary chunks? I couldn’t find related materials about it.

> 

> 

> 

> Best,

> 

> Yongheng Chen

> 

> 

 

It is not. Previous efforts to harden it against such attacks proved

more work than it was worth. You can prevent loading binary chunks

entirely, but in general you must trust the code being loaded.

 

--

Sent from my Game Boy.

 

Reply | Threaded
Open this post in threaded view
|

Re: The security of function load

云风 Cloud Wu
Yongheng Chen <[hidden email]> 于2020年9月24日周四 上午5:15写道:
>
> So if the load function causes memory corruption, it is not considered as bugs?
>

http://www.lua.org/manual/5.4/manual.html#pdf-load

Lua does not check the consistency of binary chunks. Maliciously
crafted binary chunks can crash the interpreter.

http://lua-users.org/lists/lua-l/2020-08/msg00223.html (said by lhf)

Loading malformed bytecode should not crash Lua.
Running maliciously crafted bytecode can crash the interpreter.
Reply | Threaded
Open this post in threaded view
|

Re: The security of function load (+ some remarks on fuzzing)

nobody
In reply to this post by Rena
On 23/09/2020 23.11, Rena wrote:
> You can prevent loading binary chunks entirely, but in general you
> must trust the code being loaded.

Specifically, you set the `mode` string to "t" instead of "bt".

Note that several variants of the load* functions just don't take the
mode argument and default it to NULL (effectively "bt"), which is fine
for manually written code (just avoid these variants and use the
explicit versions) but - depending on how you do it - may be
inconvenient for fuzzing or exhaustive path analysis etc.…

For that purpose, I suggest you hard-code "t" instead of `mode` in the
one call to `luaD_protectedparser` (in `lua_load` in `lapi.c`; and, to
fix the resulting warning, say `UNUSED(mode);` at the top of that function).

-----

Depending on how aggressive your fuzzer is and how well (or not at all?)
you are sandboxing runs, further unrelated stuff you may want to change is:

  *  changing `l_checkmode` (in `liolib.c` or `#define`-ing it yourself)
     to only allow opening files for reading (never writing) - such that
     opening randomly generated file names will never accidentally
     overwrite anything
  *  removing `output` and `popen` from the `luaL_Reg iolib[]`
     in liolib.c (and maybe `tmpfile` too if opening too many files
     can cause spurious errors)
  *  removing `execute`, `remove`, `rename` (and again maybe `tmpname`)
     from `luaL_Reg syslib[]` in `loslib.c`

(of course, that means you won't be testing these functions...)

And depending on how much path analysis / SAT solving you do

  *  simplifying `luaS_hash` in `lstring.c` from the original to
     something stupid-simple like

       switch (l) {
         case 0: return 0;
         case 1: return *((uint8_t*)str);
         case 2:
         case 3: return *((uint16_t*)str);
         case 4:
         case 5:
         case 6:
         case 7: return *((uint32_t*)str);
         default: return *((unsigned int*)str);
       }

     Where the original can easily make path analysis give up and/or SAT
     state grow insanely large, this one is effectively transparent.

-- nobody
Reply | Threaded
Open this post in threaded view
|

Re: The security of function load

Gé Weijers
In reply to this post by Yongheng Chen


On Wed, Sep 23, 2020, 14:15 Yongheng Chen <[hidden email]> wrote:

So if the load function causes memory corruption, it is not considered as bugs?

 


Compiling Lua from source is very fast so if you can't trust compiled code just don't use it, load source code. Fuzzing binary code will give you plenty of crashes, that's expected behavior.