GNU bug report logs - #28618
Emacs respects $HOME, even when user is root

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28618 in the body.
You can then email your comments to 28618 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Dor Azouri <dor.azouri <at> safebreach.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs Security Issue
Date: Wed, 27 Sep 2017 13:56:46 +0000

[Message part 1 (text/plain, inline)]

Dear Emacs developers,

I would like to report a possible abuse one can perform on Emacs's
extensibility mechanism, that may lead to privilege escalation.

In short, a malicious actor that can execute code as one of the sudoers (in
non-elevated mode), can edit the init file, and add malicious commands to
it. Then he needs to wait for that user to invoke the editor in elevated
mode - and the plugin that was written before, will be loaded with the root
permissions.

The root cause that enables this abuse is basically incomplete separation
between regular and elevated execution modes of the editor (using "sudo").
I can suggest possible solutions to this issue, e.g.: applying better
permissions to the plugins directories.

Reproduction steps:
===================
1)  Add the following ELisp line of code to the init file. It will be
loaded on startup and execute the command “touch /stub.file”, when
“~/.emacs.d/” is the working directory.
        *(let ((default-directory "~/.emacs.d/")) (shell-command "touch
/stub.file"))*
2)  Wait for the user to invoke Emacs in elevated mode. The owner of the
newly created stub file is root.

* This simple command is just for demonstration - of course much more
complicated intentions can be achieved once Emacs is invoked with sudo.

I will be happy to provide more information as needed,
Dor Azouri

[Message part 2 (text/html, inline)]

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Wed, 27 Sep 2017 08:44:34 -0700

>>>>> "DA" == Dor Azouri <dor.azouri <at> safebreach.com> writes:

DA> In short, a malicious actor that can execute code as one of the sudoers
DA> (in non-elevated mode), can edit the init file, and add malicious commands
DA> to it. Then he needs to wait for that user to invoke the editor in
DA> elevated mode - and the plugin that was written before, will be loaded
DA> with the root permissions.

If the user has sudo access to run Emacs, isn't the game already over? They
could M-x shell and rm -fr /, no?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

From: Dor Azouri <dor.azouri <at> safebreach.com>
To: John Wiegley <jwiegley <at> gmail.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Wed, 27 Sep 2017 16:02:42 +0000

[Message part 1 (text/plain, inline)]

sudo access is not required to edit the init file.
The only requirement is that the user is a sudoer (a user that’s in
/etc/sudoers). It is different: a sudoer is a user that is able to elevate
to root after entering root password, it doesn't mean that it is always
doing things as root. Such a user still needs to explicitly "sudo" for
elevated commands (similar to "Run As Administrator" or UAC in Windows).

So what I identified here is that such a user can be used by an attacker to
edit the init file without elevating, even though the same file will be
loaded when elevating the editor.
The flow: after inserting malicious commands to the init script, all the
attacker has to do is wait for the user to elevate Emacs at some point
(under the assumption that the user will at some point elevate Emacs, which
may not always be true). The malicious commands will be run as root.

On Wed, Sep 27, 2017 at 6:44 PM John Wiegley <jwiegley <at> gmail.com> wrote:

> >>>>> "DA" == Dor Azouri <dor.azouri <at> safebreach.com> writes:
>
> DA> In short, a malicious actor that can execute code as one of the sudoers
> DA> (in non-elevated mode), can edit the init file, and add malicious
> commands
> DA> to it. Then he needs to wait for that user to invoke the editor in
> DA> elevated mode - and the plugin that was written before, will be loaded
> DA> with the root permissions.
>
> If the user has sudo access to run Emacs, isn't the game already over? They
> could M-x shell and rm -fr /, no?
>
> --
> John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2
>

[Message part 2 (text/html, inline)]

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

From: Andreas Schwab <schwab <at> suse.de>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Wed, 27 Sep 2017 18:23:59 +0200

On Sep 27 2017, Dor Azouri <dor.azouri <at> safebreach.com> wrote:

> Reproduction steps:
> ===================
> 1)  Add the following ELisp line of code to the init file. It will be
> loaded on startup and execute the command “touch /stub.file”, when
> “~/.emacs.d/” is the working directory.
>         *(let ((default-directory "~/.emacs.d/")) (shell-command "touch
> /stub.file"))*

Why would I want to do that?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

From: Glenn Morris <rgm <at> gnu.org>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Wed, 27 Sep 2017 13:24:41 -0400

Dor Azouri wrote:

> I would like to report a possible abuse one can perform on Emacs's
> extensibility mechanism, that may lead to privilege escalation.
>
> In short, a malicious actor that can execute code as one of the sudoers (in
> non-elevated mode), can edit the init file, and add malicious commands to
> it. Then he needs to wait for that user to invoke the editor in elevated
> mode - and the plugin that was written before, will be loaded with the root
> permissions.

If an attacker has comprised a user account that can run "sudo arbitrary
command", then that's just the same as having compromised the root
account, and so worrying about this on the individual application level
doesn't seem to make sense. Eg they could replace "sudo" with a keylogger.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Wed, 27 Sep 2017 14:03:23 -0400

PS If your concern is about a user account that can only run "sudo
emacs", firstly that seems a bit unlikely, and secondly Emacs is a
big, complicated program that can eg spawn a bash shell. So it should
not be used in a sudo environment where you want to have tight control
over what the sudoer can run.

BTW, if user foo runs "sudo emacs", it consults /root/.emacs, not ~foo/.emacs.
So I don't understand your specific concern with the init file.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Thu, 28 Sep 2017 07:25:32 -0400

tags 28618 + unreproducible
quit

Dor Azouri <dor.azouri <at> safebreach.com> writes:

> Reproduction steps:
> ===================
> 1)  Add the following ELisp line of code to the init file. It will be
> loaded on startup and execute the command “touch /stub.file”, when “~
> /.emacs.d/” is the working directory.
>         (let ((default-directory "~/.emacs.d/")) (shell-command
> "touch /stub.file"))
> 2)  Wait for the user to invoke Emacs in elevated mode. The owner of
> the newly created stub file is root.

