Re: Preview: portable dumper

[Daniel Colascione]

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.