telnet: exploit and security update

Apple's recent security update appears to solve the exploits involving
help: urls. It does nothing about the telnet: exploit though, so
users should contintue to disable that url type for now. A suitably
configured telnet: url can clobber any one file that the current user
has the privileges to delete (though it doesn't actually delete the
file; it makes a new one with same name in the same directory, thus
making the old contents inaccessible). Btw this particular exploit
isn't osx-specific. It's also been demonstrated in Linux and Windows.

Given that Apple seems to have been prompted into responding to the
help: url issue at least in part by all the noise on this newsgroup, I
recommend we make equally much noise over the telnet: issue.

The security update also does nothing about disk: urls, but afaik this
url type is no more destructive in and of itself than an ftp: url. It
was its use on conjunction with help: that was potentially very
dangerous, and that seems to be taken care of now. Personally, I've
re-enabled disk: on my systems.

In article <>, noman <>
wrote:

> Given that Apple seems to have been prompted into responding to the
> help: url issue at least in part by all the noise on this newsgroup, I
> recommend we make equally much noise over the telnet: issue.

Why not rename telnet?

$ sudo mv /usr/bin/telnet /usr/bin/xtelnet

No need to monkey with the helper protocols or download more software.
If you ever need to use telnet you can type xtelnet in Terminal instead.

Just a thought...

Regards

--
Martin

On 2004-05-22, Martin <> wrote:
> Why not rename telnet?

Because disabling the telnet: protocol is just as easy and much less
of hack. The problem is with the url processing, not with the telnet
executable. The fix should go where the problem is.

In article <>, noman <>
wrote:

> On 2004-05-22, Martin <> wrote:
> > Why not rename telnet?
>
> Because disabling the telnet: protocol is just as easy and much less
> of hack. The problem is with the url processing, not with the telnet
> executable. The fix should go where the problem is.

Don't believe that that is true.

How do you disable the protocol on OS X using a method that is more
simple that renaming telnet? (And killing telnet with a hack would be
doing users a favour anyhow.)

You can't disable a protocol without downloading and installing a
third-party app.

Apple never wanted users to make that kind of decision on OS X - and now
they've been bitten. Hopefully somebody at Apple is doing what they
should have done 4 years back by writing a new System Preference right
now.

How embarrassing that mac users should have had to using Microsoft
products to do simple stuff like make changes to the helper apps and
protocols!

Regards

--
Martin

On 2004-05-22, Martin <> wrote:
> How do you disable the protocol on OS X using a method that is more
> simple that renaming telnet?

The Default Apps preference panel. If you haven't installed this by
now, you haven't been paying attention...


> Apple never wanted users to make that kind of decision on OS X

This is just wrong. 10.0 and 10.1 came with an Apple-supplied
preference panel. I don't remember now whether it was removed with
10.2 or 10.3. Given recent developments, my guess is it will come
back to life soon. And if it doesn't, what exactly is wrong with
using somebody else's excellent freeware implementation? In the Linux
world this happens all the time.

In article <user->,
Sander Tekelenburg <> wrote:

> In article <c8ntck$a7e$4$>,
> Martin <> wrote:
>
> > In article <>, noman <>
> > wrote:
> >
> > > Given that Apple seems to have been prompted into responding to the
> > > help: url issue at least in part by all the noise on this newsgroup, I
> > > recommend we make equally much noise over the telnet: issue.
> >
> > Why not rename telnet?
>
> Which one?

The one that stops the exploit that is mentioned in this thread.

Renaming the telnet in usr/bin stops this exploit working in Safari, IE
and OmniWeb.

If you have a method of calling another variant, let us know.

> There are more apps that can do telnet than just the cli one
> that Apple supplies. Some Web browsers seem to have it built-in even and
> may not pass a telnet URL on to /usr/bin/telnet at all.

And if they write out a log file using -n or -f then we can approach the
writers/publishers.

Renaming telnet appears to stop the exploit that is *on-topic* in this
thread.

Regards

--
Martin

In article <>, noman <>
wrote:

> On 2004-05-22, Martin <> wrote:
> > How do you disable the protocol on OS X using a method that is more
> > simple that renaming telnet?
>
> The Default Apps preference panel. If you haven't installed this by
> now, you haven't been paying attention...

Thanks for making my point - you can't do it without installing a
third-party app.

>
> > Apple never wanted users to make that kind of decision on OS X
>
> This is just wrong.

Really...

> 10.0 and 10.1 came with an Apple-supplied
> preference panel. I don't remember now whether it was removed with
> 10.2 or 10.3. Given recent developments, my guess is it will come
> back to life soon. And if it doesn't, what exactly is wrong with
> using somebody else's excellent freeware implementation? In the Linux
> world this happens all the time.

You're confusing the choice of default web browser and mail client with
the kind of choices that are available when you look at the protocol and
helper preferences in IE.

Even these *basic* preferences have gone from Panther, but still exist
in Panther Server if you use WorkGroup Manager.

Apple don't want users making decisions on this kind of stuff. If they
did, they'd have provided a gui to enable the editing
com.apple.LaunchServices.plist. They don't, they never have.

And what's wrong with "using somebody else's excellent freeware
implementation"? - we shouldn't have to. Basic tools like this should be
available as part of the OS.

--
Martin

On 2004-05-22, Martin <> wrote:
> You're confusing the choice of default web browser and mail client

Yeah, ok, I forgot the details of a pref panel that disappeared a year
or two ago. I stand corrected.

That doesn't make removing /usr/bin/telnet any less wrong-headed.
Telnet is not the problem; osx's url handling is.

In article <>, noman <>
wrote:

> On 2004-05-22, Martin <> wrote:
> > You're confusing the choice of default web browser and mail client
>
> Yeah, ok, I forgot the details of a pref panel that disappeared a year
> or two ago. I stand corrected.
>
> That doesn't make removing /usr/bin/telnet any less wrong-headed.
> Telnet is not the problem; osx's url handling is.

I couldn't agree with you more.

The person that came up with "telnet://" needs shooting.

I hope it isn't the same person that came up with "applescript://"
because I find that one quite useful ;-)

Regards

--
Martin

In article <c8oid3$j1i$1$>,
Martin <> wrote:

> In article <>, noman <>
> wrote:
>
> > On 2004-05-22, Martin <> wrote:
> > > You're confusing the choice of default web browser and mail client
> >
> > Yeah, ok, I forgot the details of a pref panel that disappeared a year
> > or two ago. I stand corrected.
> >
> > That doesn't make removing /usr/bin/telnet any less wrong-headed.
> > Telnet is not the problem; osx's url handling is.
>
> I couldn't agree with you more.
>
> The person that came up with "telnet://" needs shooting.

Like many of the security problems on the Internet, it dates back to the
early days, when most Internet users were trustworthy and designers
didn't worry as much about these things.

Could someone explain this exploit? I just searched at MacFixit and
couldn't find anything relevant.

--
Barry Margolin,
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***