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

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/wesnoth/wesnoth
  Commit: 2554c166dd45bfdee8ee24431224bd25e52bab12
      https://github.com/wesnoth/wesnoth/commit/2554c166dd45bfdee8ee24431224bd25e52bab12
  Author: gfgtdf <daniel.gfgtdf at gmail.com>
  Date:   2018-07-27 (Fri, 27 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.


  Commit: 6b13a63bb0999e1c494a4236a5d565306db5a0b9
      https://github.com/wesnoth/wesnoth/commit/6b13a63bb0999e1c494a4236a5d565306db5a0b9
  Author: gfgtdf <daniel.gfgtdf at gmail.com>
  Date:   2018-07-27 (Fri, 27 Jul 2018)

  Changed paths:
    A data/test/scenarios/bytecode.lua
    A data/test/scenarios/test_cve_2018_1999023.cfg
    A data/test/scenarios/test_cve_2018_1999023_2.cfg
    M wml_test_schedule

  Log Message:
  -----------
  wml test for cve-2018-1999023

this test whether we succesfully prevent the exceution and parsing of
precompiled lua chunks, which can be used to break the lua sandbox.
This test does not cover all affected functions in particular not the ai
code that loads lua chunks.


  Commit: 52ae31efb21b31f5bb0763d1da24709e90393c59
      https://github.com/wesnoth/wesnoth/commit/52ae31efb21b31f5bb0763d1da24709e90393c59
  Author: Jyrki Vesterinen <sandgtx at gmail.com>
  Date:   2018-07-27 (Fri, 27 Jul 2018)

  Changed paths:
    M src/lua/lbaselib.cpp
    M src/scripting/lua_kernel_base.cpp

  Log Message:
  -----------
  Lua: implement our own load() instead of monkey-patching Lua code

Monkey-patching has multiple problems. The biggest problem for a security
fix like this is that it's way too easy to forget to re-apply when we
update Lua to a newer version.

Instead, we now have the implementation of load() under our control and can
update Lua without risk of reintroducing CVE-2018-1999023.


Compare: https://github.com/wesnoth/wesnoth/compare/386493790e1d...52ae31efb21b
      **NOTE:** This service has 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.