Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

deceptive mail

432 views
Skip to first unread message

Stephen J. Hartley

unread,
Nov 8, 1984, 7:15:39 PM11/8/84
to
Somebody here noticed the following "feature" of mail (4.2 BSD). Under
certain conditions, a user "xyzu" can do a "set user=abcd" and send mail
to user "pqrs". To "pqrs" it appears that "abcd" sent the mail (xyzu <>
abcd). This could cause misunderstandings or such if "xyzu" were malicious.
Is this a feature or a bug? Thanks.
--
"If that's true, then I'm the Pope!" Stephen J. Hartley
USENET: decvax!dartvax!uvm-gen!uvm-cs!hartley The University of Vermont
CSNET: hartley%uvm@csnet-relay (802) 656-3330

Dave Cohrs

unread,
Nov 10, 1984, 10:36:33 AM11/10/84
to
> Somebody here noticed the following "feature" of mail (4.2 BSD). Under
> certain conditions, a user "xyzu" can do a "set user=abcd" and send mail
> to user "pqrs". To "pqrs" it appears that "abcd" sent the mail (xyzu <>
> abcd). This could cause misunderstandings or such if "xyzu" were malicious.
> Is this a feature or a bug? Thanks.

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

L.M.McLoughlin

unread,
Nov 10, 1984, 8:26:59 PM11/10/84
to
In article <3...@uvm-cs.UUCP> har...@uvm-cs.UUCP (Stephen J. Hartley) writes:
>Somebody here noticed the following "feature" of mail (4.2 BSD). Under
>certain conditions, a user "xyzu" can do a "set user=abcd" and send mail
>to user "pqrs". To "pqrs" it appears that "abcd" sent the mail (xyzu <>
>abcd). This could cause misunderstandings or such if "xyzu" were malicious.
>Is this a feature or a bug? Thanks.

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.

Stephen J. Hartley

unread,
Nov 11, 1984, 7:34:35 AM11/11/84
to
I owe the net a sincere apology:

> 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.

a...@turing.uucp

unread,
Nov 12, 1984, 8:17:41 PM11/12/84
to rn...@mcvax.local
> I tend to like my mail coming from whomever the person is currently, not who
> they logged in as!

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

Bill Dietrich

unread,
Nov 13, 1984, 1:54:06 PM11/13/84
to

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

Henry Spencer

unread,
Nov 13, 1984, 3:39:03 PM11/13/84
to
> 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().

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

Rob Warnock

unread,
Nov 13, 1984, 5:08:47 PM11/13/84
to
+---------------

| 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.
+---------------

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

Mike Parker

unread,
Nov 14, 1984, 10:26:23 PM11/14/84
to


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 Natalie

unread,
Nov 15, 1984, 7:35:27 PM11/15/84
to
Wrong. If you put the login inside the parentheses the shell forks
rather than execing log in, so the original user is still there.

-Ron

John Quarterman

unread,
Nov 15, 1984, 10:22:21 PM11/15/84
to
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.
--
John Quarterman, CS Dept., University of Texas, Austin, Texas 78712 USA
j...@ut-sally.ARPA, j...@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsq

Howard Johnson

unread,
Nov 16, 1984, 2:20:19 PM11/16/84
to
This conversation about su has me wondering: What do people usually use
su for? I see two commonly used functions here: 1) administrative and
maintenance functions (e.g. su news; ...) for required access privileges,
and 2) for someone else to do/show something (e.g. su - joe; ...; EOT).

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

a...@turing.uucp

unread,
Nov 16, 1984, 2:29:07 PM11/16/84
to rn...@mcvax.local
>> 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
>
>
> 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

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.

Mark Crispin

unread,
Nov 16, 1984, 2:39:30 PM11/16/84
to
Bill Dietrich says it clearly and simple. In the TOPS-20 community,
DEC has a procedure called CTCO's (Confidential Technical Change Orders)
which only go to the site's designated administrator/guru for distributing
security bug announcements and fixes. It fails miserably. At least half
the sites have problems getting ANY CTCO announcements out of DEC, and so
many sites have leaks that a CTCO is barely out before the "cracker net"
finds out all about it.

Spread the word and get the damn bug fixed!
-------

a...@turing.uucp

unread,
Nov 17, 1984, 12:47:21 PM11/17/84
to rn...@mcvax.local

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.

Brandon Allbery

unread,
Nov 18, 1984, 11:17:14 AM11/18/84
to
> Article <>, from mi...@amdcad.UUCP (Mike Parker)
+----------------

| > 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().
|
| 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???

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.

Andrew Klossner

unread,
Nov 19, 1984, 4:08:07 AM11/19/84
to
[No white space here. Better luck next time, news eater bug]

"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]

Dave Martindale

unread,
Nov 20, 1984, 1:58:57 PM11/20/84
to
> 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.
> Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb

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.

Henry Spencer

unread,
Nov 20, 1984, 2:00:27 PM11/20/84
to
> > 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.
>
> 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.

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.

Karl Kleinpaste

unread,
Nov 20, 1984, 11:45:34 PM11/20/84
to
----------

>>>I tend to like my mail coming from whomever the person is currently, not who
>>>they logged in as!
>>
>>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().
>
> 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???
----------
Geez, lighten up, cool down, and take a quarter off and think about it. The
indicated bug-causing example said, "(login x)" which has a set of
parentheses associated with it. That tells any shell of which I'm aware to
execute the command in a subshell. So your newly-created subshell exec's
login directly, leaving you again with a recursive login. The login program
will, of course, do kinky things to /etc/utmp, changing the results of
getlogin() calls thereafter. And, when the recursive login exits, /etc/utmp
will not be restored to its previous condition for the simple reason that
the 2nd login was not a child of init, which normally updates /etc/utmp on
logout.
--
Karl Kleinpaste @ Bell Labs, Columbus 614/860-5107 {cbosgd,ihnp4}!cbrma!kk
@ Ohio State University 614/891-5058 cbosgd!osu-eddie!karl
karl.Ohio-State@Rand-Relay

Spencer W. Thomas

unread,
Nov 21, 1984, 1:55:16 AM11/21/84
to
In article <11...@orca.UUCP> and...@orca.UUCP (Andrew Klossner) writes:
>
>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.

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...@turing.uucp

unread,
Nov 22, 1984, 6:29:14 PM11/22/84
to rn...@mcvax.local
> chmod 777 /bin/login; chmod u+s /bin/login
> /* Must be setuid root. */

A very interesting suggestion, especially the part about 777 !
--

Spencer W. Thomas

unread,
Nov 23, 1984, 11:10:42 AM11/23/84
to
>> chmod 777 /bin/login; chmod u+s /bin/login
>> /* Must be setuid root. */
>
>A very interesting suggestion, especially the part about 777 !
Oops, obviously, I meant 555. (Just a slip of the key).

=S

Andrew Klossner

unread,
Nov 24, 1984, 8:25:51 PM11/24/84
to
>In article <11...@orca.UUCP> and...@orca.UUCP (Andrew Klossner) writes:
>>
>>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.
>
>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.

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.

ach...@uiucdcs.uucp

unread,
Nov 25, 1984, 3:26:00 PM11/25/84
to
> 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().

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

Jesse Fred Shumway

unread,
Nov 27, 1984, 8:14:39 PM11/27/84
to
AT&T's UNIX V does just that.

Guy Harris

unread,
Nov 30, 1984, 1:57:44 AM11/30/84
to
> AT&T's UNIX V does just that.

So did System III.

Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy

0 new messages