Safari Falls Victim to Remote Code Exploit

A user writes, "A new vulnerability has been found in Mac OS X's Safari, which will launch Help.app and run an arbitrary script with a URL like 'help:runscript=...', assuming a known path (which is possible when Safari is set to automount disk images (which is the default)). A nice working demonstration is available on insecure.ws while the incident has been reported on Full-Disclosure."

Comments

Is this worth a story?

[0x0d0a]

I'm all for calling Apple out on security violations when they deserve it (especially since there have been some awfully generous and inaccurate security claims about Mac OS X), but if there was a Slashdot story for every exploit against a web browser, we'd be reading nothing else.

If it was exploitable and used in an *email* client (a la Outlook using the MSIE rendering engine), *then* I could see some serious cause for concern, as the worm potential is severe.

However, this is ultimately a client-level attack that requires the user to pull down malicious data. It just isn't a big deal.

Re:Is this worth a story?

[I_Love_Pocky!]

I don't know about you, but I don't always take a look at my status bar before I click on a link. It is kind of nice to know such a exploit exists, because now I will be more careful (until Apple releases a patch). It is rediculous that a url can be used to execute malicious code.

On a related note, Safari is one of the best browsers I have ever used. I hope Apple releases a fix for this quickly.

Re:Is this worth a story?

[mcgroarty]

"It just isn't a big deal"

One concealed tinyurl link on Slash or an Apple forum, or a tiny frame with a redirect to:

<a href=help:runscript=/bin/rm%20-Rf%20%2f>

is enough to run "rm -Rf /". Wiping out all user data with half a line of html isn't a big deal?

All companies have their own share of browser bugs, but this one's a doozy, so don't play it down. Prudence says you should exercise the utmost caution or use Mozilla until there's a fix.

Re:Is this worth a story?

[SandSpider]

Ah, but do you allow tinyURLs? 'Cause that's what the grandparent post is suggesting. However, that particular exploit won't work, because it's neither formed properly, nor is it calling a script. However, there are other ways of running the exploit, and even linking it on slashdot, whether in a comment or otherwise.

=Brian

Um, what privilidges does it run at?

[Llywelyn]

From the bulletin:
---------------
This can potentially wipe the entire hard-disk (or large parts of it),
if a hacker runs a script with "rm -rf /" included.
---------------

Unless this has a built-in privilege escalation, I don't see how this is true. If it just runs as the user (which it appears to) then you could erase the users information that way, but not the disk.

Re:Um, what privilidges does it run at?

[Per Wigren]

If it just runs as the user (which it appears to) then you could erase the users information that way, but not the disk.

Oh, so it will just erase all of my 100s of hours of work but not the reinstallable OS? What a relief!

Re:Um, what privilidges does it run at?

[mst76]

But the user's information is the most important part of a personal computer. On a corporate Unix system with many users, privilege separation is great: if one user messes up, others won't notice a thing. For home users, an OS reinstallation is not too problematic (especially MacOS). But the typical home user does not backup every night. It's their personal information that matters most. I think the most prudent thing to do for a home PC is to make a separate low-privilege account for all internet activities. On Windows, start the browser and mail with runas, on Unix use su.

Re:Um, what privilidges does it run at?

[pudge]

An admin user has privileges to delete files other than those merely in his HOME. And some stupid users (including one of my friends :-) have changed perms to give themselves ownership of every file, in which case this would wipe every file. So the statement is accurate.

Re:Um, what privilidges does it run at?

[imnoteddy]

Oh, so it will just erase all of my 100s of hours of work but not the reinstallable OS? What a relief!

No one should never do 100s of hours of work between backups. If someone does it indicates either that they really don't care if they lose it or that they're stupid.

Re:Um, what privilidges does it run at?

[skinfitz]

Unless this has a built-in privilege escalation, I don't see how this is true. If it just runs as the user (which it appears to) then you could erase the users information that way, but not the disk.

Show me one Mac owner that doesn't log on using an administrator class account (default, no password, auto logon).

I have never, ever, known any Mac owner (myself included) to create a "Standard" user account for their own personal use.

This exploit could destroy a lot of work, and don't give me the "you're an idiot if you don't back up" line, as it's not the point.

