From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?U8O4cmVuIFBpbGfDpXJk?= Newsgroups: gmane.emacs.devel Subject: Re: Closing a privilege escalation Date: Wed, 25 Apr 2018 19:10:25 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e0824b178d67c20056aaf5823" X-Trace: blaine.gmane.org 1524676163 23659 195.159.176.226 (25 Apr 2018 17:09:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Apr 2018 17:09:23 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 25 19:09:19 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fBNut-0005zo-Nt for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2018 19:09:16 +0200 Original-Received: from localhost ([::1]:38235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBNx0-0002H3-F8 for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2018 13:11:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBNwE-0002Fm-KC for emacs-devel@gnu.org; Wed, 25 Apr 2018 13:10:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBNwA-0002wd-Fy for emacs-devel@gnu.org; Wed, 25 Apr 2018 13:10:38 -0400 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:38183) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fBNw3-0002of-LI; Wed, 25 Apr 2018 13:10:27 -0400 Original-Received: by mail-wm0-x22d.google.com with SMTP id i3so8089531wmf.3; Wed, 25 Apr 2018 10:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1pIMgd11lGLBEcs6G2wfiC1gKIf11AOaXq7NZzDZ0lo=; b=CVAwcmBMt1Tpevj/kRQCY28LRR4ezJ7q3oBslL+PmrIFmBMFnhhKvuJ3HGCmqif1+H 8qg325wHRiu38cRxMtuQ93dt3Hf6BOP7kJRTs+rTUTTLe90JAvo4u1PndMd3Ml0botCZ lcH0QTVrhwEA701NU35Tg4cB7h702aHnYsQMtNHkVykZwbqECPj4iT9huAD13efxFtB2 O9mssu0rufSf/uIhsTE6EhU0VPYxL4Y4RD/KEhw7cCDyZAwawTjRNSo7vv5QmbT2mngC v0KUE6mO3c8BuFLLABDBaqCtO+Hi3rtPN1dS+ENKEG+SaH57T03DZ9monTXZqn8Dc41q aK+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1pIMgd11lGLBEcs6G2wfiC1gKIf11AOaXq7NZzDZ0lo=; b=D3VPtypFkIzU1YVWs2aBJGLVowwyZzfc4J8CNmuahTk3o5lgJgGtZtisUBeKSiFaPq plIc9cDZzTa83GSx/7DwpjwXcJ0Zrp/7/6GH/V7WFutNyGpiUKSmgXE/39khd24LIUTf RWC8g8HSaxv+fcvk7agZ/sY8AxmVyHK3Te6zJxS6jRp0M6U8lwWRfvSty8vLdOM5GjNX SYm38f5F9pQ5DkjYRjztNVmG1NBcoWbqv54FgAej/NEnKWhNNko/0S+quNLipf8+U1ek DxiGmT/+eCayXt5Z+GJth5y/kk21ji5Bhx7qRiVKxIo0I7APXp5EMBbF713d6kavVTBH XYZg== X-Gm-Message-State: ALQs6tCwAomD19mLSgSIaaIe+/VUG4TEg+NtPX/+ZBsJKhP6MihLXHQQ rOWZwm0JCXN8AkdqQfZvqs/YGCvwy7PU1QVM2kj4OQ== X-Google-Smtp-Source: AIpwx49DOqpKS11RIlsqEffKUul4UU+2Cjg024m2s5b9hwarnQqKHHmgFXdpzza0YB4npvgGPs7xSqOUJF47EOjbSE0= X-Received: by 10.80.157.202 with SMTP id l10mr39438164edk.192.1524676225824; Wed, 25 Apr 2018 10:10:25 -0700 (PDT) Original-Received: by 10.167.213.195 with HTTP; Wed, 25 Apr 2018 10:10:25 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224883 Archived-At: --089e0824b178d67c20056aaf5823 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018 at 6:47 PM, Glenn Morris wrote: > > This was previously discussed in bug#28618. > I think the discussion suffers from lack of a clear example, so let me > try to give one: > > A normal (uncompromised) user account inadvertently installs a malicious > Emacs package that contains exploit code that waits to be run as root. > > This user then sudos (to root) in such a way that HOME is not reset to > that of root. They then run Emacs, which executes the malicious package > code as root. > > This entire class of exploit can be avoided by suitable sudo options > (always_set_home etc), but that doesn't necessarily mean that Emacs > should not do something about it. > > It seems to me, that "if UID = 0, set user-init-file, user-emacs-directory > etc to those of root" is a simpler solution that the one you propose. > > This effectively enforces the always_set_home feature of sudo in Emacs. > This may annoy some people, but you can't make the behaviour optional, > because then the bad code could disable it. Some might say that people > using sudo without set_home want the behaviour the way it is now, but > maybe we could argue that it is not always a conscious choice. > > By the way, what about sudo called from Tramp? Let's suppose the > malicious package subverts the sudo syntax that is built-in to Emacs. > How to defend against that (ie people running sudo within Emacs)? > > If a clever hacker is able to run code on your computer as your account he could just install a fake sudo program that snatches the password. And then modify the path in your .bashrc etc. to execute this script instead of the build in. --089e0824b178d67c20056aaf5823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Apr 25, 2018 at 6:47 PM, Glenn Morris <rgm@gnu.org> wr= ote:

This was previously discussed in bug#28618.
I think the discussion suffers from lack of a clear example, so let me
try to give one:

A normal (uncompromised) user account inadvertently installs a malicious Emacs package that contains exploit code that waits to be run as root.

This user then sudos (to root) in such a way that HOME is not reset to
that of root. They then run Emacs, which executes the malicious package
code as root.

This entire class of exploit can be avoided by suitable sudo options
(always_set_home etc), but that doesn't necessarily mean that Emacs
should not do something about it.

It seems to me, that "if UID =3D 0, set user-init-file, user-emacs-dir= ectory
etc to those of root" is a simpler solution that the one you propose.<= br>
This effectively enforces the always_set_home feature of sudo in Emacs.
This may annoy some people, but you can't make the behaviour optional,<= br> because then the bad code could disable it. Some might say that people
using sudo without set_home want the behaviour the way it is now, but
maybe we could argue that it is not always a conscious choice.

By the way, what about sudo called from Tramp? Let's suppose the
malicious package subverts the sudo syntax that is built-in to Emacs.
How to defend against that (ie people running sudo within Emacs)?


If a clever hacker = is able to run code on your computer as your account he could just install = a fake sudo program that snatches the password. And then modify the path in= your .bashrc etc. to execute this script instead of the build in.
--089e0824b178d67c20056aaf5823--