Bug#950816: mpv: unintended code execution vulnerability

[astian]

Control: tags -1 + patch
Control: found -1 mpv/0.29.1-1

FYI, the patch below works for me.

Also, I think the version in stable is also affected.  The code differs
slightly so the patch will need a little tweak.

Cheers.

-- 

>From 937749b545407aa68b1d15ea5e19a6c23d62da42 Mon Sep 17 00:00:00 2001
From: astian 
Date: Mon, 11 Feb 2020 21:08:51 +
Subject: [PATCH] lua: fix unintended code execution vulnerability

Backport of upstream commit cce7062a8a6b6a3b3666aea3ff86db879cba67b6
("lua: fix highly security relevant arbitrary code execution") to
release 0.32.0.

Note:  Before release 0.32.0, it used to be that mpv-related scripts
directories where added to Lua's module-loaders search path.  This
behaviour was dropped in 0.32.0 (bc1c024ae032).  Later, a similar but
stricter behaviour was introduced (see da38caff9c0b and b86bfc907f9c).
The original commit on which this patch is based depended on the new
behaviour.  This backport retains the 0.32.0 behaviour; all it does is
filter out relative paths from "package.path" and "package.cpath" for
all Lua scripts.
---
 player/lua.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/player/lua.c b/player/lua.c
index 6423861..172ab4e 100644
--- a/player/lua.c
+++ b/player/lua.c
@@ -273,6 +273,36 @@ static int load_scripts(lua_State *L)
 return 0;
 }
 
