[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53FC4D2F.7070902@redhat.com>
Date: Tue, 26 Aug 2014 11:02:39 +0200
From: Florian Weimer <fweimer@...hat.com>
To: cve-assign@...re.org, mmcallis@...hat.com
CC: oss-security@...ts.openwall.com
Subject: Re: Lua CVE request [was Re: CVE request: possible overflow in vararg
functions]
On 08/25/2014 11:08 PM, cve-assign@...re.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
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.
