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

["Clément Pit-Claudel" <cpitclaudel@gmail.com>]

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

Clément.

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