From xemacs-m  Wed Aug 27 23:53:12 1997
Received: from firewall1.Lehman.COM (firewall.Lehman.COM [192.147.65.66])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id XAA06459;
	Wed, 27 Aug 1997 23:53:11 -0500 (CDT)
Received: from relay.messaging-svcs2.lehman.com by firewall1.Lehman.COM (8.8.6/8.6.12) id AAA01723; Thu, 28 Aug 1997 00:53:09 -0400 (EDT)
Received: from cfdevx1.lehman.com by relay.messaging-svcs2.lehman.com (8.8.5/8.8.5) id AAA10495; Thu, 28 Aug 1997 00:52:38 -0400 (EDT)
Received: from localhost by cfdevx1.lehman.com (4.1/Lehman Bros. V1.6)
	id AA02740; Thu, 28 Aug 97 00:52:36 EDT
Message-Id: <9708280452.AA02740@cfdevx1.lehman.com>
Reply-To: Rick Campbell <rickc@lehman.com>
X-Face: #<@""pDMxa>Mr$Wp[^l7e1RwB6]&7pRp,f=|)6y5?t45X$y(xx.x^?k~;-d>s:SL86Qt82U
 'M!RC3LrDvD/LjiYdGO!:\/\qx?YabgGC9%xw5%0-W05LRvyu9vB9TYk%5PN|C*0WgrXD-L0'g3j;h
X-Windows: Form follows malfunction.
Organization: Lehman Brothers Inc.
From: Rick Campbell <rickc@lehman.com>
To: Bart Robinson <lomew@cs.utah.edu>
Cc: SL Baur <steve@xemacs.org>,
        jari.aalto@poboxes.com (pgp preferred ssjaaa@uta.fi | pgp -fka),
        xemacs-beta@xemacs.org
Subject: read-passwd security (was Re: PGP security threat alert)
In-Reply-To: Your message of "Wed, 27 Aug 1997 21:51:23 MDT."
             <199708280351.VAA09675@fast.cs.utah.edu> 
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
 boundary="pgp-sign-Multipart_Thu_Aug_28_00:52:25_1997-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
Date: Thu, 28 Aug 1997 00:52:32 -0400
Sender: rickc@lehman.com

--pgp-sign-Multipart_Thu_Aug_28_00:52:25_1997-1
Content-Type: text/plain; charset=US-ASCII

    Date: Wed, 27 Aug 1997 21:51:23 -0600
    From: Bart Robinson <lomew@cs.utah.edu>
    
    I'm not an expert on elisp internals,

Neither am I.

    but if one follows the recommendations in passwd.el (zeroing the
    returned password) then I believe this is a non-issue.

I almost agree, but there are some issues remaining:

 - If a core dump was forced after read-passwd returned, but before
   the result was zeroed, the core should contain the string.
 - If a GC occurred during that timing window, and a core dump was
   forced later, the core might contain the string.

If one were *really* anal :-) they might notice that even a zeroed out
string reveals the length of the string thus seriously reducing the
search space for a brute force attack.

Anyway, while someone who can force a core dump can almost certainly
compromise your security in lots of other ways, I think that it makes
sense to try to limit the exposure as much as possible.  Different
people have different threat models, but I think that the defaults
should be as secure as possible.  There's no need for this to be the
weakest link.  How about something like this?

  (let ((record-keystrokes nil)
	(gc-cons-threshold most-positive-fixnum)
	(pw nil))
    (unwind-protect
	 (progn
	   (setq pw (read-passwd "Password: "))
	   ...)
      (cond (pw (fillarray pw 0)))))

Something that did the equivalent of
  (process-send-string PROCESS (read-passwd ...))
without creating the intermediate string at all would be a nice tool
to have around for tightening this sort of thing up further.

			Rick

--pgp-sign-Multipart_Thu_Aug_28_00:52:25_1997-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNAUEC1tTztlqB385AQF1wwP/dQXz9Q3i3j2o/y0ndSk3jIKQS5JSzG/l
QjEPzHyoHKJ7peOp48wZ36KjxLdSFJ2NmYnRFR0msslFsH8c+RouOQFjR8LVlOgm
qqvC1fZkPUmVE2rStnJlJcEyXpENMAykMEJ3WBAV65TcZpN3UjmRDaowF41wNvNf
64qzqPCJDd4=
=Lg5v
-----END PGP MESSAGE-----

--pgp-sign-Multipart_Thu_Aug_28_00:52:25_1997-1--

