unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: adam plaice <plaice.adam+lists@gmail.com>
To: emacs-devel@gnu.org
Cc: 37656@debbugs.gnu.org
Subject: bug#37656: 27.0.50; Arbitrary code execution with special `mode:'
Date: Tue, 15 Oct 2019 23:05:01 +0200	[thread overview]
Message-ID: <CAJw81dZZmX=z-YFDwvEkuWR6xH+cf=mR9h-fcZTphwdXWrA5wg__22551.5585554362$1571173594$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <CAJw81da4=R1jMJ0enx6SbO7G1rzaL61K2kqbY+jxhe=AM-3vtQ@mail.gmail.com>

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
>
>





  reply	other threads:[~2019-10-15 21:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-08  8:48 bug#37656: 27.0.50; Opening file with specially crafted local variables can cause arbitrary code execution Inbox x adam plaice
2019-10-15 21:05 ` adam plaice [this message]
2019-10-16 13:13 ` Stefan Monnier
     [not found] <CAJw81dZZmX=z-YFDwvEkuWR6xH+cf=mR9h-fcZTphwdXWrA5wg@mail.gmail.com>
2019-10-15 22:27 ` bug#37656: 27.0.50; Arbitrary code execution with special `mode:' Stefan Kangas
     [not found] ` <CADwFkmnqfbsEEWkWMA2xnN1O+-JsTcCKrSYv0e3g1+jXrxRY5g@mail.gmail.com>
2019-10-15 22:55   ` Stefan Kangas
2019-10-15 23:17     ` Stefan Kangas
2019-10-16  0:35     ` Adam Plaice
2019-10-16  7:57       ` Eli Zaretskii
2019-10-16  0:55     ` Phil Sainty
     [not found]     ` <CADwFkmk+03=J8YUy51xzBxSK2+u0DuMLq3Ur63Wr_YWv6e=C=g@mail.gmail.com>
2019-10-16  7:58       ` Eli Zaretskii
2019-10-16 11:51         ` Adam Plaice
2019-10-16 17:09           ` Eli Zaretskii
2019-10-16 19:09             ` Phil Sainty
2019-10-16 19:34               ` Eli Zaretskii
2019-10-16 21:02               ` Adam Plaice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJw81dZZmX=z-YFDwvEkuWR6xH+cf=mR9h-fcZTphwdXWrA5wg__22551.5585554362$1571173594$gmane$org@mail.gmail.com' \
    --to=plaice.adam+lists@gmail.com \
    --cc=37656@debbugs.gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).