honey (05/11/83)
From watmath!MAILER-DAEMON Tue May 10 17:51:55 1983 Security-note: Sender's site and/or name may have been forged near site allegra possibly by user honey To: allegra!honey Subject: Unable to deliver mail ----- Transcript of session follows ----- postmaster... User unknown ----- Unsent message follows ----- Date: Tue May 10 16:26:46 1983 To: rochester!allegra!watmath!postmaster rochester!bukys Subject: Re: news 2.10 ... boring interpolated (sic) material ... allegra runs A+ news. the garbage probably got tacked on somewhere down the pike. i can check on eagle if you like. this is one reason why i hate internet. peter honeyman i recall wild ravings about the lunacy of internet syntax, B news in general, and 2.10 in particular; nothing so lukewarm as what you see above. must have been a forgery. peter honeyman
arwhite (05/16/83)
From watmath!MAILER-DAEMON Tue May 10 17:51:55 1983 Security-note: Sender's site and/or name may have been forged near site allegra possibly by user honey To: allegra!honey Subject: Unable to deliver mail ----- Transcript of session follows ----- postmaster... User unknown Sigh. Do you want to know why this is??? I got tired of the basic flaws in the various mailers; specifically: 1) /bin/mail -d -r Anybody Anyone... To send a message from anybody at all; this would have been easy enough to fix but the remote case: 2) uux - watmath!rmail Anyone From anybody ... remote from Anywhere is a real pain! So, what I did was: 1) Made uucp secure. a) took off general write from uucp spool, took any read off any data files, took write off control files. b) Verify that the system logging in on a given connection is indeed allowed to log onto that userid; i.e. we assume that password verification is sufficient. c) Verify that any X. file created has the system name in it that is indeed the remote system name. d) uuxqt veri- fies that the system name in the U directive line is the same as that in the X. filename. e) uuxqt passes off REMOTE and USER env- ironment variables containing the contents of the U directive line. 2) Made /bin/mail secure. This is the only one you have to worry about, it is the only one with setuid to root. If the -r field is specified and the current real userid is not root or uucp it is rejected (actually with a security-note similar to above giving the real userid). If the userid is uucp, then make sure that the first system specified in the -r field is indeed the same as that contained in the REMOTE directive. If the USER environment variable is uucp, then make sure that there is a further remote system indicated in that field. Else make sure that all that is left in that field is the username which must be the same as that in the USER env. variable. And then a few exceptions (such as mail may come from a remote site with USER uucp, and from uucp at that remote site) Currently there are two bugs: 1) delivermail insists for rejections to call /bin/mail with -r MAILER-DAEMON. (Above case). If I make mail check specifically check for this case then anybody could send mail as if it came from MAILER-DAEMON. In this case, mail detects that the REMOTE and USER variables are allegra and honey, respecively which is why the error is as indicated. 2) Some remote sites seem to have a real uucp which has a different name from uucp. i.e. allegra has ``uucpa''. While we have different login ids for uucp, all have the same numerical userid, hence if uuxqt calls rmail which eventually calls uux, the X. file will have as user ``uucp'' And then the remote system can say that indeed it came from uucp. In the case of allegra, we get complaints saying that the user ``uucpa'' at allegra is trying to send mail basically as per the original bug 2). Anyhow, now if we get mail it really has come from at least the first site in the list, or indeed if it was within our own machines it REALLY came from that person on that site. (And not only that, nobody has read it!) So we may send the occasional false security note, but in general things are better.