From proff  Fri Sep 27 18:55:47 1996
Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id SAA01948 for best-of-security; Fri, 27 Sep 1996 18:55:47 +1000
Received: (list@localhost) by suburbia.net (8.7.4/Proff-950810) id JAA30630 for proff@suburbia.net; Fri, 27 Sep 1996 09:26:22 +1000
X-Envelope-From: dave@pbi.net  Fri Sep 27 09:26:21 1996
Received: (sendmail@localhost) by suburbia.net (8.7.4/Proff-950810) id JAA30620 for <best-of-security@suburbia.net>; Fri, 27 Sep 1996 09:26:21 +1000
Received: from popper.pbi.net(206.13.1.17)
 via SMTP by suburbia.net, id smtpd30606aaa; Thu Sep 26 23:26:17 1996
Received: from nixon.pbi.net by popper.PBI.net (4.1/PBI-12/1/95)
	id AA01426; Thu, 26 Sep 96 16:20:58 PDT
Received: by nixon.pbi.net (SMI-8.6/SMI-SVR4)
	id QAA13038; Thu, 26 Sep 1996 16:18:15 -0700
From: <dave@pbi.net> (David "I Just Work Here!")
Message-Id: <9609261618.ZM13036@nixon>
Date: Thu, 26 Sep 1996 16:18:14 -0700
X-Mailer: Z-Mail (3.2.1 10apr95)
To: best-of-security@suburbia.net
Subject: Big SecurID Hole??
Cc: perl@pbi.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: proff@suburbia.net

I recently undertook the task of upgrading our SecurID UNIX Aceserver
v1.3, running under SunOS 4.1.4 to Aceserver v2.2, running on a
Solaris 2.5 platform.

Credit goes to Richard Perlman for pointing making me aware of this
potential risk.

I took note of the instructions on setting up a client in the
'Distributing a Configuration Update' on p45 of the install guide:

	"4.	Type:	sdsetup -config
		This will install the new config file... Note that
		simply copying the file into ace/data is not sufficient."

We've tested that, and copying the file and _not_ running sdsetup works.

With this in mind:

The file permission are 777 on /usr/local/ace/data.  As such, any file in
this directory can be modified by _any_ user on the system, e.g. mv
files, rm files, replace valid files with trash data,
r e p l a c e   t h e   S D C O N F . R E C   f i l e   w/t h e i r
  own, move the 'secret' file to another name, etc.  This means that any
user can 1) disable authentication with a few keystrokes (by funking up a
file or two), and 2) potentially point the client's authentication
request to a different master or slave server (I haven't tried this, but
it looks possible).

Just food for thought.  Comments are welcome.

David L. Reoch  dave@pbi.net      ____  ___  _______
Tel  (415) 442-4928              |  _ \| _ \|__   __|   \ | /
(800) 4NE-TPBI                   |  __/|___/   | |     -->*<--
Fax  (415) 442-4999              | |   | _ \ __| |__    / | \
                                 |_|   |___/|_______|PacBellInternet