Date: Wed, 15 Aug 2001 01:48:27 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Greg Lehey" <grog@FreeBSD.org> Cc: "Ryan Thompson" <ryan@sasknow.com>, "William Nunn" <yorkie123@hotmail.com>, <freebsd-questions@FreeBSD.org> Subject: RE: Remotely Exploitable telnetd bug Message-ID: <001101c12567$0d51ac00$1401a8c0@tedm.placo.com> In-Reply-To: <20010815144453.U49989@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: Greg Lehey [mailto:grog@FreeBSD.org] >Sent: Tuesday, August 14, 2001 10:15 PM >To: Ted Mittelstaedt >Cc: Ryan Thompson; William Nunn; freebsd-questions@FreeBSD.org >Subject: Re: Remotely Exploitable telnetd bug > > >On Tuesday, 14 August 2001 at 22:02:37 -0700, Ted Mittelstaedt wrote: >> >>> -----Original Message----- >>> From: owner-freebsd-questions@FreeBSD.ORG >>> [mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Greg Lehey >>> >>> The best alternative is: don't use telnet. Even with this fix, the >>> protocol is inherently insecure. >> >> At the risk of starting a flame war, it's not the Telnet protocol that's >> insecure, it's the entire TCP/IP protocol - if that is you define >insecure as >> sending passwords in cleartext. > >I don't understand this. TCP and IP don't have the concept of a >password. > Your right - what I should have said is that just about all of the various protocols in the TCP/IP umbrella are insecure, because TCP/IP left encryption up to the application layer to implement, not the packet layer. Since the IP packet standard does not specify that the payload of the packet is encrypted - there is no mechanism for it in IPv4 - this is the real reason that Telnet is insecure. IP could have been designed from the beginning to encrypt all data payloads, with extensible encryption so that as holes were discovered (like the too small DES key) that the encryption could have been made stronger. This would obviously have fundamentally changed the IP protocol stack, for example connectionless protocols would have been petty hard to implement! It's also difficult to see what value that encryption would hold for things like broadcast packets. (anti spoofing, perhaps?) >> FTP, POP3 and many other commonly used TCP/IP protocols are >> inherently insecure using this definition. > >Definitely. In fact, POP is quite a problem because I don't know of >any well-known secure alternative. Actually, if you think about it, POP3 is not as much a problem. Look at it this way. What is transferred over POP3? E-mail. How does that E-mail get there to be transferred? SMTP mostly. Now, if an attacker wanted to sniff your e-mail, all he needs to do is sniff the incoming SMTP he doesen't need to bother looking at the POP3 session at all. Sure, POP3 does pass the password in the clear - but all the POP3 password gets the attacker is access to your mailbox, and that just lets him steal your mail. If your frequently checking e-mail then it's unlikely he could make off with the bulk of your incoming e-mail without causing noticeable trouble, since POP servers don't permit concurrent access to the mailbox. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001101c12567$0d51ac00$1401a8c0>