Date: Tue, 26 Nov 1996 12:24:21 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: terry@lambert.org (Terry Lambert) Cc: sprice@hiwaay.net, hackers@freebsd.org Subject: Re: looking for an idea Message-ID: <199611261724.MAA09233@skynet.ctr.columbia.edu> In-Reply-To: <199611252017.NAA23134@phaeton.artisoft.com> from "Terry Lambert" at Nov 25, 96 01:17:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Terry Lambert had to walk into mine and say: [chop] > > 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. It has them, yes, but they can be configured out of the kernel. What I'm worried might happen is that somebody will see the SYSV* options in their kernel config file one day and say "Aw, I don't need those," then build a kernel without them and suddenly, Secure RPC doesn't work on his machine anymore. Note that even if I stuck a big sign above the options in the GENERIC config file that said "Don't touch! No user serviceable parts inside!", somebody would still do it. Then they'd come and asks questions here or complains that it's a bug, since nothing they did could have possibly caused the problem. > But there is nothing that will prevent spoofing from an exceptionally > clever person. Well, yeah, but how many of those do we have running around who aren't encumbered by non-disclosure agreements. :) > 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. But I'm not using a network transport. I'm using AF_UNIX sockets (and potentially SysV message queues). The transport medium is the kernel, and one side of the transaction is a process owned by root which I can't control (unless I'm the admin). > 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. Yes, but this assumes that somebody with root access to the machine has somehow modified either the kernel or keyserv in order to make it possible for the IPC mechanism to be spoofed, thereby making it possible to intercept other users' secret keys (which is what I'm trying to prevent). This could happen if the owner/administrator of the machine was out to screw his users, or if an attacker managed to break into the system and gain root access (and had the means to create a compromised kernel or keyserv executable). Of course, if somebody breaks root on your machine then you're in deep trouble anyway. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261724.MAA09233>