hartley@uvm-cs.UUCP (Stephen J. Hartley) (11/09/84)
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@uwvax.UUCP (Dave Cohrs) (11/10/84)
> 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 dave@wisc-rsch.arpa
lmcl@ukc.UUCP (L.M.McLoughlin) (11/11/84)
In article <331@uvm-cs.UUCP> hartley@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.
hartley@uvm-cs.UUCP (Stephen J. Hartley) (11/11/84)
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. -- "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
aeb@turing.UUCP (11/13/84)
> 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
wapd@houxj.UUCP (Bill Dietrich) (11/13/84)
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@utzoo.UUCP (Henry Spencer) (11/13/84)
> 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
rpw3@redwood.UUCP (Rob Warnock) (11/14/84)
+--------------- | 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@amdcad.UUCP (Mike Parker) (11/15/84)
> > 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 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 <ron@BRL-TGR> (11/16/84)
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
jsq@ut-sally.UUCP (John Quarterman) (11/16/84)
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
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsqaeb@turing.UUCP (11/16/84)
>> 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. -- Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb
Mark Crispin <MRC@SU-SCORE.ARPA> (11/16/84)
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! -------
aeb@turing.UUCP (11/17/84)
>> 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 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
bsa@ncoast.UUCP (Brandon Allbery) (11/18/84)
> Article <>, from mike@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 | E1439@CSUOHIO.BITNET (friend's acct.) ---------------------------------------+--------------------------------------- Forgive; we just had a system crash & lost a month's worth of work and patches.
dmmartindale@watcgl.UUCP (Dave Martindale) (11/20/84)
> 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@utzoo.UUCP (Henry Spencer) (11/20/84)
> > 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. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
karl@osu-eddie.UUCP (Karl Kleinpaste) (11/21/84)
---------- >>>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
acheng@uiucdcs.UUCP (11/25/84)
> 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%uiuc@csnet-relay.ARPA {ihnp4,pur-ee}!uiucdcs!acheng
jfs@ih1ap.UUCP (Jesse Fred Shumway) (11/28/84)
AT&T's UNIX V does just that.
guy@rlgvax.UUCP (Guy Harris) (11/30/84)
> AT&T's UNIX V does just that.
So did System III.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy