Did I give up on telnet too easily?

Those of us paying attention will have surely noticed that SSH daemons are
proving to be rather buggy; OpenSSH has had several remote exploits
discovered including some major root exploits. And lsh -- suggested by many
as a replacement to OpenSSH -- is itself vulnerable to a remote exploit
http://www.securityfocus.com/archive...8/2003-09-24/0

If ssh is to be considered 'more secure' than telnet, I think one has to
take into account how often the admin is able to patch the machine. In an
organization that employs a full time network techie, applying the ssh
patches is an easy enough task.

But on a machine that sits unattended for long periods of time (a router,
etc.) I think a better approach would be to use telnet for remote access.
In such a circumstance, with long periods between remote logins I think the
likelihood of being exploited by an ssh vulnerability might outweigh the
likelihood of passwords being sniffed on the wire.

Thoughts?

On 21 Sep 2003 16:00:11 GMT, Jem Berkes wrote:
> Those of us paying attention will have surely noticed that SSH daemons are
> proving to be rather buggy; OpenSSH has had several remote exploits
> discovered including some major root exploits. And lsh -- suggested by many
> as a replacement to OpenSSH -- is itself vulnerable to a remote exploit
> http://www.securityfocus.com/archive...8/2003-09-24/0
>
> If ssh is to be considered 'more secure' than telnet, I think one has to
> take into account how often the admin is able to patch the machine. In an
> organization that employs a full time network techie, applying the ssh
> patches is an easy enough task.
>
> But on a machine that sits unattended for long periods of time (a router,
> etc.) I think a better approach would be to use telnet for remote access.
> In such a circumstance, with long periods between remote logins I think the
> likelihood of being exploited by an ssh vulnerability might outweigh the
> likelihood of passwords being sniffed on the wire.
>
> Thoughts?

The first thing for you to consider, was the exploit found in the wild
or in a code review.

Second, you putting only_from = trusted_ip_here in
/etc/profile.d/sshd-xinetd would keep a whole bunch of exploits from
happing now and in the future.

For the telnet consideration, how patient is the password sniffer listening
on either end of the telnet session.

Jem Berkes wrote:
> Those of us paying attention will have surely noticed that SSH daemons are
> proving to be rather buggy; OpenSSH has had several remote exploits
> discovered including some major root exploits. And lsh -- suggested by many
> as a replacement to OpenSSH -- is itself vulnerable to a remote exploit
> http://www.securityfocus.com/archive...8/2003-09-24/0
>
> If ssh is to be considered 'more secure' than telnet, I think one has to
> take into account how often the admin is able to patch the machine. In an
> organization that employs a full time network techie, applying the ssh
> patches is an easy enough task.
>
> But on a machine that sits unattended for long periods of time (a router,
> etc.) I think a better approach would be to use telnet for remote access.
> In such a circumstance, with long periods between remote logins I think the
> likelihood of being exploited by an ssh vulnerability might outweigh the
> likelihood of passwords being sniffed on the wire.
>
> Thoughts?

If you're using Kerberized telnet on your intranet, maybe.
For remote logins, I like setting up ssh to accept only public key
authentication. Then if someone wants to guess my "password," he's got
to guess my public/private key pair. I'm willing to get hyperactive
about patching ssh to keep that.

Bit Twister wrote:

> On 21 Sep 2003 16:00:11 GMT, Jem Berkes wrote:
>> Those of us paying attention will have surely noticed that SSH
>> daemons are proving to be rather buggy; OpenSSH has had several
>> remote exploits discovered including some major root exploits. And
>> lsh -- suggested by many as a replacement to OpenSSH -- is itself
>> vulnerable to a remote exploit
>> http://www.securityfocus.com/archive...8/2003-09-24/0
>>
>> If ssh is to be considered 'more secure' than telnet, I think one has
>> to take into account how often the admin is able to patch the
>> machine. In an organization that employs a full time network techie,
>> applying the ssh patches is an easy enough task.
>>
>> But on a machine that sits unattended for long periods of time (a
>> router, etc.) I think a better approach would be to use telnet for
>> remote access. In such a circumstance, with long periods between
>> remote logins I think the likelihood of being exploited by an ssh
>> vulnerability might outweigh the likelihood of passwords being
>> sniffed on the wire.
>>
>> Thoughts?
>
> The first thing for you to consider, was the exploit found in the wild
> or in a code review.
>
> Second, you putting only_from = trusted_ip_here in
> /etc/profile.d/sshd-xinetd would keep a whole bunch of exploits from
> happing now and in the future.
>
> For the telnet consideration, how patient is the password sniffer
> listening on either end of the telnet session.

