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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