From owner-freebsd-security  Tue Jun 25 10:01:16 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA17620
          for security-outgoing; Tue, 25 Jun 1996 10:01:16 -0700 (PDT)
Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA17607
          for <security@freebsd.org>; Tue, 25 Jun 1996 10:01:03 -0700 (PDT)
From: Andrew.Gordon@net-tel.co.uk
Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id RAA13900; Tue, 25 Jun 1996 17:58:30 +0100
Received: from "/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/" by net-tel.co.uk
        (Route400-RFCGate); Tue, 25 Jun 96 17:53:37 +0100
X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; 
        Relayed; Tue, 25 Jun 96 17:53:37 +0100
X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";
         Relayed; Tue, 25 Jun 96 16:53:35 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; 
        Tue, 25 Jun 96 16:53:35 +0000
X400-MTS-Identifier: 
        ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:17886-960625165335-70F1]
X400-Content-Type: P2-1984 (2)
X400-Originator: Andrew.Gordon@net-tel.co.uk
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Tue, 25 Jun 96 16:53:35 +0000
X400-Content-Identifier: NFS attacks (was
Message-Id: <"1847-960625165357-701E*/G=Andrew/S=Gordon/O=NET-TEL Computer
 Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS>
To: "Jeff Aitken" <jaitken@cslab.vt.edu>
Cc: security@freebsd.org
In-Reply-To: <199606251626.MAA06583@husky.cslab.vt.edu>
Subject: NFS attacks (was: Re(4): I need help on this one - please help
        me track this guy down!)
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > But what file transfer mechanism was used?  NFS maybe? 
> > 
> > Personally, I like to mount all NFS filesystems "nosuid" - and likewise
> > for all local systems exported by NFS (I don't normally export / or
> > /usr).  Most users have no business creating setuid programs in their
> > filespace, and such a policy would most likely have prevented this
> > breach even if the setuid binary was created by some other means.
> 
> One thing you can do to help with this sort of problem is to map UID 0
> to some other UID.  In our lab, we've got an AlphaStation which exports
> several filesystems via NFS.  On a few administrative-type machines, we
> map UID 0 to UID 0 (so that root on any of the administrative machines
> can alter files as needed) but on the client machines (i.e., those
> machines used primarily by lab patrons) UID 0 is mapped to 'nobody' or

The mode of attack I was suggesting was untrusted machine as server, machine-under-attack as client.  Maproot wouldn't help in this case, as it applies at the wrong end.

> somesuch.  Furthermore, only system administrators have accounts on the
> servers; thus, even if someone breaks root on a client machine in the
> lab, they can't install any sort of backdoor on the server.  If/when

This is good, if you can accept that limitation.  On hosts where users do have logins, maproot is only part of the answer, since quite a lot of damage can be done by just being setuid to 'bin' (or 'news' or 'www' according to cicumstance).

Also, it sounds like in your environment you can (already do?) block NFS traffic from outside the network of machines you control.  In the situation where the "suid shell" attack succeeded, we are given to understand that the attacker had his own machine readily accessible over the network - though whether NFS was involved has not yet been revealed.