As Glenn noted, this doesn't actually work: 'sudo emacs' uses
/root/.emacs, not ~/.emacs.

~$ sudo id
uid=0(root) gid=0(root) groups=0(root)
~$ echo '(let ((default-directory "~/.emacs.d/")) (shell-command "touch /stub.file"))' > .emacs
~$ emacs # *Messages* has "touch: cannot touch '/stub.file': Permission denied"
~$ ls /stub.file
ls: cannot access '/stub.file': No such file or directory
~$ sudo emacs
~$ ls /stub.file
ls: cannot access '/stub.file': No such file or directory

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

From: Dor Azouri <dor.azouri <at> safebreach.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Fri, 29 Sep 2017 12:57:06 +0000

[Message part 1 (text/plain, inline)]

Hi,

This is the output in my env that demonstrates how it works (forgive the
hebrew chars):
*~/.emacs.d$ ls -all*
total 20
drwx------   2 duke duke  4096 ספט 28 20:24 .
drwxr----- 105 duke duke 16384 ספט 28 14:36 ..
*~/.emacs.d$ echo '(let ((default-directory "/opt/")) (shell-command "touch
stub.file"))' > init.el*
*~/.emacs.d$ ls -all /opt/ | grep stub.file*
*~/.emacs.d$ sudo emacs*
*~/.emacs.d$ ls -all /opt/ | grep stub.file*
-rw-r--r--  1 root   root      0 ספט 28 20:25 stub.file
*~/.emacs.d$ rm /opt/stub.file *
rm: remove write-protected regular empty file ‘/opt/stub.file’? yes
rm: cannot remove ‘/opt/stub.file’: Permission denied
*~/.emacs.d$ sudo rm /opt/stub.file *
*~/.emacs.d$ ls -all /opt/ | grep stub.file*
*duke <at> nukem:~/.emacs.d$ sudo ls -all /root/.emacs*
ls: cannot access /root/.emacs: No such file or directory

