[10351] in bugtraq
Re: stored credentials was: Netscape 4.5 vulnerability
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@VT.EDU)
Sun Apr 25 13:58:18 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <25752.925027202.1@black-ice.cc.vt.edu>
Message-Id: <199904250800.EAA24158@black-ice.cc.vt.edu>
Date: Sun, 25 Apr 1999 04:00:02 -0400
Reply-To: Valdis.Kletnieks@VT.EDU
From: Valdis.Kletnieks@VT.EDU
X-To: jogata@NODC.NOAA.GOV
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Fri, 23 Apr 1999 17:06:33 EDT."
<3720E0D9.DA3A5AB3@nodc.noaa.gov>
On Fri, 23 Apr 1999 17:06:33 EDT, Jefferson Ogata <jogata@NODC.NOAA.GOV> said:
> What if the OS itself maintains a database of randomized encryption keys,
> and allows access to a key only to a binary whose inode and filesystem
> matches the one under which the key was stored. I'm being needlessly
> specific here, but I lack the vocabulary to describe this in more general
> terms.
1) This data must, itself, be stored someplace. Where, and how?
Obviously, this needs encrypting too. What do you use for a key for THAT?
(Remember, the key has to survive a reboot).
2) Mapping it to inode/filesystem is a Bad Idea.
2A) You upgrade the product, you lose.
2B) You restore the filesystem from tape, you lose.
2C) An attacker finds a way to grab that inode number for himself, you lose.
I won't even get into possible hassles here with symlink confusion,
NFS issues (remember, dickless clients DO exist), and other warts
that we have to deal with in the real world.
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
