Date: Tue, 25 Jun 96 16:53:35 +0000 From: Andrew.Gordon@net-tel.co.uk To: "Jeff Aitken" <jaitken@cslab.vt.edu> Cc: security@freebsd.org Subject: NFS attacks (was: Re(4): I need help on this one - please help me track this guy down!) Message-ID: <"1847-960625165357-701E*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> In-Reply-To: <199606251626.MAA06583@husky.cslab.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?"1847-960625165357-701E*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">