[wesnoth-commits] [wesnoth/wesnoth] d91126: disallow loading lua bytecode via load/dofile (CVE...

[GitHub]

  Branch: refs/heads/1.14
  Home:   https://github.com/wesnoth/wesnoth
  Commit: d911268a783467842d38eae7ac1630f1fea41318
      https://github.com/wesnoth/wesnoth/commit/d911268a783467842d38eae7ac1630f1fea41318
  Author: gfgtdf <daniel.gfgtdf at gmail.com>
  Date:   2018-07-22 (Sun, 22 Jul 2018)

  Changed paths:
    M changelog.md
    M src/ai/lua/core.cpp
    M src/lua/lbaselib.cpp
    M src/scripting/application_lua_kernel.cpp
    M src/scripting/lua_fileops.cpp
    M src/scripting/lua_kernel_base.cpp

  Log Message:
  -----------
  disallow loading lua bytecode via load/dofile (CVE-2018-1999023)

This could otherwise be used to escape the lua sandbox, as described in
multiple sources. For example one can use it to reenable the os.execute
function to do shell commands

The affected functions were
load,loadstring,wesnoth.dofile,wesnoth.require and various places in the
wesnoth source where lua chunks were loaded for example by the ai code.

This commit also changes the lua source to change luas load (which is
the same as loadstring), alternatively we could add a wrapper around the
original load function that always passes "t" as third parameter, i went
this way mostly because it was easier to implement, but also because i
was not 100% sure that is is impossible to query the upvalues of a
function via lua (wesnoth disables debug.getupvalue but still).

There is also an occurance in the application_lua_kernel that was not fixed
because i assumed that umc cannot contian application lua scipts.

As further security measure we might want to disable printing the function
adress in luas tostring for c functions, this cannot be exploited by itself
but it can be used to defeat ASLR in some cases.



      **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.