[22] in linux-net channel archive
Re: Linux-Activists - NET Channel digest. 95-0-17-12:21
daemon@ATHENA.MIT.EDU (Swen Thuemmler)
Wed Jan 18 04:32:14 1995
Date: Wed, 18 Jan 1995 09:40:20 +0100 (MET)
From: Swen Thuemmler <swen@uni-paderborn.de>
To: Linux Activists <linux-activists@niksula.hut.fi>
Cc: Linux Net <linux-net@vger.rutgers.edu>
In-Reply-To: <95Jan17.183900eet.57126-3@niksula.hut.fi>
X-Mn-Key: NET
On Tue, 17 Jan 1995, lilo wrote:
> I've been sitting around watching this debate, but I have to say
> something. Are you seriously saying that an attacker claiming to be the
> NFS server and giving bogus results is not something to worry about?
Well, in some way this is what I am saying. In another it isn't. Yes, it
is someghing to worry about. But not, this can not be fixed with
connected sockets, since the attacker has at least to produce a correct
XID. And if he or she is able to do so, changing the address will not be
a problem, either.
> Anything that leaves a loophole in which it might be possible to
> deliberately produce incorrect output in an NFS server-client
> conversation is worthy of serious concern.
Yes, but this cannot be fixed by accepting only packets from one host,
since an attacker can easily change the source address. Fixing requires
secure RPC or Kerberos or something like this. Question is: would
changing the kernel client code in the way I proposed really make the
system less secure? IMHO it does not (securing the bathroom window does
not help when the front door is wide open.), but it does cause us poor
souls with multihomed NFS servers and rendundant routes a lot of (ok,
some) problems.
I hope this clarifies the issue a bit (and I'm not very fluent in
english, so this may be a cause of misunderstanding).
Greetings, Swen
