Date: Tue, 24 Oct 1995 20:38:46 -0700 From: David Greenman <davidg@Root.COM> To: mikebo@tellabs.com Cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! Message-ID: <199510250338.UAA27854@corbin.Root.COM> In-Reply-To: Your message of "Tue, 24 Oct 95 21:45:17 CDT." <9510250245.AA11614@tellabk.tellabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>This isn't something that can be changed on a Sun. Even configuring a >Sun with static routes won't really solve the problem, as someone/sometime >is bound to request a mount from an interface which is not the server's >default route. In that case, the reply would come from the interface >tagged with the default route. The onus is on the client to deal with it... 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. >This situation is correctly handled by every commercial UNIX OS I've >worked with. I don't know what security implications that has, but I >do know that FreeBSD's NFS (and so the whole OS) is useless to me >(and others running in a similar environment) unless it works with >Suns and plays by their rules. If I can't use the OS, the security >doesn't do me a damn bit of good! > >I can document this behavior in SunOS, Solaris and HP/UX if it will >help strengthen the argument. This is the real world behavior, and I'm >inclined to believe that FreeBSD is not in a position to dictate what's >"proper behaviour" to Sun (the progenitors of RPC and NFS) and the rest >of the commerical UNIX market. This is obviously flamebait and I'm not going to respond to it. >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? 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) 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. Other commercial vendors are running old security- broken versions of NFS and this makes them wide open for security attacks. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510250338.UAA27854>