emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preview: portable dumper


From: Daniel Colascione
Subject: Re: Preview: portable dumper
Date: Wed, 30 Nov 2016 12:18:21 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]