[1116] in linux-security and linux-alert archive
[linux-security] ytalk
daemon@ATHENA.MIT.EDU (Brian L. Naylor)
Fri Aug 30 05:01:20 1996
Date: Thu, 29 Aug 1996 23:24:18 -0400
From: "Brian L. Naylor" <jones@anakin.transy.edu>
To: linux-security mailing list <linux-security@tarsier.cv.nrao.edu>
Hi. I've run across a small 'feature' in ytalk 3.0 p2 that allows
a local user to get an unlogged shell. (i.e., a full login that doesn't
make it into the system logs.) Also, the shell he's running is
apparently unable to get full info either- `whoami` and `id` show
reasonable values but `who am i` doesn't.
I've never heard of this and I haven't seen it in any of the archives,
but it certainly seems like a problem to me. (He can, for example, try
to su all day without his name appearing in the logs.) Forgive me if
this is a known behavior.
This is ytalk version 3.0 p2 on Redhat Linux 3.0.3 (kernel 2.0.10),
bash.
Do `ytalk -x user#ttypx` where user is your own login id and ttypx is
the tty you're currently logged into. Ignore the subsequent talk
request and hit <ESC>-s to bring up a new shell.
...
[user@host user]$ who
user ttyp1 Aug 29 22:53 (dialup1)
[user@host user]$ tty
/dev/ttyp2
[user@host user]$ who am i
[user@host user]$
...
Try an su:
[user@host user]$ su -
Password:
su: incorrect password
woops, well, that's ok, this is what's in the log:
Aug 29 21:27:43 host su: FAILED SU on /dev/ttyp4
^^^^
username should be here
Now, the first part of that- the user not appearing twice with `who`
seems to occur with other secondary shells as well. (From vi, etc.)
The second bit, however, with the null username, doesn't.
In any case, it makes it easy for a user to go about questionable
activities unobserved, and with little record. Is it a bug? I dunno- I
just work here.
--
Brian L. Naylor
jones@anakin.transy.edu
http://www.transy.edu/~jones
[REW: The root of the problem is that unprivilidged programs like
ytalk cannot write to utmp to set the info in there. What Brian
calls "other secondary shells" are programs that use the current
pty to do their stuff. Ytalk creates a new pty. This pty then
doesn't have its info in utmp, so that who, w and su cannot find
valid info there. The weirdest thing is that su seems to trust
"getlogin".
I created a patch (for sh-utils-1.12):
-------------------------------------------------------------------
--- su.c.orig Fri Aug 30 09:32:27 1996
+++ su.c Fri Aug 30 09:44:20 1996
@@ -466,6 +466,8 @@
int successful;
{
const char *new_user, *old_user, *tty;
+ struct passwd *old_pw;
+ char as_str[101];
#ifndef SYSLOG_NON_ROOT
if (pw->pw_uid)
@@ -475,8 +477,15 @@
/* The utmp entry (via getlogin) is probably the best way to identify
the user, especially if someone su's from a su-shell. */
old_user = getlogin ();
+ old_pw = getpwuid (getuid());
if (old_user == NULL)
old_user = "";
+
+ if ((strcmp (old_pw->pw_name, old_user) != 0))
+ snprintf (as_str,100,"(as %s)",old_pw->pw_name);
+ else
+ sprintf (as_str,"");
+
tty = ttyname (2);
if (tty == NULL)
tty = "";
@@ -488,15 +497,15 @@
);
syslog (LOG_NOTICE,
#ifdef SYSLOG_NON_ROOT
- "%s(to %s) %s on %s",
+ "%s%s(to %s) %s on %s",
#else
- "%s%s on %s",
+ "%s%s%s on %s",
#endif
successful ? "" : "FAILED SU ",
#ifdef SYSLOG_NON_ROOT
new_user,
#endif
- old_user, tty);
+ old_user, as_str, tty);
closelog ();
}
#endif
-------------------------------------------------------------------
This adds an "(as username)" to the log whenever it differs from the
info from getlogin.
This is now a log entry from an unpriviliged pty:
Aug 30 09:45:00 cave su: FAILED SU (as wolff) on /dev/ttyp9
And this is when I first su to root and then type "su" again.
Aug 30 09:50:21 cave su: wolff(as root) on /dev/ttypa
If you have SYSLOG_NON_ROOT defined I guess you would also get things
like
Aug 30 09:50:21 cave su: wolff(as root)(to menno) on /dev/ttypa
First I su-ed to root and then to "menno": I don't know menno's
password, but he wanted me to send mail "in his name".
-- Roger.]