+static void fuck_lua(lua_State *L, const char *search_path)
+{
+void *tmp = talloc_new(NULL);
+
+lua_getglobal(L, "package"); // package
+lua_getfield(L, -1, search_path); // package search_path
+bstr path = bstr0(lua_tostring(L, -1));
+char *newpath = talloc_strdup(tmp, "");
+
+// Unbelievable but true: Lua loads .lua files AND dynamic libraries from
+// the working directory. This is highly security relevant.
+// Lua scripts are still supposed to load globally installed libraries, so
+// try to get by by filtering out any relative paths.
+while (path.len) {
+bstr item;
+bstr_split_tok(path, ";", , );
+if (bstr_startswith0(item, "/")) {
+newpath = talloc_asprintf_append(newpath, "%s%.*s",
+ newpath[0] ? ";" : "",
+ BSTR_P(item));
+}
+}
+
+lua_pushstring(L, newpath);  // package search_path newpath
+lua_setfield(L, -3, search_path); // package search_path
+lua_pop(L, 2);  // -
+
+talloc_free(tmp);
+}
+
 static int run_lua(lua_State *L)
 {
 struct script_ctx *ctx = lua_touserdata(L, -1);
@@ -326,6 +356,10 @@ static int run_lua(lua_State *L)
 
 assert(lua_gettop(L) == 0);
 
+fuck_lua(L, "path");
+fuck_lua(L, "cpath");
+assert(lua_gettop(L) == 0);
+
 // run this under an error handler that can do backtraces
 lua_pushcfunction(L, error_handler); // errf
 lua_pushcfunction(L, load_scripts); // errf fn
-- 
2.25.0

Bug#950816: Acknowledgement (mpv: unintended code execution vulnerability)

[astian]

astian:
> If Lua scripts are enabled (they are by default) and configured for use
> (Debian doesn't seem to have any active by default)

Correction: mpv as shipped by Debian does have some active Lua scripts
embedded in the ELF binary, but, as the author says in the quoted commit, they
'only "require" preloaded modules':

  $ strings /usr/bin/mpv | grep 'require '
  require '%s'
  local msg = require 'mp.msg'
  local assdraw = require 'mp.assdraw'
  local msg = require 'mp.msg'
  local opt = require 'mp.options'
  local utils = require 'mp.utils'
  local utils = require 'mp.utils'
  local msg = require 'mp.msg'
  local options = require 'mp.options'
  local mp = require 'mp'
  local options = require 'mp.options'
  local utils = require 'mp.utils'
  local utils = require 'mp.utils'
  local options = require 'mp.options'
  local assdraw = require 'mp.assdraw'

That "require '%s'" looks suspicious but it seems to be only called precisely
for those "built-in" Lua modules.

Cheers.

Bug#950816: mpv: unintended code execution vulnerability

[astian]

Package: mpv
Version: 0.32.0-1
Severity: grave
Tags: security fixed-upstream
Justification: user security hole

Dear Maintainer,

If Lua scripts are enabled (they are by default) and configured for use
(Debian doesn't seem to have any active by default) mpv could end up
loading unintended code (lua scripts/bytecode and/or shared objects)
from the current working directory.

The following upstream commit supposedly fixes this:
https://github.com/mpv-player/mpv/commit/cce7062a8a6b6a3b3666aea3ff86db879cba67b6

Excerpt from the commit message:

  lua: fix highly security relevant arbitrary code execution bug

  It appears Lua's package paths try to load .lua files from the current
  working directory. Not only that, but also shared libraries.

  [...]

  In mpv's case, this is so security relevant, because mpv is normally
  used from the command line, and you will most likely actually change
  into your media directory or whatever with the shell, and play a file
  from there. No, you don't want to load a (probably downloaded) shared
  library from this directory if a script try to load a system lib with
  the same name or so.

  I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the
  Debian version) put "./?.lua" at the end, but in any case, trying to
  load a module that doesn't exist nicely lists all package paths in
  order, and confirms it tries to load files from the working directory
  first (anyone can try this). Even if it didn't, this would be
  problematic at best.

  Note that scripts are not sandboxed. They're allowed to load system
  libraries, which is also why we want to keep the non-idiotic parts of
  the package paths.

  [...]

  mpv in default configuration (i.e. no external scripts) is probably not
  affected. All builtin scripts only "require" preloaded modules, which,
  in a stroke of genius by the Lua developers, are highest priority in the
  load order. Otherwise, enjoy your semi-remote code execution bug.

  [...]

Cheers.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mpv depends on:
ii  libarchive13  3.4.0-1+b1
ii  libasound21.2.1.2-2
ii  libass9   1:0.14.0-2
ii  libavcodec58  7:4.2.2-1
ii  libavdevice58 7:4.2.2-1
ii  libavfilter7  7:4.2.2-1
ii  libavformat58 7:4.2.2-1
ii  libavutil56   7:4.2.2-1
ii  libbluray21:1.1.2-2
ii  libc6 2.29-9
ii  libcaca0  0.99.beta19-2.1
ii  libcdio-cdda2 10.2+2.0.0-1+b1
ii  libcdio-paranoia2 10.2+2.0.0-1+b1
ii  libcdio18 2.0.0-2
ii  libdrm2   2.4.100-4
ii  libdvdnav46.0.1-1+b1
ii  libegl1   1.3.0-7
ii  libgbm1   19.3.3-1
ii  libgl11.3.0-7
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-4
ii  liblua5.2-0   5.2.4-1.1+b3
ii  libpulse0 13.0-4
ii  librubberband21.8.2-1
ii  libsdl2-2.0-0 2.0.10+dfsg1-1
ii  libsmbclient  2:4.11.5+dfsg-1
ii  libsndio7.0   1.5.0-3
ii  libswresample37:4.2.2-1
ii  libswscale5   7:4.2.2-1
ii  libuchardet0  0.0.6-3
ii  libva-drm22.6.1-1
ii  libva-wayland22.6.1-1
ii  libva-x11-2   2.6.1-1
ii  libva22.6.1-1
ii  libvdpau1 1.3-1
ii  libwayland-client01.17.0-1+b1
ii  libwayland-cursor01.17.0-1+b1
ii  libwayland-egl1   1.17.0-1+b1
ii  libx11-6  2:1.6.8-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 0.9.1-1
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1
ii  zlib1g1:1.2.11.dfsg-1.1

Versions of packages mpv recommends:
ii  xdg-utils   1.1.3-1
ii  youtube-dl  2020.01.24-0.1

mpv suggests no packages.

-- no debconf information

Bug#929439: minetest-mod-pipeworks: Missing dependency

[astian]

Package: minetest-mod-pipeworks
Version: 20190430-1
Severity: serious
Justification: Policy 3.5. Dependencies

Dear Maintainer,

Package lacks a dependency on "basic_materials" (minetest-mod-basic-materials).

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages minetest-mod-pipeworks depends on:
ii  minetest  0.4.17.1+repack-1+b1

Versions of packages minetest-mod-pipeworks recommends:
ii  minetest-mod-mesecons  1:1.2.1-1

minetest-mod-pipeworks suggests no packages.

-- no debconf information

Bug#879631: python3-flask-socketio: missing dependency

[astian]

Package: python3-flask-socketio
Version: 2.9.0-1
Severity: serious

Dear Maintainer,

This package lacks a dependency on the upstream "python-socketio" [0],
which provides a "socketio" module.  Please do not confuse it with the
Debian package of the same name, which also provides a "socketio": that
package is actually "gevent-socketio" [1] and incompatible with
python3-flask-socketio [2].

  0: https://github.com/miguelgrinberg/python-socketio/
  1: https://github.com/abourget/gevent-socketio
  2: From flask_socketio/__init__.py:
   if gevent_socketio_found:
   print('The gevent-socketio package is incompatible with this version 
of '
 'the Flask-SocketIO extension. Please uninstall it, and then '
 'install the latest version of python-socketio in its place.')
   sys.exit(1)

It seems that the required package is not currently packaged in Debian,
unfortunately.  As is, python3-flask-socketio is useless.  Further
justification for "serious" severity: Debian policy manual section 3.5
[3].

  3: https://www.debian.org/doc/debian-policy/#dependencies

Cheers.

PS: The package tracker at  says:

  action needed
  Problems while searching for a new upstream version


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-flask-socketio depends on:
ii  python3   3.6.3-1
ii  python3-engineio  1.6.1-1
ii  python3-flask 0.12.2-2

python3-flask-socketio recommends no packages.

python3-flask-socketio suggests no packages.

-- no debconf information

Bug#789927: libanthyinput0: fails to upgrade from 'sid' - trying to overwrite /usr/lib/x86_64-linux-gnu/libanthyinput.so.0.0.0'

[astian]

Control: affects -1 ibus-anthy
Control: found -1 ibus-anthy/1.5.9-2
Control: found -1 anthy/1:0.3-5

Hi,

Packaging is still broken on sid.  (Interesting how 2 years of forewarning
were still not sufficient to prevent this.)

  $ sudo apt install ibus-anthy
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   ibus-anthy : Depends: libanthy0 but it is not going to be installed
  E: Unable to correct problems, you have held broken packages.

Note: I have *not* held packages.

Anyway, it seems to me that the problem is not difficult to identify (though I
can't give great insight about the solution): it is obvious that the groups of
packages  and  conflict, yet there are
many (IME-related) packages (such as ibus-anthy, or kasumi) that depend on
both "anthy" (which now pulls in libanthy1 and libanthyinput0) and
"libanthy0", which is an unworkable situation.

Now, I wonder, why does libanthy0 have to still exist (in parallel to the new
libanthy1 and libanthyinput0)?  Why not simply replacing the dependency in all
packages dependent on libanthy0 (and then maybe even removing libanthy0)?
Just thinking out loud.

You might want to take a look at the graph below showing some anthy-related
dependencies on Debian unstable (I had to edit it by hand because both
"apt-cache dotty" and "debtree" are too under-featured).

Thanks.

--

digraph packages {
concentrate=true;
size="30,40";
"ibus-anthy" -> "anthy";
"ibus-anthy" -> "ibus";
"libanthyinput0" -> "libanthy1";
"libanthyinput0" -> "anthy"[color=springgreen];
"anthy" -> "anthy-common";
"anthy" -> "libanthy1";
"anthy" -> "libanthyinput0";
"anthy" -> "anthy-common"[color=springgreen];
"libanthy0" -> "anthy-common";
"libanthy1" -> "anthy-common";

"uim-dict-gtk3" -> "libanthy0";
"uim-dict-gtk" -> "libanthy0";
"uim-anthy" -> "libanthy0";
"hime-anthy" -> "libanthy0";
"gcin-anthy" -> "libanthy0";
"uim-dict-gtk3" -> "libanthy0";
"uim-dict-gtk" -> "libanthy0";
"uim-anthy" -> "libanthy0";
"fcitx-anthy" -> "libanthy0";
"uim-dict-gtk3" -> "libanthy0";
"uim-dict-gtk" -> "libanthy0";
"uim-anthy" -> "libanthy0";
"scim-anthy" -> "libanthy0";
"m17n-lib-mimx" -> "libanthy0";
"ibus-anthy" -> "libanthy0";
"hime-anthy" -> "libanthy0";
"gcin-anthy" -> "libanthy0";
"kasumi" -> "libanthy0";

"ibus-anthy" [shape=box];
"anthy-common" [shape=box];
"ibus" [color=orange,shape=box];
"libanthyinput0" [shape=box];
"anthy" [shape=box];
"libanthy0" [shape=box];
"libanthy1" [shape=box];

"uim-dict-gtk3" [shape=box];
"uim-dict-gtk" [shape=box];
"uim-anthy" [shape=box];
"hime-anthy" [shape=box];
"gcin-anthy" [shape=box];
"uim-dict-gtk3" [shape=box];
"uim-dict-gtk" [shape=box];
"uim-anthy" [shape=box];
"fcitx-anthy" [shape=box];
"uim-dict-gtk3" [shape=box];
"uim-dict-gtk" [shape=box];
"uim-anthy" [shape=box];
"scim-anthy" [shape=box];
"m17n-lib-mimx" [shape=box];
"hime-anthy" [shape=box];
"gcin-anthy" [shape=box];
"kasumi" [shape=box];
}