Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

May 19, 2004

Remote Exploit for MacOSX

[Via Jay Allen] This is the sort of thing one expects from our friends in Redmond.

  1. Help Viewer.app will happily run scripts on your local machine.
  2. Help Viewer.app is the default helper application for help://... URI’s.
  3. Ergo an evil web master can execute scripts on your computer by redirecting an (innocent-looking) link that you click on to a help:runscript=/path/to/some/script.scpt URL.

By itself, this is limited to executing scripts or applications that are already on your machine (this includes the ubiquitous OpnApp.scpt, which can execute shell commands). For extra fun, Mr. Evil can get you to remote-mount a disk image by redirecting you to a disk://... URL, and then use the previous trick to run an application on the mounted disk image.

That is really, really, evil.

Workaround: Use the RCDefaultApp PreferencePane to disable the help://... helper application. And, similarly, disable disk://... and disks://... .

Update (5/21/2004): Apple has released an update to Help Viewer.app to address this issue, Security Update 2004-05-24 (also available through Software Update):

HelpViewer: Fixes CAN-2004-0486 to ensure that HelpViewer will only process scripts that it initiated. Credit to lixlpixel <me@lixlpixel.com> for reporting this issue.

Update (5/22/2004): John Gruber points out another vulnerability, this time in Terminal.app’s handling of the telnet:// URI scheme. Following a

telnet://-npath%2Fto%2Fsome%2Ffile

will overwrite any file you have write-access to. Best to disable that URI scheme too, until Apple fixes Terminal.app. (It’s fixed in 10.3.4.).

Posted by distler at May 19, 2004 1:56 AM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/365



5 Comments & 0 Trackbacks

Re: Remote Exploit for MacOSX

As in the OpenBSD motto: “Only one remote hole in the default install, in more than 8 years!”

Posted by: Volker Braun on May 19, 2004 8:45 AM | Permalink | Reply to this

Re: Remote Exploit for MacOSX

I’ve been trying to raise this problem for months. I didn’t know how it would be finally exploited, but I knew it would happen… and here it is.

The basic problem is that Apple has been making the same mistake Microsoft did nearly a decade ago, in setting up tight integration between the Internet and the desktop.

http://scarydevil.com/~peter/io/osx-security.html

Don’t let apple sweep this under the rug by simply “fixing” the help application. They need to rebuild the wall between the untrusted and untrustable Internet and your local system, pronto.

Posted by: Peter da Silva on May 19, 2004 10:04 AM | Permalink | Reply to this

Rebuild the Wall

Peter, I’ve taken the liberty of fixing the nonfunctional hyperlink in your comment (you really are allowed to use HTML in your comments here).

You certainly have hit the nail on the head in your open letter. “Helper Apps” need to be carefully scrutinized for their ability to safely handle untrusted data. And some URI schemes (in this case, help://...) should clearly be treated as “local-only”.

The trouble is defining clearly what’s “local”. Many of the MS security holes have come from tricking the system to treat untrusted data as coming from the Local Security Zone. Consider, for instance, an off-line NewsAggregator that caches data locally for reading off-line. Is that cached data to be trusted because it’s being read from a local file? Heck, no! But how does the OS distinguish that local file (which should not be trusted) from a local help file (which should)?

Posted by: Jacques Distler on May 19, 2004 10:30 AM | Permalink | PGP Sig | Reply to this

Re: Rebuild the Wall

I missed your response, sorry. Thanks for fixing the link.

The key difference between what I’m proposing and what Microsoft does is this: there’s really only one component of this system that knows whether a document is really local or not, and that’s the program that’s presenting it to the HTML engine. The news aggregator, for example, would present the page to the HTML engine (Microsoft’s HTML control, Web Objects, Konqueror?), and it would control how links in that page were resolved.

This would mean that you couldn’t just stick the files in a local folder and point Safari or IE at them, which is more or less what a lot of these programs do. It would mean that you would either have to pass a flag to the engine that said “this is untrusted”, or that the engine would make callbacks to you to resolve embedded objects and links.

Personally I prefer the latter, even if it’s a little more work then the former, because it allows you to take better control of the system (I have run afoul of this myself… it’s impossible to keep the HTML control from finding a link and following it without duplicating a lot of Microsoft’s code), and because it’s easy to write a wrapper that turns it into the former than the other way around.

I’ll see about cleaning up my page to make that distinction more obvious.

Posted by: Peter da Silva on August 5, 2004 2:22 PM | Permalink | Reply to this

Re: Remote Exploit for MacOSX

Hey I’m not evil. ‘twas a just a wee demo! ;-)

Anyway I took it down to avoid people thinking I was up to no good. I did succeed in creating a full-blown click-the-link and get compromised, btw, but never advertised it and it’s down now.

Posted by: Brent on May 21, 2004 7:32 PM | Permalink | Reply to this

Post a New Comment