Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Mac OS X Security Issue: Local Scripts

Skiniftz said:
Useless as it doesn't stop disk:// links being automounted.
Click to expand...

correct me if im wrong but it doesnt matter what opens "disk://" because in the end, when it tries to get the "help:" helper it'll stop it in it's tracks - because the vulnerability is w/ what opens 'help:' not 'disk:'
 
guerro said:
Is it really a vulnerability if the OS is just doing what it was designed and intended to do??? No. This is merely someone exploiting the way the operating system works. The real vulnerability with this is STUPID USERS. :rolleyes:
Click to expand...

Nope. It's still a flaw. There's a flaw in the design. In any case, exploitation of this only requires visiting a website. It's difficult to verify the trustworthiness of a website without visiting it, so there's no need to be stupid to be affected by this. There's plenty of cases where the problem is the user not using common sense, but this is not one of them.

Automatic Remote Application Execution = Flaw.
 
cryhavoc2112 said:
I disagree. If you aren't aware of proper surfing practices, don't surf.
Click to expand...

And you've actually been reading this thread, have you? The only "proper surfing" you could practice would be to not surf at all. I'm beginning to think that some people would think it was fine if all a PC was capable of doing safely was burning up electricity and expelling warm air. "Hey, it works great, so long as you don't turn it on!"
 
jessefoxperry said:
correct me if im wrong but it doesnt matter what opens "disk://" because in the end, when it tries to get the "help:" helper it'll stop it in it's tracks - because the vulnerability is w/ what opens 'help:' not 'disk:'
Click to expand...

You are correct in that help:// is needed to be accessed, however turning off "safe" attachments will not stop help opening, as it's not an attachment.

The dangerous part is the disk:// image automount, as it will contain the payload, as right now arguments cannot be passed to shell commands launched via the built in AppleScript exploit.

The disk:// launching is the "dangerous" part - if it didn't do that then it would not be so bad.
 
AmigoMac said:
If a Virus/Trojan has to be spread through Mail, using the Adress Book It wouldn't hit a big population of Mac Users, just for me would be unusuable, from my adress book I only have one "Mac Friend" the rest are Windows'ers and an applescript file would have no sense, worst a *.dmg file, I think that this whole thread of Mac Trojan/Virus comes from any Antivirus/Firewall Company or maybe from some Pro-MS-Place to create a bad atmosphere before WWDC, nevertheless, it's really neccesary tpo address this kind of issues within our OS, it's has been never a Virus/Trojan, it doesn't come to us, we have to go to it before it can operate, double-clicking or opening a homepage, but spread through an E-mail app would give less than 5% the infection efficiency expected from the writer...
Click to expand...
I agree that the amount of Mac users out there is most definitely a factor, which works in our favour at the moment as haxx0rs don't really have much to gain - it would probably fizzle out.

Now imagine if the latest version of NetSky turns up with this Mac exploit included along with a PC exploit in the same email. Not exactly difficult.

Instant multi platform virus. :(
 
Apple Hobo said:
LS didn't alert me of anything when I used Address Book. Maybe you were using a feature that needed to make a connection somewhere. :confused:
Click to expand...

Ok Addressbook connects to

homepage.mac.com on port 80

when you launch it. Still it's a bit scary and definatly unwelcome to some folks.
 
D*I*S_Frontman said:
So when will Apple be putting the fix into Software Update? Should we start a pool? Within one week? Two? Three? A month?
Click to expand...


I uh told Apple about it several months ago when it first appeared on slashdot.

Thought they fixed it long ago.
 
All apple need to do is change safari slightly so that when a disk image is downloaded a message box asks if the user wants to mount it or not. a simple yes/no with a warning that if you dont know what it is then don't open it.
 
Skiniftz said:
You are correct in that help:// is needed to be accessed, however turning off "safe" attachments will not stop help opening, as it's not an attachment.

The dangerous part is the disk:// image automount, as it will contain the payload, as right now arguments cannot be passed to shell commands launched via the built in AppleScript exploit.

The disk:// launching is the "dangerous" part - if it didn't do that then it would not be so bad.
Click to expand...

Okay, so for the idiots out there (like me, I confess), I need to change the helper app for not just the "help" protocol but also the "disk" protocol to something like Chess? I used the More Internet pref pane and changed the help protocol, but I didn't have a disk protocol listed, so I added one merely titled "disk" (I would have tried disk:// format but More Internet wouldn't allow colons). Is this correct?

Now the safe example opens Chess, but of course it's only testing the help protocol, if I understand correctly. Can someone make a safe example of the exploit that uses the disk protocol so I can test it too?
 
ElectricSheep said:
FWIW, this is how this thing works:

A user is directed to a page that does two things: (1) Downloads a disk image to the user's computer which will hopefully be automounted, and (2) redirects the page to the URL "help:runscript=MacHelp.help/Contents/Resources/English.lproj/shrd/OpnApp.scpt" with the argument "string='Volumes:0x04_script:0x04_script.term'"

