AUERBACH@CSL.SRI.COM (Karl Auerbach) (09/27/86)
A while back I saw a copy of a newsletter titled "2600" which included source code demonstrating how one could pretend to be an SMTP engine and inject false mail into a host. Although the code had a few flaws, its general structure looked plausable (and short -- about 25 lines of C). --karl-- -------
hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) (09/28/86)
It is moderately obvious from the protocol that you can spoof SMTP. What we tell our users about mail is the following: - here is how to tell from the headers whether a message was delivered locally or via SMTP. (Details vary per system.) - mail that is delivered locally is probably from the person it claims to be. That depends upon the overall security of the system, which is never perfect, but probably it is OK. But don't stake your life on it. - for mail that came in via network, all you can really be sure of is the identity of the most recent host in the link. The received line will show the name of that host. If the host claimed to be someone other than it was, we will tell you. (This is in the DEC-20 implementation. I'm not sure whether our Unix code does this. But I think it does.) Unfortunately, the protocols are such that even if that machine is secure, a user on it could send mail to us claiming to be absolutely anyone he wanted to be. In general, if you want to be more certain who the mail came from, send a response back, referring to the message. If you get a message "what are you talking about?" you know you have been spoofed. This assumes that the system the author is residing on keeps his mail private. You don't need C code to do this spoofing. Just say "telnet host 25". That will connect you to their SMTP server. You can then type a message claiming to be anybody you like. We use this for debugging. The format of the commands is simple enough that it is perfectly practical for a person to do.
MRC@SIMTEL20.ARPA (Mark Crispin) (09/29/86)
Oh wow, big deal, so the little phone phreaks has discovered how to talk to SMTP servers? I mean, am I supposed to be impressed with how bright they are or something? The Internet protocols are insecure by nature. A reasonably suspicious host should always record the host name or IP address of the how which actually connected to the SMTP server (the real host, not what was claimed in a HELO). Some hosts prevent random user programs from making TCP connections to the SMTP port (I think Multics does), but basically beyond knowing what host composed the message the end user should be reasonably suspicious about any mail s/he receives. After all, even IP addresses can be faked, although I suspect inpersonating the IP address of MIT-MULTICS is beyond the technical expertise of your average phone phreak (it requires actually KNOWING something). -------
GROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman) (09/30/86)
You could (marginally) increase the security of SMTP traffic by having SMTP servers only accept connections from a 'privileged' remote socket. Of course, you now would be required to run yet another privileged daemon just to ship mail out of your host. Stu Grossman -------
gds@SPAM.ISTC.SRI.COM (The lost Bostonian) (09/30/86)
> From: Mark Crispin <MRC@SIMTEL20.ARPA> > The Internet protocols are insecure by nature. A reasonably suspicious > host should always record the host name or IP address of the how which > actually connected to the SMTP server (the real host, not what was > claimed in a HELO). If it is true that all IP implementations enable a server program to determine the IP address of its peer, then the HELO command, and its response could be eliminated, which would save us a few bytes. Certainly the response to the HELO is not necessary, since the server has already identified itself in the opening greeting. However, I quote from RFC 821, the explanation for HELO: This command and an OK reply to it confirm that both the sender-SMTP and receiver-SMTP are in the initial state, that is, there is no transaction in progress and all state tables and buffes are cleared. I do not see that there would be a big problem of detecting the initial state without a HELO. Other protocols (FTP, NNTP) don't use it. --gregbo
smb@ulysses.UUCP (Steven Bellovin) (09/30/86)
It's important to remember that SMTP is used on non-TCP virtual circuits. For example, some hosts within Bell Labs use it over Datakit(r) VCS connections. You can't do this nearly as easily with FTP because the semantics of some of the commands (i.e., PORT and PASSIVE) are intimately tied to TCP and IP. In general, though, I regard SMTP as a newer and better protocol than FTP, and as a better model for other protocols. The concept of looking for the initial state is a good one; I've often seen half-open circuits get spliced to due to software bugs (though not on TCP, of course).
ROMKEY@XX.LCS.MIT.EDU (John Romkey) (10/01/86)
The whole idea of "privileged" sockets loses. There are lots of machines out there on the network right now which don't even have the concept of privileges in their operating system: IBM PC's. There's really very little you can do to stop someone with network code on an IBM PC from sending whatever they want, from whatever socket they choose, even whatever IP ADDRESS they wish to appear as, to the net. (of course, if they choose a sufficiently off-the-wall IP address then no packets will ever make it back to them) If you object to the idea of IBM PC's, then just think about all those single user Unix work stations that are appearing nowadays around the Internet. You can't really depend on their "owners" (most of whom probably know the root passwords) being trustworthy. I think we might be better off if no one would even suggest that privileged sockets have any role to play in the security of today's Internet. They only really provide a very thin illusion of security. - john romkey -------
SRA@XX.LCS.MIT.EDU (Rob Austein) (10/01/86)
Date: Monday, 29 September 1986 18:17-EDT
From: Stu Grossman <GROSSMAN@Sierra.Stanford.EDU>
You could (marginally) increase the security of SMTP traffic by having
SMTP servers only accept connections from a 'privileged' remote socket.
Bad idea. Nobody has ever agreed on what a "priviledged port" is.
Berkeley has used that concept for some of their net code (I'm
thinking of LPD in particular). It doesn't add any security when
talking to TOPS-20 or ITS, it's just a pain in the butt because I
can't let the TCP software do the local port multiplexing for me.
This whole discussion seems pretty pointless, since everybody accepts
the need for mail relays and you can't ever possibly verify what
happened on the other side of the mail relay.SRA@XX.LCS.MIT.EDU (Rob Austein) (10/01/86)
Date: Tuesday, 30 September 1986 13:29-EDT
From: The lost Bostonian <gds@spam.istc.sri.com>
To: header-people@mc.lcs.mit.edu, tcp-ip@sri-nic.arpa
If it is true that all IP implementations enable a server program to
determine the IP address of its peer, then the HELO command, and its
response could be eliminated, which would save us a few bytes.
You are assuming that it is always possible to translate addresses to
names and vice versa. Unfortunately, there are some people out in the
world running domain nameservers who are totally clueless about what
they are doing, and there are others who have the misfortune to be
stuck behind a losing gateway or otherwise be unreachable much of the
time. Do you really want to make it impossible to receive mail from
some host because a third party is broken? Or have to put numeric
addresses into the Recieved headers?
The answer is to fix the silly net, not throw away features to save
two IP packets.
--RobGROSSMAN@SIERRA.STANFORD.EDU (Stu Grossman) (10/02/86)
> You could (marginally) ...
That's why I said "marginally". Yes, LPD has this problem, but it's not
so simple. LPD can be told to accept print requests only from certain hosts.
So now you have to:
1) successfully imitate another host, and
2) declare yourself as the appropriate port type
So that you can send bogus print requests to an lpd.
Yes, the 'privileged' port number stuff in LPD is quite naive. However,
as long as point 1 (above) is quite difficult to do, LPD can be pretty
safe from bogus print requests.
-------