Date: Thu, 2 Nov 1995 19:45:54 +0800 (WST) From: Peter Wemm <peter@jhome.DIALix.COM> To: CVS-commiters@freefall.freebsd.org Cc: security@freebsd.org Subject: Re: cvs commit: CVSROOT log_accum.pl Message-ID: <Pine.BSF.3.91.951102192412.2078B-100000@jhome.DIALix.COM> In-Reply-To: <Pine.BSF.3.91.951102180042.2078A-100000@jhome.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2 Nov 1995, Peter Wemm wrote:
> On Thu, 2 Nov 1995, Peter Wemm wrote:
> > swallace 95/11/02 01:30:23
> ^^^^^^^^ aargh!! no!!!
> >
> > Modified: . log_accum.pl
> > Log:
> > Take $ENV{'USER'} for the login name, as rshd, telnetd and rlogind all
> > set it. I'm still at a loss to explain why getlogin and `logname`
> > (which make a supposedly secure system call) are returning somebody else's
> > username when cvs (a non privileged process) is run on the end of a rsh.
> > If I do: rsh freefall 'print getlogin' it always seems to work...
> >
> > (If this doesn't work after this commit, I might commandeer Jeffrey Hsu's
> > login.. :-) This commit may say 'hsu' though.)
>
> I think I have an idea why this is happening..
>
> Check the output of:
> rsh localhost ps -O "sess,pid,tt,stat,time,command" | sort
>
> SESS PID TT STAT TIME COMMAND
> acc320 107 ?? Ss 0:01.18 inetd
> acc320 224 ?? I 0:00.97 telnetd
> acc320 226 ?? S 0:09.80 telnetd
> acc320 228 ?? I 0:10.37 telnetd
> acc320 230 ?? S 0:07.21 telnetd
> acc320 2319 ?? S 0:00.09 rshd
> acc320 2321 ?? S 0:00.14 csh -c ps -o sess,pid,tt,stat,time,command -a
> acc320 2322 ?? R 0:00.02 ps -o sess pid tt
>
> b7a040 231 p3 IWs 0:01.05 -tcsh (tcsh)
> b7a040 274 p3 S 0:04.44 -su (tcsh)
> b7a040 307 ?? S 0:32.66 /usr/local/sbin/gated
> b7a040 2317 p3 S+ 0:00.12 rsh jhome ps -o sess,pid,tt,stat,time,command
> b7a040 2318 p3 S+ 0:00.06 sort
> b7a040 2320 p3 S+ 0:00.00 rsh jhome ps -o sess,pid,tt,stat,time,command
>
> b7a640 229 p2 Is 0:04.44 -tcsh (tcsh)
> b7a640 2248 p2 I+ 0:00.17 cvs -z5 -d freefall:/home/ncvs commit log_accu
> b7a640 2249 p2 I+ 0:00.11 rsh freefall cvs server
> b7a640 2250 p2 I+ 0:00.02 rsh freefall cvs server
>
> Notice all the processes in the same session as inetd, including rshd and
> the executed command. setlogin() within the kernel can only store one
> userid per session, and any new ones overwrite the old values.
>
> So, the chances are that the last person who used inetd (or some other
> server in inetd's group that's doing a setlogin()) is smashing all the
> login names in that group, and getting credit for the commits..
>
> I'm checking this on freefall now.. Hmmm!!!!
>
> SESS PID USER TT COMMAND
> 10f09e0 114 root ?? inetd
> 10f09e0 1083 ftp ?? -door.lotus.com: anonymous/johng@pcrd.com: RETR bin/b
> 10f09e0 2655 root ?? telnetd
> 10f09e0 2910 root ?? telnetd
> 10f09e0 8755 root ?? rlogind -D
> 10f09e0 11991 root ?? telnetd
> 10f09e0 13963 root ?? rlogind -D
> 10f09e0 17085 ftp ?? -immanuel.tfs.com: anonymous/pascal@tfs.com: RETR All
> 10f09e0 17422 root ?? rlogind -D
> 10f09e0 19057 root ?? rlogind -D
> 10f09e0 21137 ftp ?? -blues.physik.rwth-aachen.de: anonymous/kuku@: RETR a
> 10f09e0 21140 root ?? telnetd
> 10f09e0 22437 root ?? telnetd
> 10f09e0 23001 root ?? telnetd
> 10f09e0 23245 ftp ?? -133.68.164.100: anonymous/ftp: RETR manpages/manpage
> 10f09e0 24139 ftp ?? -global.atm.ncu.edu.tw: anonymous/roylin@global.atm.n
> 10f09e0 24197 ftp ?? /bin/ls -lgA -lRat
> 10f09e0 24683 ftp ?? -158.250.238.2: anonymous/moury@qw: IDLE
> 10f09e0 24710 root ?? sendmail: CAA24693 gvr.win.tue.nl.: client greeting (
> 10f09e0 24793 ftp ?? -zm.karpaty.uzhgorod.ua: anonymous/eug@zm.karpaty.uzh
> 10f09e0 24826 root ?? rlogind -D
> 10f09e0 24842 root ?? rshd
> 10f09e0 24858 ftp ?? (ls)
> 10f09e0 24859 peter ?? tcsh -c ps -o sess,pid,user,tt,command -a -x
> 10f09e0 24860 peter ?? ps -o sess pid user
> 10f09e0 27638 root ?? rlogind -D
> 10f09e0 27982 ftp ?? -mechv.me.tuns.ca: anonymous/root@: RETR 2.1.0-951026
> 10f09e0 28052 ftp ?? /usr/bin/tar -c -z -f - 2.1.0-951026-SNAP
> 10f09e0 28053 ftp ?? gzip
> 10f09e0 28054 ftp ?? /usr/bin/tar -c -z -f - 2.1.0-951026-SNAP
> 10f09e0 28310 root ?? xterm -fn koi9x15 -tn vt102 -T Freefall -n Freefall -
>
> HMMM!!!!
>
> -Peter
Well, that's definately it.. It's a kernel bug.
I ran the following, and after the rsh while loop had started printing
"peter" over and over again, I did (as root): rsh jhome id. That's when
the username of the peter rsh changed.
Script started on Thu Nov 2 19:20:01 1995
peter@jhome[7:20pm]~-101> rsh jhome id
uid=1000(peter) gid=1000(peter) groups=1000(peter), 0(wheel), 499(ncvs)
peter@jhome[7:20pm]~-102> cat ./gl
#! /bin/sh
while :
do
logname
sleep 2
done
peter@jhome[7:20pm]~-103> rsh jhome ./gl
peter
peter
peter
peter
peter
root
root
root
^C
peter@jhome[7:20pm]~-104>
Script done on Thu Nov 2 19:20:45 1995
The following patch fixes it for me by moving the setsid to a more
appropriate place, and making sure that each exec'ed process is in it's
own session.
Index: inetd.c
===================================================================
RCS file: /home/ncvs/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.8
diff -c -r1.8 inetd.c
*** inetd.c 1995/10/30 14:03:00 1.8
--- inetd.c 1995/11/02 11:23:44
***************
*** 440,447 ****
}
sigsetmask(0L);
if (pid == 0) {
- if (debug && dofork)
- setsid();
if (dofork) {
if (debug)
fprintf(stderr, "+ Closing from %d\n",
--- 440,445 ----
***************
*** 469,474 ****
--- 467,473 ----
recv(0, buf, sizeof (buf), 0);
_exit(1);
}
+ setsid();
if (pwd->pw_uid) {
if (setgid(pwd->pw_gid) < 0) {
syslog(LOG_ERR,
I'd also like to do a setlogin(se->se_user); two lines down from the
setsid() I added (ie: beore setgid(), after the if), this will ensure
non-root processes will get a valid result to getlogin(), while root
processes will be free to set their own. I think it's important to not
set root processes to "root", because if the root process is an old-style
authenticator that changes it's uid to a user, we dont want to erroniously
have that new process going by the "root" name...
Also, of note is XFree86-3.1.2's xdm and gated from ports which do not
correctly detach from the parent session. xdm is a worry, because it
changes the 'logname' of the parent session (maybe even init if started
from there).
Maybe the setlogin() call should only work for processes that are the
session leader rather than just "one of many in the session"?
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951102192412.2078B-100000>