Flycheck 检查 Emacs Lisp 代码的一个安全隐患

xuchunyang · 2019 年1 月 12 日 08:13

Flycheck 的 Emacs Lisp 语法检查依赖于 Emacs Byte Compiler（当然 Flymake 应该也一样），而 Byte Compile 时会执行代码来展开宏，这里会有安全隐患，比如这样一个宏：

(defmacro foo ()
  (shell-command "date >> /tmp/foo"))

如果开启了 Flycheck，这个 Shell 命令会不断地执行：

我想到这个是因为昨天看了：

github.com/flycheck/flycheck

Elixir checker executes code in buffer

opened 10:08PM - 26 Apr 15 UTC

closed 08:22PM - 11 May 15 UTC

mattly

While investigating the issue that led to #628, [Elixir creator José Valim menti…oned that elixirc executes code](https://github.com/elixir-lang/elixir/issues/3282#issuecomment-94381550). I discovered this while editing a cpu-intensive `.exs` script and noticing that the script was actually being ran, but José says that the `.exs` extension differs from the main `.ex` extension in that the only real difference is one of convention – elixir code is evaluated by `elixirc` on compile. So that means you can create a new elixir buffer containing: ``` elixir File.write("foo", "bar") ``` and it will write a file to disk. You could also do `File.rm_rf!` or any number of things. While the majority of elixir code I work on is my own and I can trust it, I cannot trust any code I open in Emacs is going to be safe, nor should I have to. The solution is not to use `elixirc` for syntax checking, but converting flycheck over will not prove simple, and will not provide actual compilation errors that can only be gained by evaluating and compiling the code. Since I'm still new to Emacs and its lisp variant, I'm going to sketch out the issue and its solution first, and then set about solving it. This is a safe way to syntax-check elixir code: ``` elixir -e 'r = System.argv |> List.first |> File.read! |> Code.string_to_quoted; if elem(r, 0) == :error do IO.inspect(elem(r,1)); end' -- filename.ex ``` It's perhaps not the most idiomatic elixir code, but I was aiming for something that would work on the command-line instead of from a file. It also outputs errors as elixir s-expressions, for example `{6, "missing terminator: ) (for \"(\" starting at line 1)", ""}` instead of ``` == Compilation error on file invalid_ex.ex == ** (TokenMissingError) invalid_ex.ex:6: missing terminator: ) (for "(" starting at line 1) (elixir) lib/kernel/parallel_compiler.ex:95: anonymous fn/4 in Kernel.ParallelCompiler.spawn_compilers/8 ``` Finally, this method only checks for syntax errors, it will not generate compile-time warnings or errors such as missing modules, invalid arguments, typos in keywords, etc. The only way to do that is to evaluate the code. I would _love_ to have a mode in flycheck that continued to provide that level of checking, but only for trusted projects. I'm not sure there's a way to flip between "safe, shallow checker" and "unsafe, deep checker" however.

xuchunyang · 2019 年1 月 12 日 08:21

如果你开了 global-flycheck-mode，就要注意不能随便点开别人给你发的 Emacs Lisp 文件。

glgl-schemer · 2019 年1 月 12 日 09:40

考虑发下邮件？

cireu · 2019 年1 月 12 日 09:44

给flycheck开发者报bug吧

zmqclee · 2019 年1 月 12 日 09:48

这个感觉不好解决吧，我刚刚试了一下 flymake 也是一样的

xuchunyang · 2019 年1 月 12 日 10:48

确实应该向上游报告。

尽管我估计开发者十有八九清楚这个问题，而且 Flycheck、Flymake 本身不太可能解决这个问题，得专门写个安全的 Emacs Lisp 语法检查器或者给 Emacs 加个 Sandbox，这远远超出了 Flycheck、Flymake 的范畴。

glgl-schemer · 2019 年1 月 12 日 11:47

我的意思是报给emacs，主题是 A Secure Emacs Lisp Analyzer Required 之类的。

seagle0128 · 2019 年1 月 12 日 18:31

以后只能在docker中玩emacs了？

casouri · 2019 年1 月 13 日 02:17

一个naive的方法是可选地禁止某些函数在宏展开的时候运行。

比如设置一个变量inhibit-risky-macro-expand-function，然后像risky-local-variable那样把一些函数标记为risky-macro-expand-function，比如I/O操作，fork process，等等。如果inhibit-risky-macro-expand-function为t，展开宏的时候就不运行这些函数。

语法检查器就可以let bind inhibit-risky-macro-expand-function为t。

别的lisp编辑器是怎么解决这个问题的？@ldbeth

LdBeth · 2019 年1 月 13 日 03:43

To address this problem, compilers can support a subjunctive environment [9], a special LISP environment which is quarantined from the current environment for the purposes of compilation. (IBM’s Yorktown Lisp compiler provided saved states for this purpose [10]). A LISP environment is presumably everything with dynamic extent that can be changed by evaluating top-level forms in user code; it can include the data for the reader, definitions for macros, structures, setf methods, and types, special proclamations, and even function definitions. The purpose of a subjunctive environment is to insulate the current environment from side-effects of using the compiler. The compiler runs in its own subjunctive environment.

casouri · 2019 年1 月 13 日 04:46

我感觉他讲的跟安全隐患不太一样，他说的危险是污染运行环境，而不是执行代码本身可能的危害。

LdBeth · 2019 年1 月 13 日 05:05

Evaluating arbitrary user code in the current LISP environment can be dangerous, because it may break existing code by redeiining existing functions and macros, altering the properties of symbols, or changing the state of the reader.10 It can also change the behavior of functions

我只挑了怎么做。你大概沒看全。

casouri · 2019 年1 月 13 日 17:10

哦，xuchunyang举例用的是(shell-command)，之后又说说「注意不能随便点开别人给你发的 Emacs Lisp 文件。」我就以为他说的安全隐患是指恶意代码运行rm -rf ~之类的，而不是你说的那些。

seagle0128 · 2019 年1 月 13 日 18:38

我也是这么理解的~~~