And do not forget that also telnet has its occasional exploit. There is
no added value in using telnet instead of ssh. None at all. On the
contrary.

EJ
--
Remove the obvious part (including the dot) for my email address.
http://www.vanwesten.net for examples of ipf and pf.

Jem Berkes wrote:

> Those of us paying attention will have surely noticed that SSH daemons are
> proving to be rather buggy; OpenSSH has had several remote exploits
> discovered including some major root exploits. And lsh -- suggested by
> many as a replacement to OpenSSH -- is itself vulnerable to a remote
> exploit
> http://www.securityfocus.com/archive...8/2003-09-24/0
>
> If ssh is to be considered 'more secure' than telnet, I think one has to
> take into account how often the admin is able to patch the machine. In an
> organization that employs a full time network techie, applying the ssh
> patches is an easy enough task.

Or in an organization using one of the distributions which issues patches on
a timely basis, and has a network method for getting patches. At work, I
have a mixture of Debian, Red Hat, Trustix, Tru64 Unix, and HP-UX machines.
Debian was easy -- "apt-get update; apt-get -u upgrade" (using the -u to
check what else is being upgraded). On our Red Hat machines, we have a
subscription to Red Hat Network, so running the up2date command did it. On
Trustix, the swup utility did the same thing. It took less than half an
hour to do a dozen machines, with one person doing the work.

The Tru64 machines we had didn't come with SSH (Tru64 5.1B does come with
it; theirs isn't OpenSSH based, so it wouldn't have needed updating). We
had to download the source, compile it on one machine, tar up the compiled
binaries, distribute to all the machines, and untar and install on them.
It took about two hours to do all that across about a dozen machines, with
one person doing the work.

Lastly, the HP-UX machines use an SSH derived from OpenSSH. Last I checked
(on Friday), HP hadn't made a statement or provided a patch. Since there
also wasn't an exploit reliably reported, and our firewall doesn't allow
incoming SSH connections, we felt that leaving them unpatched for now was
an acceptable risk.

We probably could have spread out doing the Tru64 machines more, since
exploits are less likely to appear quickly for the Alpha architecture than
for the Intel-32 architecture, and none of the Tru64 machines were outside
the firewall.

If you don't have a full-time admin, I'd suggest staying with a
low-maintenance configuration, with something that puts out patches on a
timely basis and makes it easy to put them on. Heck... with Debian, you
could easily set up a cron job to either automatically patch every night,
or to notify you of which packages have upgrades available every night.

> But on a machine that sits unattended for long periods of time (a router,
> etc.) I think a better approach would be to use telnet for remote access.
> In such a circumstance, with long periods between remote logins I think
> the likelihood of being exploited by an ssh vulnerability might outweigh
> the likelihood of passwords being sniffed on the wire.
>
> Thoughts?

If you don't need people outside your organization to access it, then don't
allow SSH to it from outside. If you're more paranoid, only allow SSH
access from a few selected IPs. Both will help limit your vulnerability.

--
ZZzz |\ _,,,---,,_ Travis S. Casey <(E-Mail Removed)>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)

Jem Berkes wrote:
> Those of us paying attention will have surely noticed that SSH daemons are
> proving to be rather buggy; OpenSSH has had several remote exploits
> discovered including some major root exploits. And lsh -- suggested by many
> as a replacement to OpenSSH -- is itself vulnerable to a remote exploit
> http://www.securityfocus.com/archive...8/2003-09-24/0
>
> If ssh is to be considered 'more secure' than telnet, I think one has to
> take into account how often the admin is able to patch the machine. In an
> organization that employs a full time network techie, applying the ssh
> patches is an easy enough task.