My env:
GNU Emacs 25.3.2 (tested with old version 23 as well)
Ubuntu 14.04, Kernel 4.13.0

Tested and works as well on Ubuntu 16.04 with emacs24.

Best,
Dor Azouri

On Thu, Sep 28, 2017 at 2:25 PM Noam Postavsky <
npostavs <at> users.sourceforge.net> wrote:

> tags 28618 + unreproducible
> quit
>
> Dor Azouri <dor.azouri <at> safebreach.com> writes:
>
> > Reproduction steps:
> > ===================
> > 1)  Add the following ELisp line of code to the init file. It will be
> > loaded on startup and execute the command “touch /stub.file”, when “~
> > /.emacs.d/” is the working directory.
> >         (let ((default-directory "~/.emacs.d/")) (shell-command
> > "touch /stub.file"))
> > 2)  Wait for the user to invoke Emacs in elevated mode. The owner of
> > the newly created stub file is root.
>
> As Glenn noted, this doesn't actually work: 'sudo emacs' uses
> /root/.emacs, not ~/.emacs.
>
> ~$ sudo id
> uid=0(root) gid=0(root) groups=0(root)
> ~$ echo '(let ((default-directory "~/.emacs.d/")) (shell-command "touch
> /stub.file"))' > .emacs
> ~$ emacs # *Messages* has "touch: cannot touch '/stub.file': Permission
> denied"
> ~$ ls /stub.file
> ls: cannot access '/stub.file': No such file or directory
> ~$ sudo emacs
> ~$ ls /stub.file
> ls: cannot access '/stub.file': No such file or directory
>
>
>

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Fri, 29 Sep 2017 09:24:40 -0400

Dor Azouri <dor.azouri <at> safebreach.com> writes:

> This is the output in my env that demonstrates how it works (forgive
> the hebrew chars):
> ~/.emacs.d$ ls -all
> total 20
> drwx------   2 duke duke  4096 ספט 28 20:24 .
> drwxr----- 105 duke duke 16384 ספט 28 14:36 ..
> ~/.emacs.d$ echo '(let ((default-directory "/opt/")) (shell-command
> "touch stub.file"))' > init.el
> ~/.emacs.d$ ls -all /opt/ | grep stub.file
> ~/.emacs.d$ sudo emacs
> ~/.emacs.d$ ls -all /opt/ | grep stub.file
> -rw-r--r--  1 root   root      0 ספט 28 20:25 stub.file

Hmm, it doesn't happen for me.

    ~/.emacs.d$ ls -all
    total 12
    drwx------  3 npostavs npostavs 4096 Sep 29 09:19 .
    drwxr-xr-x 37 npostavs npostavs 4096 Sep 29 09:19 ..
    drwx------  2 npostavs npostavs 4096 Sep 29 09:19 auto-save-list
    ~/.emacs.d$ echo '(let ((default-directory "/opt/")) (shell-command "touch stub.file"))' > init.el
    ~/.emacs.d$ ls -all /opt/ | grep stub.file
    ~/.emacs.d$ sudo emacs
    [sudo] password for npostavs: 
    ~/.emacs.d$ ls -all /opt/ | grep stub.file

Can you do

    echo '(debug)' > ~/.emacs.d/init.el
    sudo emacs

and show the result backtrace please?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28618 <at> debbugs.gnu.org, Dor Azouri <dor.azouri <at> safebreach.com>
Subject: Re: bug#28618: Emacs Security Issue
Date: Fri, 29 Sep 2017 12:41:26 -0400

