[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#37656: 27.0.50; Arbitrary code execution with special `mode:'

From: Clément Pit-Claudel
Subject: Re: bug#37656: 27.0.50; Arbitrary code execution with special `mode:'
Date: Tue, 15 Oct 2019 18:23:30 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

Besides this particular problem, whose fix might just be to remove an already 
deprecated feature, there's the more general issue that many people enable 
Flymake and Flycheck unconditionally in prog-mode and derivatives.

Flycheck has that same code execution problem, and it's been a known design 
issue for a while.  I think the right fix is to make a safe ELisp macroexpander 
(we try call checkers for languages that execute code at compile time with 
appropriate flags, but such flags are not always available; locally, I have a 
list of paths to enable Flycheck on, and I disable it otherwise).


On 2019-10-15 17:05, adam plaice wrote:
> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]