Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Aug 2014 11:02:39 +0200
From: Florian Weimer <>
Subject: Re: Lua CVE request [was Re: CVE request: possible overflow in vararg

On 08/25/2014 11:08 PM, wrote:
> Hash: SHA1
> We wanted to check whether we were interpreting this correctly before
> proceeding to CVE assignment.
> says "loadstring
> accepts precompiled bytecode and does not perform sufficient
> verification on it ... But it is not entirely clear if we can assume
> that a trust boundary is crossed." We think this may mean something
> like: "By default, an attacker who is able to control input to the
> loadstring function can include a representation of os.execute in that
> input. A realistic Lua program is (probably?) not going to call
> loadstring unless it plans to run the chunk. Therefore the attacker
> already has the privileges of the Lua process, and it is not relevant
> that the attacker can also exploit implementation flaws in the
> bytecode interpreter."

Lua has some sandboxing functionality, but it can be bypassed by 
supplying precompiled bytecode.  There have been extensive discussions 
about this on the lua-users mailing list, e.g.:


> also says "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." Were there missing words here (possibly "string and filter
> that out")?

Right, and that's a valid observation.

> In general, it seems that this observation about the bytecode
> interpreter is largely unrelated to the
> bug report.

It's relevant to deciding whether there's security impact or not.  If 
this functionality is utterly insecure anyway, this bug wouldn't be a 
security bug.

> Alternatively, there could be separate CVE IDs for
> Lua programs that lack the filtering mentioned above. Is this issue
> best considered to be not yet publicly disclosed?

No, oss-security is a public list, and the general problem has been 
widely discussed (see above).

>> this modified reproducer crashes as well
> As far as we can tell, this is within the scope of the vendor's
> disclosure, and isn't a separate problem. The
> bug report is about "vararg
> functions with many fixed parameters called with few arguments."

What I was trying to show is this: Existing code which uses a large 
number of arguments (for example, for dissecting a table or string) 
could expose this issue when called with too few arguments (say, if the 
table was too short).  This means that a crafted argument to loadstring 
is not always needed to trigger this bug, and the security properties of 
loadstring do not matter.  In short, I think this vararg processing bug 
should be treated as a security bug.

Florian Weimer / Red Hat Product Security

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