An overflow flaw was fixed in Lua 5.2.2: http://www.lua.org/bugs.html#5.2.2-1 This could cause the application to crash or, potentially, execute arbitrary code. One way an attacker could trigger this issue is if they can control parameters to a loadstring call (an eval in Lua, http://en.wikipedia.org/wiki/Eval#Lua). Although Fedora 20 has 5.2.2, the issue is not resolved there.
Created lua tracking bugs for this issue: Affects: fedora-all [bug 1132307] Affects: epel-5 [bug 1132308]
CVE request: http://www.openwall.com/lists/oss-security/2014/08/21/1
Issue affects 5.2.2 of which never an update was released to fix it, and 5.2.3 was releasd in Nov 2013 while the bug & patch in 5.2.2 was already published on http://www.lua.org/bugs.html in April 2013. What this means is that upstream does *not* release updated tarballs, all fixes published on http://www.lua.org/bugs.html need to be incorporated manually until a major release which finally resolves all issues in one go is released (5.2.3 in that case). Sadly, the download page on lua.org doesn't contain a warning about that either.
Regarding loadstring as an attack vector: loadstring accepts precompiled bytecode and does not perform sufficient verification on it. 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, enabling malicious code to break out of the sandbox. But it is not entirely clear if we can assume that a trust boundary is crossed. However, this modified reproducer crashes as well, but only if you do not supply enough arguments (on the command line or to the surrounding function which fills in the ... argument list): function f(p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14, p15, p16, p17, p18, p19, p20, p21, p22, p23, p24, p25, p26, p27, p28, p29, p30, p31, p32, p33, p34, p35, p36, p37, p38, p39, p40, p41, p42, p43, p44, p45, p46, p48, p49, p50, ...) local a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14 end f(...) This means we cannot rule out that existing code in the Lua process exposes the vulnerability because a programmer might use this style to extract elements from an array whose contents (and length) is determined by an untrusted source. The Lua-level stack is allocated on the heap, so from a vulnerability viewpoint, this is a heap overflow.
@loadstring: it is common practise to whitelist functions for Lua states before running untrusted code, and the Lua wiki has common practises like a warning against exactly this issue: http://lua-users.org/wiki/SandBoxes The recommended way is to replace loadstring with a custom wrapper that doesn't allow bytecode loading, or not providing it at all. Therefore the "loadstring" issue is more like a known limitation of Lua, not a real security issue because it can be solved by adhering to well-described sandboxing practises. -- TL;DR: I'd recommend to assume a hardened (non-byte code loading) "load"/"loadstring" when considering whether this is a security issue for sandboxing applications, since basic common sandboxing practises as recommended on the wiki should be assumed to be followed.
I am trying to convince Lua people for a note about their unusual practises (mainly about not releasing timely patched updates like most other projects, but only a more or less hard to discover note about discovered exploits on http://www.lua.org/bugs.html) on their download page, but they don't seem to be up for it: http://lua.2524044.n2.nabble.com/Please-add-warning-to-download-page-if-tarball-isn-t-patched-up-with-all-latest-security-fixes-td7662438.html Well, I hope at least Red Hat/Fedora packagers are more aware of this pitfall by now.
MITRE assigned CVE-2014-5461 to this issue: http://seclists.org/oss-sec/2014/q3/453
Debian took a few days to patch this out, but this still appears to be unfixed in Fedora. Any estimate when this will be fixed?
Fedora 21 and this is still unfixed. Is there ever going to be something done about it?
Statement: This issue affects the versions of lua as shipped with Red Hat Enterprise Linux 6 and 7. Red Hat Product Security has rated this issue as having Moderate security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
(In reply to Jonas Thiem from comment #15) > Fedora 21 and this is still unfixed. Is there ever going to be something > done about it? You can try contacting the lua package owner for Fedora, if they are unresponsive then there is a process to handle non responsive maintainers. https://admin.fedoraproject.org/pkgdb/package/lua/
I'll take a look at this tomorrow for Fedora.