Date: Thu, 21 Aug 2014 10:42:36 +0200 From: Florian Weimer <fweimer@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: CVE request: possible overflow in vararg functions 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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