I think this is the product of a bug and a "feature". The bug is in /bin/mail
and a bad fix in the same. It seems that /bin/mail would through mail
from uucp on the floor under certain circumstances. The fix was to take
out all checking for the sender and just believe whatever /bin/mail was told.
Not a good policy as far as I'm concerned. The feature is that mail loves
to look at silly things like getlogin() and $USER instead of more valid
things like getpwuid(getuid()) for the username. These two combined cause
mail to make bogus 'From' lines.
The real fix is in /bin/mail -- get rid of the bad fix and do getpwuid()s
instead of getlogin()s to find the username. While you're at it, you
might want to do this to ucb/mail and sendmail too. I guess this isn't the
most popular way of handling mail senders, but I find it the most reliable --
I tend to like my mail coming from whomever the person is currently, not who
they logged in as!
--
(Bug? What bug? That's a feature!)
Dave Cohrs
...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!dave
da...@wisc-rsch.arpa
I thought it was a bug. When we switched to MMDF it agreed with me.
The From: line and who is posting the message must agree or mmdf tells
you to drop dead (to be honest it says something like invalid author spec).
So I change the rmail to ignore the USER enviroment variable and alway go by
uid.
> You must be new to the net.
>
> When encountering a bug like this, with such nightmarish security
>consequences, do NOT POST IT!! Instead, post a note stating that you will
>send the bug report to site!root for all sites from which you receive
>mail from site!root.
>
> Why? It's now 11:03 on a Saturday morning here...your article
>has been on our system for about 2 hours...and already people are starting
>to exploit the bug.
I received the above response to my recent posting. I didn't realize the
potential consequences of spreading the information. I am not new to the net,
I just didn't think. My apologies to all sites for whom this has caused
problems.
It is even worse: if you are working at a terminal, somebody comes along
and in order to show you something logs in recursively: (login x)
then after his login process has finished your identity will be reported
as x by programs like who and routines like getlogin().
--
Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb
I disagree totally with the sentiment of "that's a big
bug; don't tell anybody except administrators about it".
Telling everybody about it is the only way to guarantee
that people will take notice and fix it. That is, they
are embarassed and/or alarmed into actually doing
something about it.
Otherwise, the bug will sit there for years until
release X comes out, and even then they will probably
forget to fix it. In the meantime, everyone sits
around with a false sense of security and those who
discover the bug on their own are free to wreak havoc.
Bill Dietrich
houxj!wapd
This should not be a staggering surprise; the login operation is not
recursive, and trying to use it that way is obviously a disaster in the
making. The correct approach to this particular problem is to fix login
to recognize, and reject, attempts at recursive logins.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Uhhh... remember that the "From:" line may not ALWAYS be the person
posting the message, if there is a "Sender:" line. (See RFC822 for an
example in which a secretary sends boss's mail.) ((And aren't there
"Resent-...:" headers, too?))
Anyway, the 'uid' (if not "uucp") should match ONE of the valid sender
lines, but not necessarily "From:".
Rob Warnock
UUCP: {ihnp4,ucbvax!amd}!fortune!redwood!rpw3
DDD: (415)572-2607
Envoy: rob.warnock/kingfisher
USPS: 510 Trinidad Ln, Foster City, CA 94404
Say What!
If someone comes up to your terminal and types "login name" you
will be logged out and he will be logged in. If his login process
"finishes" i.e. he logs out, the system will display a login
banner. YOU WILL BE GONE! I'd say whoever did this when you were
at a terminal walked away without logging off. Are you confusing
login with su???
Mike @ AMD
-Ron
It seems to me that su could be smart enough to distinguish between these
two uses (since it already has separate command sequences which are
documented). Opinions?
--
Howard Johnson Cyb Systems, Austin, TX
..!{gatech,harvard,ihnp4,nbires,noao,seismo}!ut-sally!cyb-eng!howard
Please read carefully: if x says (login x) to my shell and his login
process finishes then I am back in my shell again. He might also have
said /bin/login x . What you are thinking of is that most shells
recognize login as a special command and execute it directly without
forking.
Spread the word and get the damn bug fixed!
-------
Well, perhaps. I do not see the possibility of a recursive login as
something that is broken and should be fixed, in fact I use it almost daily.
My only point was to warn you that the value returned by getlogin() is
not always reliable.
There is a difference between (login x) and su x : in the first case
you get into the home directory of x, his .profile or .login is executed etc.;
in the second case your working directory remains unchanged and your
environment is unchanged except for SHELL and HOME. I need the former kind
of behaviour, but can well imagine that other people prefer the latter.
Nope. Typing
% login me
logs out the current user. What the original message said was:
% (login me)
which forces login to run in a subshell. I often pull that trick with
newgrp, we lacking sg.
--bsa
--
Brandon Allbery @ North Coast Xenix | the.world!ucbvax!decvax!cwruecmp!
6504 Chestnut Road, Independence, Ohio | {atvax!}ncoast!{tdi1!}bsa
(216) 524-1416 \ 44131 | E1...@CSUOHIO.BITNET (friend's acct.)
---------------------------------------+---------------------------------------
Forgive; we just had a system crash & lost a month's worth of work and patches.
"Make /bin/login mode 500 owned by root and it will fail on
exec, usually causing /etc/init to fork another copy of itself
and the new user to thus get a fresh copy of /bin/login for
normal login, or (perhaps with parentheses) an error message
from the shell. This mode also makes realistic login
simulators (of the sort that want to collect your password)
harder to write, since they can't just exec /bin/login
afterwards and leave the user no wiser."
The big win of the builtin shell "login" command is that it logs me out
and lets you log in without hanging up the modem line. If you chmod
500 /bin/login, then the line will drop when exec("/bin/login") fails.
Inconvenient.
-- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@csnet-relay) [ARPA]
But "login" is intended to "log you in", replacing the previous user of
that terminal. If you really want to get the home directory of x, his
.profile executed, but all in a nested shell like "su" provides, you
should either modify "su" to allow that behaviour as an option, or
write a command of a different name to do it. Just because a nested
login provides some useful facilities doesn't mean that the ability to
do them is a feature instead of a bug.
If you want those facilities, provide them in a way that doesn't also
create the problems.
Well, you pays your money and you takes your choice. Either you say that:
(a) the value from getlogin() isn't reliable
(b) the environment on login can be a strange mishmash of the
user's environment and the previous user's environment
(c) the stty settings ditto
or
(d) the login operation is not recursive, and hence leads to
confusion if you try to use it that way.
It sure sounds to me like (d) is the simpler explanation of the phenomena.
The fact is, login is modifying "global variables" like the utmp entry,
the environment, and the stty settings, and they don't get put back later.
This is practically the *definition* of something that isn't recursive.
Oh, sure, you can use it that way... provided you aren't too fussy about
the results.
An easy fix (if you have source) is to have /bin/login check if its ppid
== 1, and exit if not. Foils those recursive logins right away. Still
doesn't protect against the password collectors, though. If you don't
have source, compile the little program below (call it ./login) and
mv /bin/login /etc/login; chmod 500 /etc/login
cp ./login /bin/login
chmod 777 /bin/login; chmod u+s /bin/login
/*
* Quick hack to prevent recursive logins. Install as /bin/login, after
* copying /bin/login to /etc/login (mode 500). Must be setuid root.
*
* NOTE and DISCLAIMER - this is completely untested, I haven't even
* compiled it.
*/
#include <stdio.h>
main( argc, argv )
char **argv;
{
if ( getppid() !=1 )
{
fprintf( stderr, "Can't do recursive logins\n" );
exit( 1 );
}
execv( "/etc/login", argv );
perror( "Can't exec login" );
exit( 1 );
}
A very interesting suggestion, especially the part about 777 !
--
=S
If you use "rlogin", then during network connections, login is run as a
child of a child of /etc/rlogind. Thus, if you install this fix, you
disable remote logins.
I would suggest a simple fix if no one has thought of it yet:
After the (login x) is done, do a
(login myself)
That should take care of the problem. Since you are so
nice to let others to use your terminal, may as well
"walk the extra mile".
Albert Cheng
acheng%ui...@csnet-relay.ARPA
{ihnp4,pur-ee}!uiucdcs!acheng
So did System III.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy