[70] in linux-net channel archive
Re: NFS packets' source address & security.
daemon@ATHENA.MIT.EDU (Swen Thuemmler)
Wed Feb 8 14:20:12 1995
Date: Wed, 8 Feb 1995 18:17:22 +0100 (MET)
From: Swen Thuemmler <swen@uni-paderborn.de>
To: Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI>
cc: Rick Sladkey <jrs@world.std.com>, linux-net@vger.rutgers.edu,
Ian Jackson <iwj10@cus.cam.ac.uk>
In-Reply-To: <m0raMUe-0002g8Z.ijackson@nyx.cs.du.edu>
Warning: This is going to be rather lengthy. Linus: please read it and
reconsider.
On Fri, 3 Feb 1995, Ian Jackson wrote:
> The XID is not particularly hard to predict or guess, and the
> attacker can guess as many times as they like. (They may also find
> it out quite easily if they are able to generate legitimate traffic
> to a host they control, or are able to snoop but not to insert
> packets.)
[...]
> > Yes, but this cannot be fixed by accepting only packets from one
> > host, since an attacker can easily change the source address.
>
> This is not true - many sites now configure their routers to block
> packets that arrive on their external interface with a source
> address on the internal network. Almost all sites should do this,
> and with this in place the source address can at least be trusted to
> say whether a packet is coming from inside or outside your own
> network, which may well be enough.
>
> However, if your NFS client will accept packets from any old source
> address this fails.
>
> Furthermore, when IPSEC comes along and IP source addresses can be
> authenticated NFS can at least be made to work between mutually
> trusting systems. This won't work either, if packets from anywhere
> work as replies.
Ok, point taken. But I'm still not convinced the kernel should enforce
this restriction on NFS packets. I will try once again to explain the
problems with this enforcement. In a nutshell: it is incompatible with
user level programs like amd and may make your machine unusable, when
a lot of programs hang waiting for an NFS reply which is never
recognised. If you have to reboot to make it work again, this makes
the machine unreliable. There is always the possibility to add an
option to the mount program for "secure" mounts.
Not in a nutshell:
Arguments for the
current behaviour: { comments by me }
--------------------------------------------------------------------
o it is more secure { I don't believe this. As I
did write in an earlier mail:
securing the bathroom window does
not help, if your front door is
open. If you are THAT concerned of
security, you should not be using
NFS anyway.
AND you can have the same behaviour
with your mount program
connect()ing the socket, so there
is no need having this in the
kernel. }
o connected sockets may have better { I don't know. Alan? }
performance in the network layer
o (feel free to add your own arguments)
Arguments for the
proposed change:
--------------------------------------------------------------------
o NFS is defined in terms of ONC RPC. If you look at the
implementation of the rpc library, you will notice, that it does
use sendto() and recvfrm() in the clnt_call() routine. The sockets
are not connected. So all UDP RPC clients will accept packets from
any host. Therefore I consider it as standard behaviour for UDP
RPC client programs to accept packets from any address (there is
of course the XID which has to match). An NFS client is a UDP RPC
client.
o The mount program itself and the automounter amd use the RPC
routines. The mount program get the filehandle via the MOUNT
protocol (with the rpc library routines). It then gives this
information to the kernel which handles the NFS protocol. Now,
here we have a problem. If Joe User did give mount the "wrong"
interface address, the MOUNT protocol will still succeed, but the
kernel will not accept packets from this hosts. The mount program
will hang, since the mount call will not succeed. This is bad. But
it can get worse. Imagine, the mount succeeds, because the address
was correct. But suddenly some router goes down or some fddi board
run amok, and the route to your server changes (this is the
situation on our university: two backbones, one ethernet, one
fddi, servers often have three interfaces: subnet, fddi-bb,
ethernet-bb). Now all programs accessing the mount point will hang
with NFS server not responding. But worse: the automounter amd was
designed to prevent programs from hanging when an NFS server goes
down. It sends NFS pings to the server to check if it is still
alive. Again this is implemented with the rpc library, so amd
happily thinks the server is up, gives the programs the link to
the actual mount point an bummer, they hang, because the kernel
does not know about the multiple interfaces.
Summary: The current behaviour is bad and results in problems. A
change in the kernel can fix this without adding other
problems. So please let us make the kernel change.
Greetings,
--Swen
