|
From: | Daniel Colascione |
Subject: | Re: Preview: portable dumper |
Date: | Sat, 3 Dec 2016 13:37:19 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |