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: Sat, 3 Dec 2016 13:37:19 -0800 Message-ID: <21236078-89c3-299b-46be-b4cc3ad488bc@dancol.org> 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1480801088 12616 195.159.176.226 (3 Dec 2016 21:38:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2016 21:38:08 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 22:38:02 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 1cDI0P-00022v-HG for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 22:38:01 +0100 Original-Received: from localhost ([::1]:52587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDI0T-0001DL-7N for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 16:38:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDHzr-0001DF-3M for emacs-devel@gnu.org; Sat, 03 Dec 2016 16:37:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDHzn-0005b4-W2 for emacs-devel@gnu.org; Sat, 03 Dec 2016 16:37:27 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:43112) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cDHzn-0005aa-M0; Sat, 03 Dec 2016 16:37:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=uhnu27W26h12YdARR5VP+zf62l57l3c4nGEAMH7hmM0=; b=mXJjdWngglQGZUOc3UeejfTUOemojatVwqBwWJ78862SP329iK+3xazm+b2YlXjsx6WthZvWdryki9WFnTRnq6/SSjNBBoDCFuBmPs3SH3e9LCLDqEVLm6RMLDqOvIc2/LXCmFzNFQZ0oAg/Z9qDtnJjUYp+IeFr3Pzm09QzGgJpLCJTovgwCkBAqDSa+/PisJFk2IZLKNuodR4hFJhAP8qGVBS+D1uJx5jYCpeIumjfxsw21rYMxC/UmeyoDU9dorvDgnWbmTKZ+ZK2Rtzr1zt6sf/yP4bTyKtUZcsuWv9bk629Pt9RGfw0IB/5LV6CcwjtgzxL/dO3lPU61lKRTA==; Original-Received: from c-73-140-245-253.hsd1.wa.comcast.net ([73.140.245.253] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cDHzm-0007oA-8l; Sat, 03 Dec 2016 13:37:22 -0800 In-Reply-To: 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:210002 Archived-At: On 12/03/2016 01:32 PM, Richard Stallman wrote: > > 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. > > That reasoning is logically valid -- but is it really a plausible > scenario that Emacs's parsing of a packet would have a bug that > clobbers other unrelated memory? Bitter experience with other software has shown the answer to be "yes". The bug doesn't even have to be in Emacs --- it can be in a library we use. For example, we link against libpng when available, and libpng has had repeated security problems over the years: https://www.cvedetails.com/vulnerability-list/vendor_id-7294/Libpng.html Gnus uses libpng to display images in news and email. All of this means that the scenario I've described can come to pass merely by browsing emacs-devel. I'd prefer to protect us against it. (I don't want to single out libpng --- other libraries have bugs too. libpng is just the first one that came to mind.) > What Emacs does with the contents of an incoming packet is mainly > to turn it into Lisp objects and make that available at Lisp level. > That means not much opportunity for such a bug to occur. If you think so and are willing to take on this risk yourself, you can build a non-position-independent Emacs and get security and performance equivalent to what you have today. There are lots of hardening measures available to modern software, all optional, and we should allow users to use them.