Bug 1132304 (CVE-2014-5461) - CVE-2014-5461 lua: overflow flaw in vararg functions
Summary: CVE-2014-5461 lua: overflow flaw in vararg functions
Alias: CVE-2014-5461
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1132307 1132308
Blocks: 1132323
TreeView+ depends on / blocked
Reported: 2014-08-21 06:25 UTC by Murray McAllister
Modified: 2021-02-17 06:17 UTC (History)
13 users (show)

Fixed In Version: lua 5.2.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-19 20:39:45 UTC

Attachments (Terms of Use)

Description Murray McAllister 2014-08-21 06:25:10 UTC
An overflow flaw was fixed in Lua 5.2.2:


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.

Comment 1 Murray McAllister 2014-08-21 06:26:58 UTC
Created lua tracking bugs for this issue:

Affects: fedora-all [bug 1132307]
Affects: epel-5 [bug 1132308]

Comment 2 Murray McAllister 2014-08-21 06:32:08 UTC
CVE request: http://www.openwall.com/lists/oss-security/2014/08/21/1

Comment 7 ell1e 2014-08-21 13:16:02 UTC
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.

Comment 8 Florian Weimer 2014-08-21 15:00:01 UTC
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

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.

Comment 9 ell1e 2014-08-21 15:07:52 UTC

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.

Comment 10 ell1e 2014-08-21 15:16:41 UTC
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:


Well, I hope at least Red Hat/Fedora packagers are more aware of this pitfall by now.

Comment 11 Murray McAllister 2014-08-27 07:54:40 UTC
MITRE assigned CVE-2014-5461 to this issue:


Comment 13 ell1e 2014-10-14 18:06:02 UTC
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?

Comment 15 ell1e 2015-02-01 11:46:59 UTC
Fedora 21 and this is still unfixed. Is there ever going to be something done about it?

Comment 16 Kurt Seifried 2015-02-19 20:39:45 UTC

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/.

Comment 17 Kurt Seifried 2015-02-19 20:41:23 UTC
(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. 


Comment 18 Tim Niemueller 2015-02-19 20:48:54 UTC
I'll take a look at this tomorrow for Fedora.

Note You need to log in before you can comment on or make changes to this bug.