SSH/lsh/etc. don't have to try *at all* to be more secure than telnet.
Since telnet sends everything across the net in the clear, it so vastly
insecure and so liable to having passwords stolen that there's no point
in reviewing it any further for comparison.

> But on a machine that sits unattended for long periods of time (a router,
> etc.) I think a better approach would be to use telnet for remote access.
> In such a circumstance, with long periods between remote logins I think the
> likelihood of being exploited by an ssh vulnerability might outweigh the
> likelihood of passwords being sniffed on the wire.
>
> Thoughts?

I think you're making an infortunately common mistake in evaluating the
relative risks.

> I think you're making an infortunately common mistake in evaluating
> the relative risks.

I think not. Not everybody's on ethernet One has to take into account
what type of connection you have to the server. Different situations have
different eavesdropping risks.

My server is connected via ADSL (point to point) to my ISP. I sure as hell
wouldn't telnet into my server from my University LAN, but if I'm at my
workplace -- which also uses DSL, I would be relatively comfortable doing a
telnet login.

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes wrote:
>>I think you're making an infortunately common mistake in evaluating
>>the relative risks.
>
>
> I think not. Not everybody's on ethernet One has to take into account
> what type of connection you have to the server. Different situations have
> different eavesdropping risks.
>
> My server is connected via ADSL (point to point) to my ISP. I sure as hell
> wouldn't telnet into my server from my University LAN, but if I'm at my
> workplace -- which also uses DSL, I would be relatively comfortable doing a
> telnet login.

You *shouldn't* be. Telnet should be blocked at the firewalls, because
of exactly this sort of man-in-the-middle attack of sniffing passwords.
And a lot of institutions, big ISP's included, use really poor security
on their switches. (Old and never-changed passwords, never resetting
default passwords, etc.). This leaves the switches vulnerable to having
someone reconfigure them to echo, say, all the telnet port traffic
through that gateway to a remote box that just sniffs the packets for
passwords.

Is this done commonly by crackers? *OF COURSE* it is, because it's very
difficult to detect but easy to do and they can reap a *lot* of
passwords from people who are careless.

> Is this done commonly by crackers? *OF COURSE* it is, because it's
> very difficult to detect but easy to do and they can reap a *lot* of
> passwords from people who are careless.

Why go to all this trouble and harvest a bunch of users passwords, when you
can run a well established exploit and instantly root pretty much any
university, small web site or clueless company using an ancient but
unpatched BIND, wu-ftp, sendmail, or (my favourite) RPC install?

Passwords are a dime a dozen.

Nico Kadel-Garcia <(E-Mail Removed)> writes:

>> which also uses DSL, I would be relatively comfortable
>> doing a telnet login.

(`Uses DSL' strikes me as a naff reason to be trusting of telnet, but I
can't quite pin down why...)

> You *shouldn't* be. Telnet should be blocked at the firewalls, because of
> exactly this sort of man-in-the-middle attack of sniffing passwords. And
> a lot of institutions, big ISP's included, use really poor security on
> their switches. (Old and never-changed passwords, never resetting default
> passwords, etc.). This leaves the switches vulnerable to having someone
> reconfigure them to echo, say, all the telnet port traffic through that
> gateway to a remote box that just sniffs the packets for passwords.

So if we were to start talking kerberos or some kind of s/key auth instead
of plaintext password, would that be any better? Yes, I know it would mean
the *content* of the data-stream would still be plaintext, of course.


I'm more or less of the opinion that for anything more than a simple
`GET'-type request, plaintext is out of the question. That means anon-FTP
is OK (good thing, too), HTTP is ok for GET requests, but as soon as you
start interacting (telnet for shell access) it's Bad.

~Tim
--
You take your message to the waters, |(E-Mail Removed)
And you watch the ripples flow |http://spodzone.org.uk/