Follow @Openwall on Twitter for new release announcements and other news
[<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

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.