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: Tue, 06 Dec 2016 16:04:36 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Tue, Dec 06 2016, Jacob Bachmeyer wrote:
> Daniel Colascione wrote:
>> On Tue, Dec 06 2016, Jacob Bachmeyer wrote:
>>   
>>>> (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.)
>>>>       
>>> That should not be too difficult, if you can track which files were
>>> read when creating the dump and store some fields from the stat(2)
>>> information on those files in the dump.  I am using this approach in a
>>> packaging system that I am developing to close a race between
>>> attaching a file to an archive handle and actually writing the
>>> archive, at which time the digest of the file is computed.  (I wanted
>>> to avoid reading input files twice.)
>>>
>>> I take a conservative approach and verify that the
>>> st_{ino,dev,size,blocks,{m,c}tim{e,.tv_nsec}} fields are all
>>> unchanged.  For my use, writing the archive produces a hard failure if
>>> this check fails; for Emacs, failing that check would indicate "time
>>> to rebuild the fast-load cache".
>>>
>>>
>>> On the other hand, I think that per-user dumps are a bad idea--the
>>> Emacs dump is an inscrutable binary blob
>>>     
>>
>> Users run lots of inscrutable binary blobs.  At least this one is made
>> from free software.  ("Sure", you might think, "we can just have the
>> system Emacs *sign* the blob." But an attacker could just read the
>> private key right out of the Emacs binary.  You really can't win.)
>>   
>
> "A strange game.  The only winning move is not to play."
>
> The system Emacs dump cannot be modified by a user's account.
> A per-user dump could be.  Currently, this particular persistence
> option for a (user-level) intruder does not exist; I argue that we
> should think very carefully before creating it.  (No objection to
> using this for the system Emacs dump, though.)

And you don't have any binaries under $HOME? No elc files? No
.pyc files? Really? Are you sure that you can read a pyc file and
detect exploit code?

> A counter-proposal to signing the dump:  upon loading the dump,
> display a digest or randomart-like image that summarizes the dump.
> Users who care can then notice if the dump changes when it should not.

That'll annoy users, and I've never seen a real human being pay
attention to those SSH key fingerprint ASCII art things, much less some
weird art thing that Emacs might display on startup.

>>> and therefore a good place
>>> for an intruder to hide persistent nastiness.  This could allow an
>>> intruder to add a back door to a user's Emacs in a difficult-to-detect
>>> manner while needing only temporary access to that user's account,
>>> say, from exploiting any program that user runs.
>>>     
>>
>> I don't think attempting to defend against this sort of attack, at least
>> the way you suggest, is desirable.  An attacker who can modify user
>> files like that has already won --- there are all sorts of user-mode
>> "rootkits" that hide themselves very effectively.
>>
>> https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283
>>   
>
> Some of the comments on that blog are appropriate here.  This kind of
> "not a security problem because <insert excuse here>" is a position
> for which Microsoft is infamous.

That the author of that post works for Microsoft is irrelevant.

"Security" is a meaningless word.  You need to be secure *against*
something.  You need a threat model.  Your threat model is an attacker
who already has the ability to overwrite files under $HOME.  Such an
attacker can do anything anyway (e.g., LD_PRELOAD something in
~/.profile that presents whatever secure fantasy the attacker wants to
present), so your proposed security measure doesn't actually help ---
and it has costs.

Sorry: I don't think that forgoing user dumps on security grounds makes
any sense.  There might be plenty of other reasons not to implement the
feature, but security isn't one of them.

That's not "an excuse" --- as if implementing any random feature
somebody proposes in the name of "security" is some moral imperative, we
need to be excused from our duty to perform it --- it's reason.

> The issue that I see is that a
> per-user Emacs dump (which of course must be writable by the user) is
> a place (platform-independent, even!) where an attacker can hide a bit
> of code to make future access easier, even after the exploit that
> initially allowed the attacker to get in is fixed.

System compromises are never "fixed": there are too many places for
attackers to hide code.  If your account has been compromised, you lose.
Restore from backup.



reply via email to

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