Re:Um, what privilidges does it run at?

[harlows_monkeys]

Unless this has a built-in privilege escalation, I don't see how this is true. If it just runs as the user (which it appears to) then you could erase the users information that way, but not the disk

So, basically, it can't wipe out those parts of the disk that are trivial to restore from the system install CDs, and instead only gets the parts that are actually important to the user? How comforting. :-)

Re:Um, what privilidges does it run at?

[drsmithy]

And with fast user switching it's a breeze.

As long as you don't want to do something rare and uncommon like, say, copy & paste between your "unsafe stuff" and anything else...

Re:Ummmmmm

[I_Love_Pocky!]

I would guess the team (or more possibly even the individual) working on the "help" system probably didn't have security as their top priority. Infact, I would be suprised if they even thought about it.

Yes, it probably is

[Tor]

I get the impression (only from the /. blurb so far) that this hole is, by orders of magnitude, more serious than anything reported for Mac OS X previously.

Most "vulnerabilites" previously reported for Mac OS X have been largely theoretical, obscure, and hardly any real threat (at least, when compared to the pretty high threshold of threat before anyting is considered a "flaw" in the Windows world).

Don't misunderstand, more serious stuff than this is pretty much standard fare for Windows (and sometimes on UNIX/Linux to, cf. "wu-ftpd", "bind", and "sendmail") - but for the Mac OS X platform, a flaw as "exploitable" as this is pretty unique.

'Course, if will probably be taken care of within a few days via "software update", if not already.

-tor

Re:Yes, it probably is

[log0n]

This is pretty much the same thing. There have to be 1, 2, 3, etc steps that all have to work, or you can't get the desired result. It's not a reproducable "bug". IMO, this is a kind of 'social engineering' stunt for OSX software (it takes advantage of a mindset more than actually breaking something in OSX).

$.02

Workaround

[fsck!]

rm -rf /Applications/Help.app

This awful help tool is as bad as they come. It's clumsy, slow, and most of the help appears to be online anyway. Apple should just make Safari the help browser to begin with. I haven't examined this much, but it looks like thelp documentation is XML or HTML anyway.

possible scenario

[Anonymous Coward]

Help-team: let's base our help app on html, which is the de-facto standard markup language now. Oh, and let's give it the ability to launch scripts, so we can give live demo's in the help files.

Browser-team: of course we're not going to let scripts with full user-privileges run from within the browser by default, that's idiotic. Who do you think we are, Microsoft? Hey, the help app is based on html right? Let's stick a help: protocol in the URL handler, that would be convenient.

Re:Try Camino

[geoffspear]

From the Full Disclosure article, it does not appear that switching to another browser will help a bit. This is NOT a flaw in Safari, but a flaw in the way the OS handles help: URLs. Any browser that uses the system's settings to decide what helper application to use for a given URL is vulnerable, and any browser that doesn't obey those settings is a badly behaved app.

Fortunately, changing the app that handles help: URLs fixes the problem; unfortunately, OS X by default doesn't include a utility to change those settings. (Actually, IIRC Internet Explorer can do it, creating the irony that you need to use IE to fix a vulnerability in an y other browser. Or get a third-party utility).

Re:Pudge, you got it WRONG! More serious than this

[Anonymous Coward]

You misunderstood.

Setting .help files (those don't even exist on Mac OS X) to something else is of no use. You need to set the help: protocol to something else than Help Viewer.

Possible workaround ...

[Durandal64]

I'm too lazy to try and implement this, but what you could do is write an AppleScript to receive all calls to the help protocol. So whenever there's a help: URL, your little AppleScript goes up, notifying you that something is trying to open a help: URL, which is a security vulnerability. Then either allow or deny. If the user allows it, pass the URL along to Help Viewer.app. Then just use something like MoreInternet to point the help: protocol to that script.

Like I said though, I'm too lazy to try it right now.

Help Viewerrrrrrrrr

[TitanBL]

Just one more reason for Apple to rethink the whole 'Help Viewer' implementation. I don't know about you, but I despise that sluggish POS (I hate that spinning beachball). I do not even bother using it. It is faster to find 'help' via a google search. It is without question the LAMEST aspect of OS X.