[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140825210805.036906C0008@smtpvmsrv1.mitre.org>
Date: Mon, 25 Aug 2014 17:08:05 -0400 (EDT)
From: cve-assign@...re.org
To: fweimer@...hat.com, mmcallis@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Lua CVE request [was Re: CVE request: possible overflow in vararg functions]
-----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."
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")?
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. The behavior of the
bytecode interpreter could have a separate CVE ID, but readers would
typically want either an "enabling malicious code to break out of the
sandbox" example or a reference to the specific incorrect part of the
Lua source code. 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?
> 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." Zero
arguments is apparently a valid way to provide "few arguments," and a
small number of attacker-supplied arguments is another way. We think
you mean that the original reproducer and the modified reproducer both
cross privilege boundaries (i.e., a Lua program may be providing a
realistic interface, such as an interface reachable with an HTTP
request, that allows an untrusted person to trigger a crash). The
essential difference is that the modified reproducer is more likely to
cause a crash with attacker-controllable memory corruption.
This would suggest one CVE assignment now for a vulnerability in the
vararg implementation, and possibly other CVE assignments related to
the mishandling of precompiled bytecode loading.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJT+6TyAAoJEKllVAevmvmsPNwH/3ZixUL16PzWmK1nQDVcjDmR
uPKo40lTFNfQA26ibE1SC8ItV33Owfy/aDUW3X4S3yEgUJvgj+TW5jScEc1n6EVr
r6+vgSaP4erEyIfcQRzNV11FulIkF25lxkG39XLksAze+N4VFUShjcgqVjptY2KX
Faqdq6I95oeUdxoih0sAuO380dgGZ1lcQN8VZCCoRdl4/VVbN98g7Xk1cnz1e8gr
2VCVdi/eo/tx/tBCe05q4vv7U70o33rH1PieoyweVqdBLyokvoxLPFNhTzw9JB3F
fQTKW+0aWBfTrFwashutch9A7sFmq9P1MkjmeEou1f1q33uLHXyuLJOy+vLmgVY=
=tApa
-----END PGP SIGNATURE-----
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.
