From owner-freebsd-hackers Mon Nov 25 12:34:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA07089 for hackers-outgoing; Mon, 25 Nov 1996 12:34:39 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA07071 for ; Mon, 25 Nov 1996 12:34:24 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA23134; Mon, 25 Nov 1996 13:17:31 -0700 From: Terry Lambert Message-Id: <199611252017.NAA23134@phaeton.artisoft.com> Subject: Re: looking for an idea To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 25 Nov 1996 13:17:31 -0700 (MST) Cc: sprice@hiwaay.net, hackers@freebsd.org In-Reply-To: <199611251548.KAA05926@skynet.ctr.columbia.edu> from "Bill Paul" at Nov 25, 96 10:48:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What you're suggesting is basically security through obscurity. > This would only work if we were a commercial OS like Slowlaris where > source code is not available and the vendor intentionally fails to > document the unerlying interface. Since we provide all source code, > there's nothing to stop the user from splitting the RPC library out > of the libc source tree (or making his own libc), modifying a few > things, and then linking a malicious program that doesn't play by > the rules. > > What I want is a way for keyserv to learn the UID of the caller that > can't be spoofed unless an attacker can: > > - compromise keyserv itself > - compromise the kernel > - break root through some other means, in which case all bets are off > anyway > > Again, it seems like the SysV IPC system calls are the only ones that > do what I want, which is really too bad. You'd think BSD would have > something equivalent. Well, BSD has the IPC calls, you could use them. But there is nothing that will prevent spoofing from an exceptionally clever person. For instance, I can spoof a Netrek server quite easily by hacking my socket code. All I have to do is let a blessed client respond to interrogations about whether or not it is blessed, and have my own ("borg") client handle/generate all other client/server traffic. Voila: I have just destroyed the ability of an RSA interrogation to determine that the client generating the traffic is not a "borg" because I have just split a socket into two entities, and the key exchange mechanism assumes (incorrectly) that sockets are indivisible entities. There is no way to stop a sufficiently determind person from engaging in an interposition attack on any network transport, short of one time pads. Even a Diffie/Helmen is vunerable to an identity switch, where an interposing party gives the remote side his key instead of your key, and give you his key, and then unwraps and rewraps the data in both directions. Sure, you can't (easily) use a route-broadcast attack for insertion, but it can be done. Even the IPC code *could* be hacked for an interposition attack, the same way. Your program has to make some assumptions somewhere, and when it does, it becomes vunerable. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.