From: k claffy [mailto:kc@ipn.caida.org]
Sent: Tuesday, July 24, 2001 10:36 PM
almost makes me wonder if some white hat might (should?) have
been behind CodeRed as some 'vaccination' attempt.
Stop wondering. IMHO "White hats" that crack into systems should be treated
the same as "black hats" that crack into systems. Throw them in jail and RO
them from even thinking the word "computer" ever again (A few years, on a
chain-gang, might do them some good ... sun ... excersize ... daylight ...
fresh air ... they might lose that pasty complexion). <from someone whom has
lost way too many days cleaning up the messes after>.
This assault also demonstrates that machines operated by home
users or small businesses (hosts less likely to be maintained
by a professional sysadmin) are integral to the robustness of
the global Internet. As is the case with biologically active
Do you always let your stereotyping lead you by the nose like this ...? Home
users ... maybe. Small businesses ... not.
From: CERT Advisory [mailto:cert-advisory@cert.org]
Sent: Tuesday, July 24, 2001 6:50 PM
CERT Advisory CA-2001-21 Buffer Overflow in telnetd
Original release date: July 24, 2001
Last revised: --
Source: CERT/CC
Systems Affected
Systems running versions of telnetd derived from BSD source.
How many of us here run anything less than SSH and even allow telnetd to
live on any of our hosts?
Those (few) providers offering shell accounts still do.
--Mitch
NetSide
> This assault also demonstrates that machines operated by home
> users or small businesses (hosts less likely to be maintained
> by a professional sysadmin) are integral to the robustness of
> the global Internet. As is the case with biologically active
Do you always let your stereotyping lead you by the nose like this ...? Home
users ... maybe. Small businesses ... not.
I think your faith in mankind is sorely misplaced on this issue. Small
businesses are no more likely to be well maintained than many home
systems. There is little to no motivation for the majority of small
businesses to have an on staff IT professional. Most simply have a
person who is slightly more knowledgable than the other people there.
This isn't because they are ignorant but because the cost/benefit
analysis doesn't indicate that one is really worthwhile.
One might say that any place which has a webserver or telnet server or
whatever should be large enough to afford an IT person. Except that
ignores the fact that several OSes install things like this
automagically or at least with great ease. I suppose much of this also
depends on what you consider to be a small business though.
I am only speaking from experience both as a consultant to small
businesses and having worked for several in my life.
> Systems Affected
>
> Systems running versions of telnetd derived from BSD source.
How many of us here run anything less than SSH and even allow telnetd to
live on any of our hosts?
Here? Probably not all that many. In the real world? Probably the
majority (at least up until recently).
Do you have any evidence that "small businesses" are any more clued than
home users?
The gym I have a membership at has a PC at the front desk that has Internet
connectivity (hey, connectivity is *cheap* when you're in a research park 
I'm willing to bet that most of the people who work there are *NOT* clued
users or sysadmins.
The music store I frequent for guitar gear has a PC - the store owner admits
that he's a great guitarist, a "not in chapter 11" businessman, and totally
clueless about computers - this guy who plays bass fixes it for him when it's
totally dead in the water (fortunately for the store, I happen to know the
bass player, and that guy *does* have some clue - but I'm positive that
nobody told the guys at the store about SirCam, or CodeRed, or anything like
that).
When David Moore said 'Small Business', he meant *SMALL* business. How many
5-and-10 employee stores out there *DONT* have on-staff sysadmins, but *DO*
have PC's that enployees surf the web when business is slow?
> How many of us here run anything less than SSH and even allow telnetd to
> live on any of our hosts?
Here? Probably not all that many.
I wouldn't be so sure. You might want to take a look at the first couple
of minutes of this session from the last NANOG meeting:
http://www.nanog.org/mtg-0105/real/dnssec.ram
It suggests that many (most?) of the NANOG attendees are shipping passwords
around in the clear (not necessarily all telnet, but indicative of a mindset).
I think this suggests the problem is far worse than most people imagine.
mb
> Here? Probably not all that many.
I wouldn't be so sure. You might want to take a look at the first
couple
of minutes of this session from the last NANOG meeting:
http://www.nanog.org/mtg-0105/real/dnssec.ram
It suggests that many (most?) of the NANOG attendees are shipping
passwords
around in the clear (not necessarily all telnet, but indicative of a
mindset).
I think this suggests the problem is far worse than most people imagine.
I think the real suprise to me was at the Pittsburgh IETF, and the number
of people sitting on the wireless LAN in the Security Area open meeting
whose passwords were sniffed and posted on the overhead projector.
if there were ever a bunch of people who were supposed to know better...
richard
> How many of us here run anything less than SSH and even allow telnetd to
> live on any of our hosts?
Here? Probably not all that many.
[bill's password slide from the Scottsdale NANOG]
suggests that many (most?) of the NANOG attendees are shipping passwords
around in the clear (not necessarily all telnet, but indicative of a
mindset).
The system with that data on it is off right now, but my recollection was
that the top three offenders were (in no particular order)
- cleartext POP
- cleartext IMAP
- http:// (mostly people reading their email via Exchange).
Note that the final slide that I put up at the end of the meeting (with
something like 150 passwords on it) had one of my passwords too
(my Vindigo password, if anyone wants to change what cities I have
configured =), so even people who are aware of the issues sometimes
still send cleartext passwords.
Bill
telnetd is not inherently bad. It is a tool that is lacking the
session encryption and strong authentication features of SSH, but is
still useful in some cases. Like any tool it can be used poorly, but
that is not the fault of the tool.
For example, when traveling, I can log in securely from any random
Internet cafe using OPIE or S/Key one-time passwords via telnet. SSH
requires that you trust your local machine, and OPIE assumes that you
don't.
David
You may not expose your password to get into your network but, you do
expose everything else that happens on the connection, including the
passwords to devices that do not use/support OPIE or S/Key
authentication. You can run an SSH client in a java applet in nearly any
browser. If some devices on your network don't support ssh, ssh into
something that does and from there, telnet to the devices that don't.
See RFCs 2941 through 2953. Just because your telnetd doesn't implement
it doesn't mean it's not available.
Having said that, I still use ssh for most stuff.
> > How many of us here run anything less than SSH and even allow telnetd to
> > live on any of our hosts?
>
> telnetd is not inherently bad. It is a tool that is lacking the
> session encryption and strong authentication features of SSH, but is
> still useful in some cases. Like any tool it can be used poorly, but
> that is not the fault of the tool.
>
> For example, when traveling, I can log in securely from any random
> Internet cafe using OPIE or S/Key one-time passwords via telnet. SSH
> requires that you trust your local machine, and OPIE assumes that you
> don't.
You may not expose your password to get into your network but, you do
expose everything else that happens on the connection, including the
passwords to devices that do not use/support OPIE or S/Key
authentication.
Absolutely. OPIE is a strongly authenticated login tool. It does not
encrypt the session. I am aware of this, and thus don't type anything
I don't want sniffed.
You can run an SSH client in a java applet in nearly any browser.
If some devices on your network don't support ssh, ssh into
something that does and from there, telnet to the devices that
don't.
This is the part I disagree with. Given my example (needing to
connect from a public machine while traveling), I cannot trust the
local terminal.
The SSH protocol requires a secure local terminal so using the Java
SSH client does not protect me in the slightest if I can't trust that
terminal, and a public terminal, by its very nature, can never be
trusted.
David
> telnetd is not inherently bad. It is a tool that is lacking the
> session encryption and strong authentication features of SSH, but is
> still useful in some cases. Like any tool it can be used poorly, but
> that is not the fault of the tool.
>
> For example, when traveling, I can log in securely from any random
> Internet cafe using OPIE or S/Key one-time passwords via telnet. SSH
> requires that you trust your local machine, and OPIE assumes that you
> don't.
>
> David
>
> --
> David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/
> +---------------------------------------------------------------------------+
> "There are two major products that come out of Berkeley: LSD and UNIX.
> We don't believe this to be a coincidence." - Jeremy S. Anderson
>
You may not expose your password to get into your network but, you do
expose everything else that happens on the connection, including the
passwords to devices that do not use/support OPIE or S/Key
authentication. You can run an SSH client in a java applet in nearly any
browser. If some devices on your network don't support ssh, ssh into
something that does and from there, telnet to the devices that don't.
John, I think you miss the point. David is saying he can gain access to
devices from untrusted hosts not supporting hardly any services such as
ssh when he needs to with telnet. An application which I agree with to
some degree.
In the past I've used similar telnet backdoors to gain access when in the
field and theres been a crisis. That is where they have their use.. as you
say, if you use it all the time then you run the risk albeit a small one
of being snooped.
FYI at present I have no telnet access.. perhaps I'm paranoid! 
Steve
> telnetd is not inherently bad. It is a tool that is lacking the
> session encryption and strong authentication features of SSH, but is
See RFCs 2941 through 2953. Just because your telnetd doesn't implement
it doesn't mean it's not available.
True I should have said "usually lacking".
Having said that, I still use ssh for most stuff.
Oh, so do I. I was just pointing out while SSH is a wonderful thing,
for certain specific uses (logging in from an untrusted terminal being
one of them), there are better tools.
David
telnetd is not inherently bad. It is a tool that is lacking the
session encryption and strong authentication features of SSH, but is
still useful in some cases. Like any tool it can be used poorly, but
that is not the fault of the tool.
Agreed.
For example, when traveling, I can log in securely from any random
Internet cafe using OPIE or S/Key one-time passwords via telnet. SSH
requires that you trust your local machine, and OPIE assumes that you
don't.
Incorrect. OPIE assumes complete trust of your local machine,
but not the network. You still have to generate the hashes using your
password.
--msa
Not at all. You don't have to generate the hashes on your local
machine. Most people using OPIE (or any one-time password scheme)
have a hardware device (i.e. Palm Pilot) to calculate the hashes. As
you say, it would be rather silly to calculate the hashes on the
untrusted machine!
David
Not the smart ones. I do shell, and I may have an in.telnetd lying around
somewhere, but it sure as hell isn't turned on. The line wasn't just
commented out of my inetd.conf, it was deleted.
Amazingly, the people I provide the service to are using SSH with no
problem at all.
I am not sure why people complain about telnet-security when many of these
same people have no qualms whatsoever using FTP on the same account --
equally plain text and over the general internet.
Yes, you can SSL encapsulate your FTP transactions, and rdist can use ssh as
its transport method, but how many people are really doing that? You can
also kerberize POP, or ssh pop too, but again, most customers don't have the
sophistication to do use all three religiously.
Security is not a once-in-a-while thing. If you allow FTP or POP access to
the same accounts you deny telnet to, the same alleged sniffers will have
just as easy a time grabbing anything they'd like off the wire.
Deepak Jain
AiNET
Steven J. Sobol
I'm looking for ways to secure FTP/POP/IMAP myself, as I agree with
you. (FWIW.)
I'm looking for ways to secure FTP/POP/IMAP myself, as I agree with
you. (FWIW.)
While it's a bit klunky, I found Ixplorer soon after I discovered putty
(http://www.chiark.greenend.org.uk/~sgtatham/putty/). It's a front-end for
pscp written in Delphi that mimics the ubiquitous Windows Explorer:
http://www.i-tree.org/ixplorer.htm. Source is available. I think your
average windows user could get the hang of this pretty quickly.
As for IMAP, I've been playing with courier-imap and it has full SSL
support. Ditto for the pop daemon that comes with the package, and
sqwebmail can be run on an ssl-enabled apache. And then there's the ssl
patches for qmail... Just part of an experiment to see how many things I
could wrap with ssl It was all pretty easy. The hard part would be
putting docs together for your users to explain how to click all the
relevant checkboxes in their mail program(s).
Charles