Yet another finger hole

[Tony Nardo]

In article <8811281958.AA16132 at fnord.umiacs.UMD.EDU> you write:
>If someone can get to, and become root on, an untrusted machine that can
>mount your /usr/etc read-write, they can do a lot of things that will end
>up with their gaining root access to your machine.  (This is why we manage
								  ^^^^^^^^^
>our exports files carefully, and why on untrusted machines we use a hacked
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>/etc/init that won't boot single-user without being given the root
>password.)

This is true, and most likely the reason I missed the hole I was creating.
What's funny is that I did point out the dangers of universal access to
systems (via etc/exports) to a large number of people that asked me about
the "other" finger bug, but I never thought about this as one of the
dangers posed by rogue "root" users.

>The scenario that you describe will indeed allow such an intruder to gain
>root access to your system.  I think the change you suggest will work to
>foil such methods of intrusion.

If you have the source code, you can insert the line

	setuid( (unsigned short)-2 );	/* use ID for "nobody" */

just before the "execv(...)" call.  This allows you to keep "in.fingerd"
owned by "root" on systems that don't have 4.3 BSD-style "inetd.conf"
files.

>The best fix is to use
>a 4.3-style inetd.conf, but that's only an option for those running SunOS
>4.0...

Actually, the *BEST* fix would be to retain SU privilege for in.fingerd
and fix the real culprit, "finger.c".  The local copy of "finger" should
check that the target .plan/.project files are
	a) really named .plan/.project (not just links to them), and
	b) world readable

That way a user may protect his/her directory but still have publicly
accessible .plan/.project files.

I see that there's a new set of 4.3 BSD sources available from Berkeley.
I sure hope they made changes like these to "finger.c"...

--
Over the Christmas holidays, our link to the APRANET will once again disappear
while our gateway undergoes "technical diff...", er, "electrical maintenance".
If you need to reach me, be warned that "r" and "R" may result in a bounced
message.  In such a case, use the first ARPA address or UUCP.

ARPA:		aplcomm!trn at mimsy.umd.edu	(until 1/4/89)
		trn at aplcomm.jhuapl.edu		(after 1/4/89)
BITNET:		trn at warper.jhuapl.edu
UUCP:		{backbone!}mimsy!aplcomm!trn