Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 07 Feb 2014 00:05:06 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Ted Zlatanov writes:
>> Inside Emacs, there would have to be a passphrase popup in the
>> minibuffer or elsewhere that can't be faked from ELisp but must
>> come from the "secure core."

SJT> Ted, there is no "secure core" in an Emacs Lisp application.  That was
SJT> the main point of the defadvice.  If *your* Lisp program can invoke a
SJT> password popup, so can *my* sleazebag defadvice.

Yes, that would be an attack target internally, obviously.  But a) I was
originally talking about how calling out to external programs makes it
hard to tell if the popup is authentic or not[1]; and b) this needs work
and discussion, but I think it's a valuable use case.

What do you think happens when you open a .gpg file using GnuPG
externally, even disregarding the OS channels traveled?  That data is
certainly not safe from defadvice.  I try to protect passwords in
auth-source by wrapping them in closures; EPA/EPG simply throws the data
into a buffer.  This is *not* saying the EPA/EPG design is bad, only
that Emacs as a whole could use a way to hide "data not intended for
direct user inspection" better, and provide for a "tainting" trace of
data (to use the Perl term).  For special files like authinfo.gpg, you
certainly don't need the whole file in memory just to grab one line.

SJT> Not at all.  The presence of those primitives is an attractive
SJT> nuisance, encouraging security neophytes to roll-their-own authn/authz/
SJT> crypto systems.  If you want horror stories, there are plenty archived
SJT> at the RISKS forum and on CERT.  Statistically speaking, availability
SJT> of these functions will mean somebody *will* get screwed by a self-
SJT> injected security bug.
>> 
>> I can't debate what could happen, that's what "hypothetical" means.

SJT> Security is all about what *could* happen if you're not careful.  If
SJT> you aren't already thinking carefully about that, I don't understand
SJT> why you're doing this!

OK then, let's hypothesize.  I don't think the presence of these
primitives will make the situation worse by flooding us with badly
implemented crypto.  I may be wrong, but it just doesn't seem likely.
One of the things you learn from RISKS is that generally, things tend to
work out all right as long as the source code is open and
vulnerabilities are disclosed quickly.

Realistically speaking, attacks against Emacs are extremely unlikely
unless specific people are targeted.  The user population is too small.
We also don't generally have anything all that secret or precious stored
in Emacs (except RMS, who has a million Bitcoins and is the real Satoshi
Nakamoto, you heard it here first).  So I think comparing the risks of
what I'm proposing to, say, bank databases or airplane software is a bit
ambitious.

Ted

[1] One of my first tasks as a sysadmin, many years ago on AIX, was to
stop some attackers with internal access.  They had set up a login
system that decrypted some special files with a password and wiped them
clean on logout.  Their encryption password, for technical and practical
reasons, was the fastest way to stop them completely.  So I simply made
a prompt that looked the same as the normal one, grabbed their password,
and told them "wrong password, reenter please."  It then wiped itself
out of their login files.