* bug#28618: Emacs Security Issue
@ 2017-09-27 13:56 Dor Azouri
2017-09-27 15:44 ` John Wiegley
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Dor Azouri @ 2017-09-27 13:56 UTC (permalink / raw)
To: 28618
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1633 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#28618: Emacs Security Issue
2017-09-27 13:56 bug#28618: Emacs Security Issue Dor Azouri
@ 2017-09-27 15:44 ` John Wiegley
2017-09-27 16:02 ` Dor Azouri
2017-09-27 16:23 ` Andreas Schwab
` (2 subsequent siblings)
3 siblings, 1 reply; 14+ messages in thread
From: John Wiegley @ 2017-09-27 15:44 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
>>>>> "DA" == Dor Azouri <dor.azouri@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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#28618: Emacs Security Issue
2017-09-27 15:44 ` John Wiegley
@ 2017-09-27 16:02 ` Dor Azouri
0 siblings, 0 replies; 14+ messages in thread
From: Dor Azouri @ 2017-09-27 16:02 UTC (permalink / raw)
To: John Wiegley; +Cc: 28618
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]
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@gmail.com> wrote:
> >>>>> "DA" == Dor Azouri <dor.azouri@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
>
[-- Attachment #2: Type: text/html, Size: 2208 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-27 13:56 bug#28618: Emacs Security Issue Dor Azouri
2017-09-27 15:44 ` John Wiegley
@ 2017-09-27 16:23 ` Andreas Schwab
2017-09-27 17:24 ` Glenn Morris
2017-09-28 11:25 ` Noam Postavsky
3 siblings, 0 replies; 14+ messages in thread
From: Andreas Schwab @ 2017-09-27 16:23 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
On Sep 27 2017, Dor Azouri <dor.azouri@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-27 13:56 bug#28618: Emacs Security Issue Dor Azouri
2017-09-27 15:44 ` John Wiegley
2017-09-27 16:23 ` Andreas Schwab
@ 2017-09-27 17:24 ` Glenn Morris
2017-09-27 18:03 ` Glenn Morris
2017-09-28 11:25 ` Noam Postavsky
3 siblings, 1 reply; 14+ messages in thread
From: Glenn Morris @ 2017-09-27 17:24 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-27 17:24 ` Glenn Morris
@ 2017-09-27 18:03 ` Glenn Morris
0 siblings, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2017-09-27 18:03 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-27 13:56 bug#28618: Emacs Security Issue Dor Azouri
` (2 preceding siblings ...)
2017-09-27 17:24 ` Glenn Morris
@ 2017-09-28 11:25 ` Noam Postavsky
2017-09-29 12:57 ` Dor Azouri
3 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2017-09-28 11:25 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
tags 28618 + unreproducible
quit
Dor Azouri <dor.azouri@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
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#28618: Emacs Security Issue
2017-09-28 11:25 ` Noam Postavsky
@ 2017-09-29 12:57 ` Dor Azouri
2017-09-29 13:24 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Dor Azouri @ 2017-09-29 12:57 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 28618
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]
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@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@users.sourceforge.net> wrote:
> tags 28618 + unreproducible
> quit
>
> Dor Azouri <dor.azouri@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
>
>
>
[-- Attachment #2: Type: text/html, Size: 3120 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-29 12:57 ` Dor Azouri
@ 2017-09-29 13:24 ` Noam Postavsky
2017-09-29 16:41 ` Glenn Morris
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2017-09-29 13:24 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
Dor Azouri <dor.azouri@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?
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#28618: Emacs Security Issue
2017-09-29 13:24 ` Noam Postavsky
@ 2017-09-29 16:41 ` Glenn Morris
2017-09-29 22:55 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Glenn Morris @ 2017-09-29 16:41 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 28618, Dor Azouri
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-29 16:41 ` Glenn Morris
@ 2017-09-29 22:55 ` Noam Postavsky
2017-10-01 15:27 ` Dor Azouri
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2017-09-29 22:55 UTC (permalink / raw)
To: Glenn Morris; +Cc: 28618, Dor Azouri
tags 28618 - unreproducible
tags 28618 + notabug
quit
Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#28618: Emacs Security Issue
2017-09-29 22:55 ` Noam Postavsky
@ 2017-10-01 15:27 ` Dor Azouri
2017-10-06 2:23 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Dor Azouri @ 2017-10-01 15:27 UTC (permalink / raw)
To: Noam Postavsky, Glenn Morris; +Cc: 28618
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
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@users.sourceforge.net> wrote:
> tags 28618 - unreproducible
> tags 28618 + notabug
> quit
>
> Glenn Morris <rgm@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.
>
[-- Attachment #2: Type: text/html, Size: 1884 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* bug#28618: Emacs Security Issue
2017-10-01 15:27 ` Dor Azouri
@ 2017-10-06 2:23 ` Noam Postavsky
2018-03-17 1:43 ` Noam Postavsky
0 siblings, 1 reply; 14+ messages in thread
From: Noam Postavsky @ 2017-10-06 2:23 UTC (permalink / raw)
To: Dor Azouri; +Cc: 28618
retitle 28618 Emacs respects $HOME, even when user is root
tags 28618 + wontfix
quit
Dor Azouri <dor.azouri@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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-03-17 1:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-27 13:56 bug#28618: Emacs Security Issue Dor Azouri
2017-09-27 15:44 ` John Wiegley
2017-09-27 16:02 ` Dor Azouri
2017-09-27 16:23 ` Andreas Schwab
2017-09-27 17:24 ` Glenn Morris
2017-09-27 18:03 ` Glenn Morris
2017-09-28 11:25 ` Noam Postavsky
2017-09-29 12:57 ` Dor Azouri
2017-09-29 13:24 ` Noam Postavsky
2017-09-29 16:41 ` Glenn Morris
2017-09-29 22:55 ` Noam Postavsky
2017-10-01 15:27 ` Dor Azouri
2017-10-06 2:23 ` Noam Postavsky
2018-03-17 1:43 ` Noam Postavsky
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).