[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE request: possible overflow in vararg functions
From:       Florian Weimer <fweimer () redhat ! com>
Date:       2014-08-21 8:42:36
Message-ID: 53F5B0FC.9090708 () redhat ! com
[Download RAW message or body]

On 08/21/2014 08:31 AM, Murray McAllister wrote:
> Good morning,
>
> An overflow was reported to have been fixed in Lua 5.2.2. A reproducer
> and patch are available from:
>
> http://www.lua.org/bugs.html#5.2.2-1
>
> The reproducer affects older versions too (such as 5.1.4). One way an
> attacker could trigger this issue is if they can control parameters to a
> loadstring call (an eval in Lua, http://en.wikipedia.org/wiki/Eval#Lua).

loadstring only compiles the argument, it does not actually run any 
code.  So it's not really an eval as such.  As far as I can tell, the 
issue only arises if the code is executed.

loadstring accepts precompiled bytecode and does not perform sufficient 
verification on it.  It is possible to recognize a bytecode argument 
string filter that out, but if you do not that, attacks against the 
bytecode interpreter are possible, enabling malicious code to break out 
of the sandbox.  But it is not entirely clear if we can assume that a 
trust boundary is crossed.

However, this modified reproducer crashes as well, but only if you do 
not supply enough arguments (on the command line or to the surrounding 
function which fills in the ... argument list):

function f(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10,
            p11, p12, p13, p14, p15, p16, p17, p18, p19, p20,
            p21, p22, p23, p24, p25, p26, p27, p28, p29, p30,
            p31, p32, p33, p34, p35, p36, p37, p38, p39, p40,
            p41, p42, p43, p44, p45, p46, p48, p49, p50, ...)
   local a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14
end
f(...)

This means we cannot rule out that existing code in the Lua process 
exposes the vulnerability because a programmer might use this style to 
extract elements from an array whose contents (and length) is determined 
by an untrusted source.

> valgrind shows this crashes with invalid writes, but I am not sure if
> this is really a stack or heap overflow but something else. In
> luaD_precall():
>
> 330       for (; n < p->numparams; n++)
> 331         setnilvalue(L->top++);  /* complete missing arguments */
>
> This goes through 49 times with the reproducer (?possibly lifting what
> Lua thinks is the stack into the heap area?).

The Lua-level stack is allocated on the heap, so from a vulnerability 
viewpoint, this is a heap overflow.

-- 
Florian Weimer / Red Hat Product Security
[prev in list] [next in list] [prev in thread] [next in thread]