GNU bug report logs - #37656
27.0.50; Arbitrary code execution with special `mode:'

Previous Next

Package: emacs;

Reported by: adam plaice <plaice.adam+lists <at> gmail.com>

Date: Tue, 8 Oct 2019 08:49:02 UTC

Severity: normal

Tags: security

Found in version 27.0.50

Fixed in version 30.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 37656 <at> debbugs.gnu.org (full text, mbox):

From: adam plaice <plaice.adam+lists <at> gmail.com>
To: emacs-devel <at> gnu.org
Cc: 37656 <at> debbugs.gnu.org
Subject: bug#37656: 27.0.50; Arbitrary code execution with special `mode:'
Date: Tue, 15 Oct 2019 23:05:01 +0200
Since the bug allows an attacker to execute arbitrary code if the
victim opens a payload file, and hence opening any file from an
untrusted source becomes dangerous, it seems to be rather
serious.

The bug relies on the fact that flymake-mode can execute arbitrary
code, that minor modes (in particular, flymake-mode) can be set with
local variables (with `mode:') and that when a minor-mode is set in
this way, the major-mode is not unset. (See the linked bug or below
for details.)

I'm not sure whether I should be bringing greater attention to it,
but given that it's already in the open, and malicious actors can
find it (or just come up with it themselves, as it's not a particularly
complex idea), increasing the likelihood of getting it fixed hopefully
outweighs the disadvantages.

I'd offer to provide a patch, but I'm neither very proficient with
Emacs lisp, nor a security expert.  I also haven't signed any copyright
papers.


Some thoughts on potential solutions (from a well-intentioned, but
possibly misguided layman):

AFAICT the easiest way to prevent this specific bug would be to
prevent more than one mode being set by the file and directory
local-variables machinery.

Perhaps also only allowing major modes to be set with `mode' in local
variables (and only allowing minor-modes to be set with `eval', as is
already encouraged in the manual), might decrease the "attack surface"
for similar such attacks.

I'm not sure whether any major modes are "unsafe" (in the way flymake
is), but possibly it might make sense to mark major modes as safe,
similarly to the way variables are, though that would be a far more
extensive change.

Thank you,
Adam

PS Should Emacs have some policies on reporting security issues? I
was encouraged (via an earlier e-mail exchange) to post the bug to
debbugs, as normal, but it might perhaps be useful if the process
(specifically for security vulnerabilities, not bugs in general) were
mentioned in the manual.

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37656
>
> * To reproduce:
>
> 1. Create a file, say `~/foobar', (it could have an arbitrary
> extension) with the following contents:
>
> -*- mode: emacs-lisp; mode: flymake -*-
>
> (eval-when-compile
>   (with-temp-file "~/emacs_flymake_security_bug"
>       (insert "Could have also executed any code.")))
>
> 2. Open the file with emacs:
>
> emacs -Q ~/foobar
>
> 3. Inspect ~/emacs_flymake_security_bug:
>
> cat ~/emacs_flymake_security_bug
>
> * Expected result
>
> ~/emacs_flymake_security_bug does not exist.
>
> * Actual result
>
> ~/emacs_flymake_security_bug does exist.
>
> * Further information
>
> This relies on the "deprecated" feature of allowing `mode: ' to be
> repeated more than once, to also specify minor modes.  Just having:
>
> -*- mode: flymake -*-
>
> in, say, `~/foobar.el' would not trigger the security bug.  There may,
> however, be alternative ways of triggering it, that I haven't come up
> with.
>
>
> This was "inspired" by a very similar bug (concerning an external
> package, editorconfig), described here:
>
> https://illikainen.dev/blog/2019-10-06-editorconfig
>
> Thank you and best regards,
> Adam
>
>




This bug report was last modified 125 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.