From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Wed, 30 Nov 2016 12:18:21 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <9b6a0571-b2ae-a5dd-a643-3595e8f71cd6@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480538386 10534 195.159.176.226 (30 Nov 2016 20:39:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2016 20:39:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Paul Eggert , emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 21:39:42 2016 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 1cCBfH-0001qz-Rp for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 21:39:40 +0100 Original-Received: from localhost ([::1]:46425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCBfL-0005T5-Mm for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 15:39:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCBKp-0006Mf-AS for emacs-devel@gnu.org; Wed, 30 Nov 2016 15:18:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCBKo-0000Ry-E4 for emacs-devel@gnu.org; Wed, 30 Nov 2016 15:18:31 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45194) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCBKo-0000RR-0V; Wed, 30 Nov 2016 15:18:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=Te1PkoZqWefjsa1riUz6I4WpxC43QAuVpRS6m9bAcMU=; b=nSUgj6/vGnNKUbeqDzWHFM4uvL/omDM1bdi9zULU4Yx8xUwsBEOQKEDdpBoooSslLN+9pqqCscJK1Zpvpg9cPNBbE7fw+lJXnsxgzCr2bywySu9JXo1wBdl4AE36hkxz1HCfHhp4VmEWeyUes+ebTxrCrxJh7LN/c2hMZaVAERaFXYk2bEnxfybFjE7rAlKgh98JTXXruGyu5Zyjfd2uKDr0ZWxzJoRRqgYehl+72kxntxQ013EVCmAVo7lM4g+C9qdJV94hV3yyCgMWJmnRwG37HP1d9agTLY0eCbdeXm8q5LQxFegkyLLnNgbycrGtLwl0b3/95bmJDEaNSuv94Q==; Original-Received: from [2620:0:1008:100b:bc8e:4940:ab86:ab74] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cCBKm-0008Le-Df; Wed, 30 Nov 2016 12:18:28 -0800 In-Reply-To: (Richard Stallman's message of "Wed, 30 Nov 2016 15:07:37 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209832 Archived-At: On Wed, Nov 30 2016, Richard Stallman wrote: > > I'm more worried about the next level up. Although the dump is pure data > > to the machine, it's not pure data to Elisp. Since the dump would > > contain bytecodes, if attackers can alter the bytecodes then they can > > execute whatever Elisp code they want. > > If they can change installed system files, they are already in control > of the machine, so why worry about this? We're not talking about changing system files on disk. We're talking about changing the image of a system file in memory. Here's the scenario: suppose I can convince your Emacs to parse a carefully crafted network packet that triggers a bug in Emacs and lets me overwrite arbitrary memory in your Emacs process. Today, I win, in the sense that I gain complete control over your Emacs process and can do anything Emacs can do. Address space layout randomization defeats this attack by randomizing the memory layout of the process: if the memory layout is randomized, my arbitrary-memory-overwrite vulnerability doesn't let me do anything interesting, because I don't know *where* and *what* to write using this vulnerability. Now, if I know that your Emacs process is randomized *except* for the location of the dump, I still win, because I can just write to the dump image in order to make Emacs do what I want it to do. Writing the dump works because we'll have mapped it copy-on-write, which is needed in order to make the dump usable as an Emacs heap image. Writes work whether or not the underlying file is itself writable. Paul is absolutely right that we shouldn't defeat ALSR this way. Maybe we can randomize the dump base address *per* *machine*? That way, remote attackers would still be frustrated. We'd still be making Emacs users vulnerable to hostile users running on the same machine. (Or we could just randomize per-user and dump Emacs the first time it runs for a particular user? If we do that after loading ~/.emacs, we also improve people's startup time. Invalidating and regenerating the dump when configuration changes would be a challenge though.)