Re: Lua CVE request [was Re: CVE request: possible overflow in vararg functions]

[Florian Weimer <fweimer () redhat com>]

On 08/25/2014 11:08 PM, cve-assign () mitre org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We wanted to check whether we were interpreting this correctly before
> proceeding to CVE assignment.
>
> http://openwall.com/lists/oss-security/2014/08/21/4 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.:

<http://lua-users.org/lists/lua-l/2011-10/msg01215.html>

> http://openwall.com/lists/oss-security/2014/08/21/4 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
> http://www.lua.org/bugs.html#5.2.2-1 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
> http://www.lua.org/bugs.html#5.2.2-1 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