From owner-freebsd-security  Tue Mar 11 05:57:30 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA04046
          for security-outgoing; Tue, 11 Mar 1997 05:57:30 -0800 (PST)
Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA04041
          for <freebsd-security@FreeBSD.org>; Tue, 11 Mar 1997 05:57:24 -0800 (PST)
Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id OAA27007; Tue, 11 Mar 1997 14:57:13 +0100 (MET)
From: Guido van Rooij <guido@gvr.win.tue.nl>
Message-Id: <199703111357.OAA27007@gvr.win.tue.nl>
Subject: Re: NFS security issue...
In-Reply-To: <199703111253.GAA14875@enteract.com> from "Thomas H. Ptacek" at "Mar 11, 97 06:53:07 am"
To: tqbf@enteract.com
Date: Tue, 11 Mar 1997 14:57:13 +0100 (MET)
Cc: freebsd-security@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Thomas H. Ptacek wrote:
> 
> As we all know, the mount daemon can be configured to ignore mount procs
> originating on non-reserved ports. MOUNTPROC_NULL will time out from
> callrpc() if I'm a normal user requesting the service over loopback.
> 
> Unfortunately, the same consideration doesn't seem to be given to NFS
> requests - I can successfully complete an NFSPROC_NULL through callrpc()
> as a normal user, can't find any code in sys/nfs/nfs_socket.c that ever
> checks the port on which NFS requests are originating, and can only assume
> that any arbitrary user on my system, with knowledge of an NFS file
> handle, can complete NFS transactions.
> 
> Is there a reason why nfssvc() can't be told to check the port on incoming
> NFS requests? This seems to me to be a major loophole in the manner in
> which NFS RPC requests are validated.
> 

I agre. But this is only true for special setups where no systems are involved
that you do not control. I still think it is a valid point you make. I 
made somethig using a syscvtl variable. Perhaps the discussion should
be done againb...

-Guido