From owner-freebsd-hackers Tue Oct 24 21:21:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA26289 for hackers-outgoing; Tue, 24 Oct 1995 21:21:36 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA26264 ; Tue, 24 Oct 1995 21:21:24 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id VAA16934; Tue, 24 Oct 1995 21:20:41 -0700 From: Julian Elischer Message-Id: <199510250420.VAA16934@ref.tfs.com> Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! To: davidg@Root.COM Date: Tue, 24 Oct 1995 21:20:41 -0700 (PDT) Cc: mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199510250338.UAA27854@corbin.Root.COM> from "David Greenman" at Oct 24, 95 08:38:46 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2426 Sender: owner-hackers@freebsd.org Precedence: bulk > > The client should ignore NFS packets from hosts that it's not talking to or > doesn't know about, and that's what all 4.4BSD derived OSs do. unfortunatly it doesn't gain you anything in security to do so however > This is obviously flamebait and I'm not going to respond to it. I'm pretty sure FreeBSD can be made to do the same thing too, given the right icmp packets > > >Sorry for the rambling discourse, but I need this fixed or I can't > >use FreeBSD. At the least, can the "Sun behavior" I need be added > >as an option to the mount command? like most misguided security attempts it should be optional. > > If you choose not to use my suggested work-around, then I guess you can't > use FreeBSD. For the NFS server, FreeBSD (and all other 4.4BSD derived systems) well 4.4BSD derived OS's comprise OSF/1, NetBSD, FreeBSD and BSD/OS. Not exactly aearthshaking combination, and I wouldn't be surprised to see that OSF1 might act differently.. (they are actually net2.5 based) > keep an authentication list in the kernel that is constructed from > /etc/exports. For the NFS client, FreeBSD requires that replies to its RPC > requests come from the same address that they were issued to. If it didn't > work this way, then *anyone* could send bogus udp datagrams with hand-tailored > RPC calls/replies to you and as long as that someone can come up with a file > handle (which is relatively easy), he can do unchecked file operations and > bypass the system security. So? I can make my machine have any address you wish.. and probably still get a packet to your machine.. I mean the source address is not looked at for routing.. It's a security feature to keep out SIMPLE attacks but fails on any really dedicated attack. anyway we're talking being a CLIENT here.. you're talking about being a server, with the exports list.. I didn't notice the exports list being involved in the client side of things.. I think that if we get a patch to make this optional, then we should allow it to be included.. certainly there should be some way to tell NFS that two addresses are equivalent. A Mount option MIGHT work, but you'd have to feed it an alternate IP address.. (not a name) possibbly a routing table entry could be used to do it.. > The best I could offer you would be a kernel option to disable this > security, but I'll say right now that this *won't* be in the 2.1 release. > > -DG >