steve@brillig.umd.edu (Steve D. Miller) (11/23/88)
It has been pointed out to me by Tony Nardo at APL (trn@warper.jhuapl.edu) that there's yet another (smallish) problem with finger under at least SunOS 3.X. Basically, one can make a symlink from one's own .plan to some protected file in another user's directory, then take advantage of the fact that in.fingerd runs from inetd (which runs as root) to read the "unreadable" file. The fix, as I see it, is to run a more reasonable inetd (like the 4.3BSD one, which allows you to specify the user as which a daemon should run), or to do: # chown nobody /usr/etc/in.fingerd # chgrp nobody /usr/etc/in.fingerd # chmod 6755 /usr/etc/in.fingerd This will make fingerd run as nobody. This problem is likely to exist in any system that doesn't provide a 4.3BSD-style inetd.conf. Whether or not that includes SunOS 4.X, I don't know, but I'd like to find out. [[ See the next message. --wnl ]] This is sure the week for the security problems to come out of the woodwork, isn't it! -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
brian@cs.utexas.edu (Brian H. Powell) (11/23/88)
As distributed, SunOS 4.0 has the same bug. However, since SunOS 4.0 uses
a 4.3BSD-style inetd.conf, you can easily fix it.
Just edit /etc/inetd.conf, and change the line that says:
finger stream tcp nowait root /usr/etc/in.fingerd in.fingerd
to say
finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd
This will cause in.fingerd to run as nobody instead of root. Make sure
you've got a nobody in your passwd file. The fix mentioned above (making
in.fingerd owned, grouped, setuid and setgid to nobody/nogroup) also
works.
Brian H. Powell National Instruments Corp.
brian@natinst.uucp 12109 Technology Blvd.
cs.utexas.edu!natinst!brian Austin, Texas 78727-6204
AppleLink:D0351 (512) 250-9119 x832trinkle@purdue.edu (12/04/88)
The only inconvenience of changing fingerd to run as "nobody", is that
nobody has a uid (type uid_t == unsigned int) of -2. In SunOS 4.0, Sun is
very careful (ha ha) to handle all uids as type uid_t. This makes
/usr/etc/sa complain about preposterous user ids of 65534 every time sa is
run. It is too bad Sun has hardcoded a totally bogus user id into the
kernel (and it has been perpetuated by other vendors that support NFS out
of necessity), or it would be simple enough to change nobody to a
reasonable uid.
This unnecessary annoyance is still a small price to pay for the added
security of running fingerd as nobody.
Daniel Trinkle trinkle@cs.purdue.edu ARPA
Department of Computer Sciences trinkle%purdue.edu@relay.cs.net CSNET
Purdue University {ucbvax,decvax}!purdue!trinkle UUCP
West Lafayette, IN 47907 (317) 494-7844 PHONEJONESD@kcgl1.eng.ohio-state.edu (David Jones) (12/04/88)
I think the proper way to defeat use of symbolic links for .plan files is to have finger check that the file it opens is actually owned by the same uid as the user whose plan file it is supposed to be. This requires actual coding changes to the program, however, so it's not a very attractive solution. David L. Jones | Phone: (614) 292-6929 Ohio State Unviversity | Internet: 1971 Neil Ave. Rm. 406 | jonesd@kcgl1.eng.ohio-state.edu Columbus, OH 43210 | jones-d@eng.ohio-state.edu
trn@aplcomm.jhuapl.edu (Tony Nardo) (12/04/88)
In X-Sun-Spots-Digest: Volume 7, Issue 22, message 8 of 14 natinst!brian@cs.utexas.edu (Brian H. Powell) writes: >... >This will cause in.fingerd to run as nobody instead of root.... There's a slight problem with this, as some of you may have discovered by now. When I used "nobody" in inetd.conf, cron sent root a mail message every day at 00:15 complaining about a daemon having a negative user ID. Other than that, "nobody" works just fine. I set up user "news" as my safe user name in inetd.conf, and "cron" stopped complaining. I really should have tried "chown nobody in.fingerd ; chmod 6755 in.fingerd" on SunOS 4.0 first. From the mail I've received, it sounds like that's the most universally accepted solution. ARPA, BITNET: trn@aplcomm.jhuapl.edu (when our link is fixed) UUCP: {backbone!}mimsy!aplcomm!trn (stopgap measure)
pb%computer-lab.cambridge.ac.uk@nss.cs.ucl.ac.uk (Piete Brooks) (12/04/88)
> The fix, as I see it, is to run a more reasonable inetd (like the 4.3BSD > one, which allows you to specify the user as which a daemon should run), > or to do: > # chown nobody /usr/etc/in.fingerd > # chgrp nobody /usr/etc/in.fingerd > # chmod 6755 /usr/etc/in.fingerd > This will make fingerd run as nobody. ********** DO NOT DO THIS without thinking VERY carefully ! ********** As I see it this allows anyone who accesses you machine as "nobody" (e.g. root on an untrusted machine accessable to random undergrads) to gain root access to your machine ! If they can mount your /usr/etc writable, then all they have to do is to chmod in.fingerd (if people really DID set it writable by "nobody") so that you can write it, insert your favourite program, chmod it to be NOT setuid, then run a remote finger ! May I suggest moving /usr/etc/in.fingerd to (e.g.) /usr/etc/In.fingerd and replacing it with a script: #! /bin/sh exec su nobody -c /usr/etc/In.fingerd [ exec if you don't trust your sh to exec the last command of a script ]
steve@umiacs.umd.edu (Steven D. Miller) (12/12/88)
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.) 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. I suspect that this sort of shenanigans could be pulled on almost any network server, not just fingerd, so long as that utility is owned by someone other than root. The best fix is to use a 4.3-style inetd.conf, but that's only an option for those running SunOS 4.0... Thanks for pointing this out. -Steve Spoken: Steve Miller Domain: steve@mimsy.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-454-1808 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
gandalf@csli.stanford.edu (Juergen Wagner) (12/16/88)
Why bother to change in.fingerd? The easiest fix would be to change *finger* to setuid/setgid nobody, and if you don't like the uid 65534 reports, makeup a new user/group 'finger' with a unique uid/gid. Until you fix the source of 'finger', this will do. And if you are fixing the source, you could disallow all symbolic links for .plan/.project (easy fix if you have source). Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
guy@uunet.uu.net (Guy Harris) (12/17/88)
>This makes /usr/etc/sa complain about preposterous user ids of 65534 >every time sa is run. It is too bad Sun has hardcoded a totally bogus >user id into the kernel Another fix is to make it not be bogus; a future release will probably do so (and make UIDs and GIDs unsigned consistently, as they are in BSD and S5). >This unnecessary annoyance is still a small price to pay for the added >security of running fingerd as nobody. And you can silence "sa" by changing the line in "root"s "crontab" file to read: 15 0 * * * /usr/etc/sa -s 2>&1 >/dev/null | egrep -v '^Preposterous user id, 65534: ignored$'
trn@aplcomm.jhuapl.edu (Tony Nardo) (12/20/88)
In article <8811281958.AA16132@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@mimsy.umd.edu (until 1/4/89) trn@aplcomm.jhuapl.edu (after 1/4/89) BITNET: trn@warper.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn