[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