On some systems, sudo may preserve HOME by default. Or it may be
optional behaviour with "sudo -E" (eg on Debian 8, it seems).
(Of course, the attacker who has complete control of your user account
could alias "sudo" to "sudo -E".)

Ref eg

https://security.stackexchange.com/questions/18369/issues-with-preserving-home-on-sudo

As it stands, I don't think this is an Emacs issue.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 28618 <at> debbugs.gnu.org, Dor Azouri <dor.azouri <at> safebreach.com>
Subject: Re: bug#28618: Emacs Security Issue
Date: Fri, 29 Sep 2017 18:55:13 -0400

tags 28618 - unreproducible
tags 28618 + notabug
quit

Glenn Morris <rgm <at> gnu.org> writes:

> On some systems, sudo may preserve HOME by default. Or it may be
> optional behaviour with "sudo -E" (eg on Debian 8, it seems).

Ah, that explains the discrepancy then (it's the same with Debian 9,
which I'm using here).

> Ref eg
>
> https://security.stackexchange.com/questions/18369/issues-with-preserving-home-on-sudo
>
> As it stands, I don't think this is an Emacs issue.

I agree.

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

From: Dor Azouri <dor.azouri <at> safebreach.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>, Glenn Morris <rgm <at> gnu.org>
Cc: 28618 <at> debbugs.gnu.org
Subject: Re: bug#28618: Emacs Security Issue
Date: Sun, 01 Oct 2017 15:27:58 +0000

[Message part 1 (text/plain, inline)]

Thanks for checking this problem.
I am convinced by the comments that this is not a pure Emacs issue, though
a step can still be taken to help users protect from this abuse.

For example, Notepad++ on Windows does not load user plugins (located in
AppData) when run as Administrator - unless an Administrator explicitly
puts a specific file in the protected installation directory
("allowAppDataPlugins.xml").

Best,
Dor Azouri


On Sat, Sep 30, 2017 at 1:55 AM Noam Postavsky <
npostavs <at> users.sourceforge.net> wrote:

> tags 28618 - unreproducible
> tags 28618 + notabug
> quit
>
> Glenn Morris <rgm <at> gnu.org> writes:
>
> > On some systems, sudo may preserve HOME by default. Or it may be
> > optional behaviour with "sudo -E" (eg on Debian 8, it seems).
>
> Ah, that explains the discrepancy then (it's the same with Debian 9,
> which I'm using here).
>
> > Ref eg
> >
> >
> https://security.stackexchange.com/questions/18369/issues-with-preserving-home-on-sudo
> >
> > As it stands, I don't think this is an Emacs issue.
>
> I agree.
>

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Dor Azouri <dor.azouri <at> safebreach.com>
Cc: 28618 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#28618: Emacs Security Issue
Date: Thu, 05 Oct 2017 22:23:37 -0400

retitle 28618 Emacs respects $HOME, even when user is root
tags 28618 + wontfix
quit

Dor Azouri <dor.azouri <at> safebreach.com> writes:

> Thanks for checking this problem.
> I am convinced by the comments that this is not a pure Emacs issue,
> though a step can still be taken to help users protect from this
> abuse.
>
> For example, Notepad++ on Windows does not load user plugins (located
> in AppData) when run as Administrator - unless an Administrator
> explicitly puts a specific file in the protected installation
> directory ("allowAppDataPlugins.xml").

It could be different for Windows, but for GNU/Linux I think the
previous messages already explained why this doesn't actually protect
anything.  The user can still get the behaviour they like by setting the
appropriate sudo option.  I don't see why Emacs should override that.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28618 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Dor Azouri <dor.azouri <at> safebreach.com>
Subject: Re: bug#28618: Emacs Security Issue
Date: Fri, 16 Mar 2018 21:43:22 -0400

close 28618
quit

> The user can still get the behaviour they like by setting the
> appropriate sudo option.  I don't see why Emacs should override that.

Seems there is nothing left to say about this.

Previous Next

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