What this does is instructs the Help Viewer application to send the «event helphdhp» AppleEvent to a script file located at a path relative to /Library/Documentation/Help/. If the script file does not respond to this Apple Event, nothing will happen. You cannot use this method to directly execute non-compiled applescript, binary executables, or applescript which is inline with the URL. You have to find a script which responds to «event helphdhp». I imagine that there are not a whole lot of these scripts save for the two bundled with the Help Viewer application itself: OpnApp.scpt and opnbndsig.scpt.
Click to expand...

I tried renaming the scripts to see if that would do anything, and the exploit seems to be prevented (both the webpage link and the .dmg versions). My question, though, is what do OpnApp.scpt and opnbndsig.scpt do that would be important to Help Viewer, such that I would not want to rename them, and I should instead try one of the other solutions, such as changing permissions?
 
After G said:
I tried renaming the scripts to see if that would do anything, and the exploit seems to be prevented (both the webpage link and the .dmg versions). My question, though, is what do OpnApp.scpt and opnbndsig.scpt do that would be important to Help Viewer, such that I would not want to rename them, and I should instead try one of the other solutions, such as changing permissions?
Click to expand...

They are used by help to open files as part of the help. For instance the take me to the blah blah preference or the go to blah blah website.

http://users.adelphia.net/~lively/fixbug.dmg has a script that replaces the current versions (its in more than one help file) with one that

1) won't launch an application (there is another script for that so that shouldn't be an issue)
2) won't open something off of a mounted volume, probably a good saftey measure.
3) asks before anything is opened.

Its not ready for localized versions of the help files.
 
Please !!

Changing OpnApp.scpt wont help !

The fixes from MongoTheGeek and Isophonic (iostream.h) are NOT ENOUGH !

Try http://bronosky.com/pub/AppleScript.htm - this isn't a complete exploit, but coupled with the disk: protocol it is. (Edit: to be more precise: Try this link "help:runscript=../../Scripts/Info%20Scripts/Current%20Date%20&%20Time.scpt")


The ONLY good fix is to map the "help:" protocol to start something other than HelpViewer. - Note that this apparently won't affect the help system in any way ! (do this with Internet Explorer -> Settings -> Network -> Protocol Helpers)

It would be really easy for Apple to issue a quick fix that just changed the "help:" protocol (or somehow removed it). I guess they aren't in any hurry since noone has exploited this in a bad way...yet.
 
MongoTheGeek said:
It will break some ways of getting to the help system.
Click to expand...

Ok, I haven't noticed. Could you please be more specific ?

Well, starting help from a website comes to mind, but who does that anyway ? :)
 
Everyday someone trys to find some way to say somthing bad about the Mac OS. The last update have fixed this problem and i dont think that there should be anything to worry about, such as worms and viruses. I dont think you have anything to worry about. Microsoft put out XP and a minute later there come thoese security updates. I just have to say im happy that i dont have to deal with another computer that has to use windows updates. All i have to say is the next best thing to the MAC OS is open sorce.


Bobby The Gibbons
crazybobby.com
 
When I try it that way, Help Viewer launches and that's it. The script itself doesn't run. Seems DGTGF does it's job well.
 
garybUK said:
All apple need to do is change safari slightly so that when a disk image is downloaded a message box asks if the user wants to mount it or not. a simple yes/no with a warning that if you dont know what it is then don't open it.
Click to expand...

Or along with the auto-open safe attachments preference. There could be an auto-mount disk images feature (which when turned off Safari or the Finder would prompt you if you really want to mount the image).
 
Ok, here...

tkn0spdr said:
When I try it that way, Help Viewer launches and that's it. The script itself doesn't run. Seems DGTGF does it's job well.
Click to expand...

Ok, I give up.

Here is a real example - although in steps so you can see what happens. Of course totally harmless, and nothing will happen before you click a link from the linked page.

The disk image actually was stolen from lixlpixel - the person who discovered this security hole initially.
 
Hugin777 said:
Ok, I give up.

Here is a real example - although in steps so you can see what happens. Of course totally harmless, and nothing will happen before you click a link from the linked page.

The disk image actually was stolen from lixlpixel - the person who discovered this security hole initially.
Click to expand...

Alright, those still worked. Hey, I wasn't trying to argue with you I just wanted to test the limits of the 'fix' that I had applied. Seems it wasn't good enough. I changed the help URI and now it seems I'm safe even from those.
Thanks.
 
tkn0spdr said:
Alright, those still worked. Hey, I wasn't trying to argue with you [..]
Click to expand...

I'm sorry. I'm just frustrated on isophonic.net because I have written them twice, and they still make people believe that they are secured by their fix when they are not... :mad:
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back