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 (Page 8)
Thread Tools
turtle777
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status: Offline
Reply With Quote
May 21, 2004, 10:58 PM
 
Originally posted by smeger:
My test exploit (page contains a link, not the exploit itself) still works. I'm uncomfortable with this as well.
In my opinion, the SU, just put out prematurely, as we know, makes the situation even worse.

Most likely, with all the past publicity, Apple will now be praised for reacting so quickly, without mentioning that more serious security issues are still unresolved. As an effect, people will just blindely trust this SU, without being cautious anymore.

And this is as dangerous as the original situation, because the exploit is still simple and easy to deploy.

Even more scary: Apple might not take additional warnings and reports seriously. I am still rather upset and scared...

-t
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 21, 2004, 11:15 PM
 
Originally posted by turtle777:
In my opinion, the SU, just put out prematurely, as we know, makes the situation even worse.

Most likely, with all the past publicity, Apple will now be praised for reacting so quickly, without mentioning that more serious security issues are still unresolved. As an effect, people will just blindely trust this SU, without being cautious anymore.

And this is as dangerous as the original situation, because the exploit is still simple and easy to deploy.

Even more scary: Apple might not take additional warnings and reports seriously. I am still rather upset and scared...

-t
If they do, they ought to know by know that we've already got it all over the Internet. Hopefully, they'll be smart enough to avoid another PR disaster...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
MindFad
Posting Junkie
Join Date: Sep 2001
Status: Offline
Reply With Quote
May 22, 2004, 12:19 AM
 
Yeah, the update didn't fix the DMG exploit. I tried smeger's little exploit. That's pretty scary. What needs to be fixed to prevent this from happening? This should be easy for Apple to fix, right? Just prevent Safari from opening DMGs like that? Yeesh, Apple should be all over this; hopefully they are.

Speaking of how big this may be, part of the news on Air America Radio today was the security hole in OS X (though the news person said "oh ess ex")! Though they said it made your computer "vulnerable to hackers," which isn't the case, correct?
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 22, 2004, 12:43 AM
 
Originally posted by MindFad:
Yeah, the update didn't fix the DMG exploit. I tried smeger's little exploit. That's pretty scary. What needs to be fixed to prevent this from happening?
I think if LaunchServices behaved like I originally thought it behaves, i. e. URL Schemes are only register if an app is either "installed" ((~)/Applications, /Core Services, ...) at log-in time or has been launched at least once before, then this wouldn't be a problem any more. Also probably default assignments to non-existing apps should be removed.
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.
     
MindFad
Posting Junkie
Join Date: Sep 2001
Status: Offline
Reply With Quote
May 22, 2004, 01:13 AM
 
Man, I'm still freaked out by that. Hopefully they fix that soon somehow. I never thought I'd need to be cautious of websites on my Mac. Almost makes me want to run off screaming back to OS 9. Almost.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 01:31 AM
 
Originally posted by MindFad:
Man, I'm still freaked out by that. Hopefully they fix that soon somehow. I never thought I'd need to be cautious of websites on my Mac. Almost makes me want to run off screaming back to OS 9. Almost.
Turn off "safe" files and remap disk: to Chess using More Internet, and that should be able to keep you relatively safe.

Also, you can redirect telnet: to Chess if you are worried about that.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 03:39 AM
 
Originally posted by CharlesS:
Turn off "safe" files and remap disk: to Chess using More Internet, and that should be able to keep you relatively safe.

Also, you can redirect telnet: to Chess if you are worried about that.
Well, yes; relatively It won't protect you against my exploit example . . .
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 03:51 AM
 
Originally posted by turtle777:
In my opinion, the SU, just put out prematurely, as we know, makes the situation even worse.

Most likely, with all the past publicity, Apple will now be praised for reacting so quickly, without mentioning that more serious security issues are still unresolved. As an effect, people will just blindely trust this SU, without being cautious anymore.

And this is as dangerous as the original situation, because the exploit is still simple and easy to deploy.

Even more scary: Apple might not take additional warnings and reports seriously. I am still rather upset and scared...
Well, I must admit that I really don't consider the threat to be that high.

And publicizing the new, still unfixed, vulnerability won't do Apple any good. They probably first heard about it from you, so they really haven't got the chance to fix this yet.

I'm debating with myself whether to alarm everyone on the forums I visit, or keep it low and just warn if someone feels too safe
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 05:17 AM
 
Originally posted by Hugin777:
Well, yes; relatively It won't protect you against my exploit example . . .
My ftp: protocol is mapped to Fetch, so that one is thwarted too on my machine...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 05:32 AM
 
Originally posted by CharlesS:
My ftp: protocol is mapped to Fetch, so that one is thwarted too on my machine...
Well, yes, but my page is just an example. (Edit: and MindFad may not use Fetch )

I could have used any of afp: disk: disks: ftp: (or whatever)

- I just did a
find / -name Info.plist -exec grep -q CFBundleURLTypes '{}' \; -print
and this is what it found:
/Applications/Address Book.app/Contents/Info.plist
/Applications/AppleScript/Script Editor.app/Contents/Info.plist
/Applications/FTP:SFTP/Cyberduck.app/Contents/Info.plist
/Applications/FTP:SFTP/LifTP.app/Contents/Info.plist
/Applications/FTP:SFTP/RBrowserLite.app/Contents/Info.plist
/Applications/FTP:SFTP/Transmit.app/Contents/Info.plist
/Applications/iCal.app/Contents/Info.plist
/Applications/iChat.app/Contents/Info.plist
/Applications/iTunes.app/Contents/Info.plist
/Applications/Lyd, Video og CD'er/RealOne Player.app/Contents/Info.plist
/Applications/Lyd, Video og CD'er/VLC.app/Contents/Info.plist
/Applications/Lyd, Video og CD'er/Windows Media Player.app/Contents/Info.plist
/Applications/Mail.app/Contents/Info.plist
/Applications/Net-ting, IM, etc./Adium.app/Contents/Info.plist
/Applications/Net-ting, IM, etc./Conversation.app/Contents/Info.plist
/Applications/Net-ting, IM, etc./Fire.app/Contents/Info.plist
/Applications/Net-ting, IM, etc./Opera.app/Contents/Info.plist
/Applications/Office/SubEthaEdit.app/Contents/Info.plist
/Applications/Quicksilver.app/Contents/Info.plist
/Applications/QuickTime Player.app/Contents/Info.plist
/Applications/Safari.app/Contents/Info.plist
/Applications/Sherlock.app/Contents/Info.plist
/Applications/Utilities/Terminal.app/Contents/Info.plist
/Developer/Applications/Interface Builder.app/Contents/Info.plist
/System/Library/CoreServices/DiskImageMounter.app/Contents/Info.plist
/System/Library/CoreServices/Finder.app/Contents/Info.plist
/System/Library/CoreServices/Help Viewer.app/Contents/Info.plist
/System/Library/Filesystems/URLMount/afp.URLMounter/Contents/Info.plist
/System/Library/Filesystems/URLMount/ftp.URLMounter/Contents/Info.plist
/System/Library/Filesystems/URLMount/http.URLMounter/Contents/Info.plist
/System/Library/Filesystems/URLMount/nfs.URLMounter/Contents/Info.plist
/System/Library/Filesystems/URLMount/smb.URLMounter/Contents/Info.plist
/System/Library/PrivateFrameworks/DevToolsInterface.framework/Versions/A/Resources/Info.plist
- Each one of these could potentially have a trap door which could (amongst other things) mount disk images remotely...


Edit: Maybe Fetch registers a logInAsRoot: URLHandler - and now that I know you have Fetch installed you are owned (if I just could get you to try my test page - hmm... )
( Last edited by Hugin777; May 22, 2004 at 10:27 AM. )
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 06:18 AM
 
Originally posted by Hugin777:
- Each one of these could potentially have a trap door which could (amongst other things) mount disk images remotely...
This is the list of common URLHandlers on Mac OS X, FYI:
Code:
addressbook: Address Book afp: afp.URLMounter, Finder aim: iChat applescript: Script Editor cifs: smb.URLMounter daap: iTunes disk: DiskImageMounter disks: DiskImageMounter file: Finder, Safari, RealOne Player, Opera ftp: Finder, ftp.URLMounter, VLC, Opera ftps: ftp.URLMounter help: Help Viewer http: Safari, Opera, http.URLMounter, VLC https: Safari, Opera hydra: SubEthaEdit ical: iCal iChat: iChat itms: iTunes itmss: iTunes mailto: Mail mms: VLC, Windows Media Player mmst: Windows Media Player mmsu: Windows Media Player nfs: nfs.URLMounter nib: Interface Builder pnm: RealOne Player qs: Quicksilver qss-http: Quicksilver qssp-http: Quicksilver rtsp: Safari, RealOne Player sherlock: Sherlock smb: smb.URLMounter ssh: Terminal telnet: Terminal udp: VLC webcal: iCal x-man-page: Terminal

Edit: my point is: Don't think you are safe surfing unsafe sites
( Last edited by Hugin777; May 22, 2004 at 06:29 AM. )
     
alcatholic
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 22, 2004, 06:54 AM
 
Originally posted by CharlesS:
I figured that the thing started with my little flamewar with kampl when I brought LaunchServices into the mix:

http://forums.macnn.com/showthread.p...=4#post1994990

with the sudden "Oh Crap" realization I added with an edit. That led to Developer doubting whether LaunchServices would cache the creator code on browsing, my proposal of the tn3270: exploit, and finally your realization that the problem was even worse than I thought it was by pointing out that it would work with any fake protocol.

If you came up with the protocol idea independently, and just didn't post until we were discussing LaunchServices, than that makes it okay and I don't have to feel guilty anymore, I guess. I'm still somewhat upset at this whole thing, though...
Actually, Developer was the first to spell out the possibility of "phantom" protocols after you brought LaunchServices into the mix. smeger was the first to demonstrate.
Here is Developer's very astute recognition of some ramifications IF LaunchServices cached creator code AND url protocols. He took your concept of creator code caches and extended it to the url protocol caching. But you're right he doubted the "smart" caching took place until you demonstrated.
http://forums.macnn.com/showthread.p...=5#post1995063

All in all, the three of you worked very quickly to a deep understanding once kampl's questions helped CharleS bring LaunchServices into the mix.

The sad thing is now that this thread has helped me understand the deep nature of the hole, I cannot load the only defense, PA, as I have Jaguar.

BTW, am I wrong, or are we one mass email away from an outbreak? Isn't it enough to unwittingly click on a link in an email? Could an app be written to then propogate the email from owned machines? I don't know how email works on the Mac in the sense of unwittingly spreading viruses as in Windows.
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 22, 2004, 07:24 AM
 
Originally posted by Hugin777:
I'm debating with myself whether to alarm everyone on the forums I visit, or keep it low and just warn if someone feels too safe
I recommend keep it somewhat low. I rushed out to early just after the Slashdot story hit the front page, alarmed everyone, and I've felt obligated to update every new detail on the story there* since then. Because of the nature in this situation, there will be some confusion. Question is; is it worth the effort? - It probably is, but there is no end to this until Apple is out with a patch that covers all the bases. Just a thought.

*..on the other forum community I frequent visit.
( Last edited by sniffer; May 22, 2004 at 11:29 AM. )

Sniffer gone old-school sig
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 22, 2004, 07:33 AM
 
Originally posted by alcatholic:
...

BTW, am I wrong, or are we one mass email away from an outbreak? Isn't it enough to unwittingly click on a link in an email? Could an app be written to then propogate the email from owned machines? I don't know how email works on the Mac in the sense of unwittingly spreading viruses as in Windows.
Yup, I am pretty grateful to lixlpixel, CharlesS, Developer, Smeger and others for having been so on the ball about this -I'm the 1337 person who relaised you can do all of this just by landing on an infected page. Thank you. I take checks and Credit Cards -

At the moment, I have the following protocols all pointed towards chess (It might become a very active application in the near future, but I really hope not)
help: -> chess, and staying there as it still works well.
ftp: -> chess, and staying there as it still works well in the finder or terminal.
telnet: -> chess, and staying there as it still works well. (who actually uses telnet these days anyway???)
afp: -> chess, and staying there as it still works well.
smb: -> chess, and staying there as it still works well.
disk: -> chess, and staying there as it still works well.
tn3270: -> chess, and staying there as it still works well. (not really necessary, as you can't mount anything with this)

I don't really want to install PA as I have an allergy against too many doodahs on my system (although it really is great I think and is light years ahead of Apple's fix). I really hope this SU from Apple was only a start and that they will release a more comprehensive fix in the near future. If they don't then I'm in the market for x86 machines again.
weird wabbit
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 22, 2004, 07:36 AM
 
Originally posted by sniffer:
I recommend keep it somewhat low. I rushed out to early just after the Slashdot story hit the front page, alarmed everyone, and I've felt obligated to update every new detail on the story there since then. Because of the nature in this situation, there will be some confusion. Question is; is it worth the effort? - It probably is, but there is no end to this until Apple is out with a patch that covers all the bases. Just a thought.
Pudge is a clown. he knew full well that the vulnerability was more serious but decided to ignore it, being the Apple fanboy that he is. At least, though, the lates Slashdot story mentions that Apple's SU doesn't fix anything apart from help:runscript
weird wabbit
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 07:51 AM
 
Originally posted by theolein:
At the moment, I have the following protocols all pointed towards chess (It might become a very active application in the near future, but I really hope not)
help: -> chess, and staying there as it still works well.
ftp: -> chess, and staying there as it still works well in the finder or terminal.
telnet: -> chess, and staying there as it still works well. (who actually uses telnet these days anyway???)
afp: -> chess, and staying there as it still works well.
smb: -> chess, and staying there as it still works well.
disk: -> chess, and staying there as it still works well.
tn3270: -> chess, and staying there as it still works well. (not really necessary, as you can't mount anything with this)
As far as I can see, you are still vulnerable if using webdav: (and possibly disks: ) and any of the following (with the corresponding App Code):

finger:
netphone:
wais:
whois:
x-netphone:

Edit: At least on my system these URI shemas are present, just waiting for the Right App to come along. YMMV

Edit 2: This is Re: the "default Orphan URI schemas" vulnerability. Of course any non-registered URI schema will work presently.

Edit 3: Ok, maybe not webdav: But maybe cifs: disks: ftps: and nfs: ?

Edit 4: Apparently cifs: ftps: and nfs: are safe. Only disks: remain.
( Last edited by Hugin777; May 22, 2004 at 10:25 AM. )
     
dirtymouse
Fresh-Faced Recruit
Join Date: May 2004
Location: Ireland
Status: Offline
Reply With Quote
May 22, 2004, 08:05 AM
 
This method also works below:

Install RCdefaultApp from:

http://www.rubicode.com/Software/RCDefaultApp/

Visit this page and follow the visual instructions:

http://troubledmac.com/secureit.htm

Using the above technique, all the exploit examples of automatic downloading disk images etc that i have tried over the last 2 days have failed to execute and deploy any scripts automatically.

However, if you open any downloaded disk image from these exploit example, then sure, they may/will possibly run scripts using Help Viewer. But i understand this should be fixed by Apples latest security update.
-----------------------
Author of 'Fix a troubled Mac'
Macintosh troubleshooting PDF
http://fixa.troubledmac.com
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 08:12 AM
 
Originally posted by alcatholic:
BTW, am I wrong, or are we one mass email away from an outbreak? Isn't it enough to unwittingly click on a link in an email? Could an app be written to then propogate the email from owned machines? I don't know how email works on the Mac in the sense of unwittingly spreading viruses as in Windows.
You could write an application, launched by clicking a link in an email, that sent a similar email to every person Mail.app and/or the AddressBook knows about. And that may be a lot.

But most of these may be using another OS, or simply not click the link.

And I don't think you could really "own" the compromised machines, so who would want to do this ? (maybe you could install a user-level service, listening on some port, but it wouldn't be too hard to detect, I think - and the real "fun", spoofing IP-packets, needs root-access, AFAIK. WindowsXP is much more fun...)
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 08:24 AM
 
Originally posted by dirtymouse:
This method also works below:

Install RCdefaultApp from:

http://www.rubicode.com/Software/RCDefaultApp/

Visit this page and follow the visual instructions:

http://troubledmac.com/secureit.htm

Using the above technique, all the exploit examples of automatic downloading disk images etc that i have tried over the last 2 days have failed to execute and deploy any scripts automatically.

However, if you open any downloaded disk image from these exploit example, then sure, they may/will possibly run scripts using Help Viewer. But i understand this should be fixed by Apples latest security update.
As far as I can see you only fix help: disk: disks: and telnet: - what about afp: and ftp: ?

Have you tried my exploit example ? (where you can try ftp: )


Edit:

My list of URI schemas which are potentially usable to mount a remote directory / disk image:

Code:
afp: Finder, afp.URLMounter cifs: smb.URLMounter (NB: not from Safari) disk: DiskImageMounter disks: DiskImageMounter file: Finder, Safari, RealOne Player, Opera ftp: Finder, ftp.URLMounter, VLC, Opera ftps: ftp.URLMounter (NB: not from Safari) nfs: nfs.URLMounter (NB: not from Safari) smb: smb.URLMounter (NB: not from Safari) ssh: Terminal
And, of course, the following, which are protected by the "auto open safe files" setting:

Code:
http: Safari, Opera, http.URLMounter, VLC https: Safari, Opera
Edit 2: Hmm... It seems webdav: isn't exploitable...

Edit 3: Assorted editing. My current list of URI schemas able to mount a remote directory / disk image: disk, disks, afp, and ftp. (I think file and ssh are safe)
( Last edited by Hugin777; May 22, 2004 at 10:23 AM. )
     
sniffer
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status: Offline
Reply With Quote
May 22, 2004, 08:38 AM
 
Originally posted by theolein:
Pudge is a clown.
I agree. I saw his parade in the Slashdot discussion.

Sniffer gone old-school sig
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
May 22, 2004, 08:39 AM
 
Originally posted by theolein:
Pudge is a clown. he knew full well that the vulnerability was more serious but decided to ignore it, being the Apple fanboy that he is. At least, though, the lates Slashdot story mentions that Apple's SU doesn't fix anything apart from help:runscript
Well after having read the slashdot page(s) between you and pudge I am inclined to agree with you.

Another thing.... Some have worried or speculated that it was the slashdot story that got Apple moving on this hole. I disagree because if you just look at the stats:

Slashdot: Safari Falls Victim to Remote Code Exploit
Posted by pudge on Monday May 17, @01:36PM
.
.
( Read More... | 188 of 196 comments )

MacNN Serious Security Flaw in Mac OS X/Safari/Help Viewer ( 1 2 3 4 ... Last page )
Developer 351 Posts (13044 views)

(Not including related side topics.)

Now slashdot doesn't show the "views" for a given topic. But judging by the number of posts (hence discussion) on slashdot I would have to say that the major public news source of this problem has been via MacNN. There have also been articles CNet and numerous other places. Remember slashdot generates VERY little original content other than user comments, it just links to other sites. It would have been interesting to look at the httpd logs of the sites that slashdot linked to and map the hits vs time. Webalizer:
http://www.webalizer.org/ does it very nicely.
( Last edited by utidjian; May 22, 2004 at 08:56 AM. )
-DU-...etc...
     
fukami
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 22, 2004, 08:58 AM
 
Originally posted by Hugin777:
And I don't think you could really "own" the compromised machines, so who would want to do this ? (maybe you could install a user-level service, listening on some port, but it wouldn't be too hard to detect, I think - and the real "fun", spoofing IP-packets, needs root-access, AFAIK. WindowsXP is much more fun...)
Be sure, there are enough skidz out there who like to 0wn a mac.

Many Mac users I know are on user id 501, so it would hit them on a high level. Consider someone sends forged mails from Apple saying: "Here is the link to the important patch against the xyz vuln" ...

It isn't too hard to exploit that vulnerability to install a backshell on a higher port and a cronjob for a timed back connect (I tried that a couple of days ago while playing around with Server Side XSS -- be sure, it works). That's enough on low user level to make a lot of bad[tm] things

Many users are definitively not able to detect a backshell on their machine.
     
Eug Wanker
Posting Junkie
Join Date: Jun 2003
Location: Dangling something in the water… of the Arabian Sea
Status: Offline
Reply With Quote
May 22, 2004, 10:09 AM
 
I'm not sure if somebody posted this page yet, but it is another page which demonstrates the Help Viewer exploit. Do not go to this URL if you don't want Help Viewer to launch Terminal and do things to make you nervous:

http: // bronosky.com / pub / AppleScript.htm

You have to remove the spaces to make the link work. The page is harmless, but I don't want people to freak out after clicking on this link.

Installing the 5-24 Security Update prevents it from launching.
( Last edited by Eug Wanker; May 22, 2004 at 10:18 AM. )
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 22, 2004, 10:58 AM
 
Originally posted by Hugin777:
As far as I can see you only fix help: disk: disks: and telnet: - what about afp: and ftp: ?

Have you tried my exploit example ? (where you can try ftp: )


Edit:

My list of URI schemas which are potentially usable to mount a remote directory / disk image:

Code:
afp: Finder, afp.URLMounter cifs: smb.URLMounter (NB: not from Safari) disk: DiskImageMounter disks: DiskImageMounter file: Finder, Safari, RealOne Player, Opera ftp: Finder, ftp.URLMounter, VLC, Opera ftps: ftp.URLMounter (NB: not from Safari) nfs: nfs.URLMounter (NB: not from Safari) smb: smb.URLMounter (NB: not from Safari) ssh: Terminal
And, of course, the following, which are protected by the "auto open safe files" setting:

Code:
http: Safari, Opera, http.URLMounter, VLC https: Safari, Opera
Edit 2: Hmm... It seems webdav: isn't exploitable...

Edit 3: Assorted editing. My current list of URI schemas able to mount a remote directory / disk image: disk, disks, afp, and ftp. (I think file and ssh are safe)
You're right, to a point, I think. I wasn't thinking when I changed those protocol handlers. I was only thinking about the default protocols that can mount a volume, directly from the browser. Those would be disk:, ftp:, afp: and disks:.

Webdav:, smb:, nfs: ftps: etc are not reckognised by Safari (They aren't in the list of Protocol helpers). That doesn't mean they are not a problem of course, as they can definitely be used as an attack vector, but it would be difficult to see how a webpage can do this remotely.

The file: protocol always refers to a local volume, so I don't think that can be used to mount a remote volume that isn't already mounted (Catch 22)

The telnet:// protocol helper can be used as attack vector, in that a file can overwrite something already in your home directory, but I don't know what you could do with the ssh:// protocol (does start up the terminal from Safari) since you usually need authentification, i.e. host and user, to do anything useful.

All this, doesn't change the fact that a mounted device with an application forcing a new protocol is still a real problem. The only fix at the moment is the PA haxie.
weird wabbit
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 10:59 AM
 
Secunia has now issued a new advisory.

I recommend turning off auto-opening of "safe" files, and disabling afp: disk: disks: and ftp:...
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 11:10 AM
 
Originally posted by theolein:
Webdav:, smb:, nfs: ftps: etc are not reckognised by Safari (They aren't in the list of Protocol helpers).
[..]
All this, doesn't change the fact that a mounted device with an application forcing a new protocol is still a real problem. The only fix at the moment is the PA haxie.
I think the reason for cifs: smb: nfs: and ftps: not working is that the bundles (*.URLMounter) which has registered those URLHandlers aren't apps. So Safari can't do anything with them.

As to "the only fix", I now think you are safe disabling afp: ftp: disk: and disks: (and auto-open), as previously mentioned.
     
KrayZ
Fresh-Faced Recruit
Join Date: May 2004
Status: Offline
Reply With Quote
May 22, 2004, 12:03 PM
 
Originally posted by theolein:
Webdav:, smb:, nfs: ftps: etc are not reckognised by Safari (They aren't in the list of Protocol helpers). That doesn't mean they are not a problem of course, as they can definitely be used as an attack vector, but it would be difficult to see how a webpage can do this remotely.
Hmm. But disk: and disks: aren't in the list of Protocol Helpers, either, and yet Safari recognizes them. Do we need to test webdav:, smb:, nfs:, cifs:, etc. in order to be sure?
     
MindFad
Posting Junkie
Join Date: Sep 2001
Status: Offline
Reply With Quote
May 22, 2004, 12:16 PM
 
Well, I got paranoid enough to install Paranoid Android, as much as I dislike having APE installed.
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 12:52 PM
 
Originally posted by KrayZ:
Hmm. But disk: and disks: aren't in the list of Protocol Helpers, either, and yet Safari recognizes them. Do we need to test webdav:, smb:, nfs:, cifs:, etc. in order to be sure?
Right. And "malware:" isn't in the list of Protocol Helpers either - and yet Safari launches any Malware application which registers a "malware:" URLHelper ;-)

On my system webdav:, smb:, nfs:, cifs:, and ftps: just give an error in Safari. So I have sorta tested them (see my recently edited posts above)...
     
dirtymouse
Fresh-Faced Recruit
Join Date: May 2004
Location: Ireland
Status: Offline
Reply With Quote
May 22, 2004, 01:23 PM
 
[QUOTE]Originally posted by Hugin777:
[B]As far as I can see you only fix help: disk: disks: and telnet: - what about afp: and ftp: ?

Have you tried my exploit example ? (where you can try ftp: )

+

sure, if you want to prevent ftp and afp, go ahead and change them using the same software. I myself have changed them, but they are less likely to be used. afp and ftp using Apple's Finder (default handlers) over a medium speed DSL connection is nothing to write home about. Its very slow. In the time something happens, you'll be able to stop it.

Yes, i've tried your FTP link, i'm secure.


dirtymouse
-----------------------
Author of 'Fix a troubled Mac'
Macintosh troubleshooting PDF
http://fixa.troubledmac.com
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 22, 2004, 01:50 PM
 
Originally posted by Hugin777:
Right. And "malware:" isn't in the list of Protocol Helpers either - and yet Safari launches any Malware application which registers a "malware:" URLHelper ;-)

On my system webdav:, smb:, nfs:, cifs:, and ftps: just give an error in Safari. So I have sorta tested them (see my recently edited posts above)...
Read the thread, again. The malware:// or evil:// or yomama:// protocols only work AFTER the application has been registered through Apple LaunchServices. They have to be on a remote or local MOUNTABLE volume in order to be registered. That means through either the disk://, disks://, ftp:// or afp:// protocols .webdav:// would also be at risk if it worked from a all browsers, but it doesn't from Safari and which idiot is going to write an exploit which only affects Opera users, for example? cifs://, smb:// and nfs:// would also be dangerous if they worked from all browsers, but they don't. Go ahead try it out, they don't. They are however dangerous in a networked area such as in a university etc, but it is much less likey.

Remember, that with the exception of the telnet:// protocol (and that is debatable), it is a vulnerability that requires TWO things to happed for it to work: One is that a remote volume has to get mounted, and two is that a protocol helper, either existing or a new one from an application bundle's Info.plist which is on the just mounted volume, is then used to launch the application via the webpage in the browser.

This whole vulnerability is bad enough, without having to get too paranoid I think.
weird wabbit
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 02:06 PM
 
Originally posted by theolein:
Read the thread, again. The malware:// or evil:// or yomama:// protocols only work AFTER the application has been registered through Apple LaunchServices. They have to be on a remote or local MOUNTABLE volume in order to be registered. That means through either the disk://, disks://, ftp:// or afp:// protocols .webdav:// would also be at risk if it worked from a all browsers, but it doesn't from Safari and which idiot is going to write an exploit which only affects Opera users, for example? cifs://, smb:// and nfs:// would also be dangerous if they worked from all browsers, but they don't. Go ahead try it out, they don't. They are however dangerous in a networked area such as in a university etc, but it is much less likey.

Remember, that with the exception of the telnet:// protocol (and that is debatable), it is a vulnerability that requires TWO things to happed for it to work: One is that a remote volume has to get mounted, and two is that a protocol helper, either existing or a new one from an application bundle's Info.plist which is on the just mounted volume, is then used to launch the application via the webpage in the browser.

This whole vulnerability is bad enough, without having to get too paranoid I think.
I think you misunderstood my post. Or I wasn't clear enough.

What I was looking for was protocols that allowed mounting remote directories or remote disk images. FTP is one such example. But as any _local_ bundle that the Finder knows about can register itself as a URLHandler I had to look through all _locally_ installed bundles. I did, and found ftp:, afp:, and also smb: - but as smb: is only registered by a bundle which is _not_ an application Safari won't use that. But afp: and ftp: should be able to mount a remote directory. And in fact I have tried ftp: and it works perfectly.

So I wasn't saying that LaunchServices magically registered everything on the internet. Just everything in the default installation. And that includes disk:, disks:, afp:, and ftp:.

Also. A Malware writer wouldn't write an exploit only affecting Opera users. But if all other gates were closed, and Opera had a "way in" - of course it would be a smart move to try that too...

Note: the real issue does not lie at mounting remote directories / disk images (IMHO), but as the real issue only can be fixed by the Paranoid Android, the only other workaround I can see is to disable auto-open of safe files, and disk:, disks:, ftp:, and afp:.
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 22, 2004, 02:50 PM
 
Originally posted by Hugin777:
I think you misunderstood my post. Or I wasn't clear enough.

What I was looking for was protocols that allowed mounting remote directories or remote disk images. FTP is one such example. But as any _local_ bundle that the Finder knows about can register itself as a URLHandler I had to look through all _locally_ installed bundles. I did, and found ftp:, afp:, and also smb: - but as smb: is only registered by a bundle which is _not_ an application Safari won't use that. But afp: and ftp: should be able to mount a remote directory. And in fact I have tried ftp: and it works perfectly.

So I wasn't saying that LaunchServices magically registered everything on the internet. Just everything in the default installation. And that includes disk:, disks:, afp:, and ftp:.

Also. A Malware writer wouldn't write an exploit only affecting Opera users. But if all other gates were closed, and Opera had a "way in" - of course it would be a smart move to try that too...

Note: the real issue does not lie at mounting remote directories / disk images (IMHO), but as the real issue only can be fixed by the Paranoid Android, the only other workaround I can see is to disable auto-open of safe files, and disk:, disks:, ftp:, and afp:.
Mmmm, maybe I should learn Danish. Or why else would you basically repeat what I just said?
weird wabbit
     
MindFad
Posting Junkie
Join Date: Sep 2001
Status: Offline
Reply With Quote
May 22, 2004, 02:57 PM
 
Paranoid Android v1.1 is out, by the way.
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 03:18 PM
 
Originally posted by theolein:
Mmmm, maybe I should learn Danish. Or why else would you basically repeat what I just said?
LOL, ok. Here goes:


KrayZ writes:
Hmm. But disk: and disks: aren't in the list of Protocol Helpers, either, and yet Safari recognizes them. Do we need to test webdav:, smb:, nfs:, cifs:, etc. in order to be sure?
Then I write:
Right. And "malware:" isn't in the list of Protocol Helpers either - and yet Safari launches any Malware application which registers a "malware:" URLHelper ;-)
- What I meant was: That is correct. But the automatic registration of URLHelpers (which work for "malware:") will also work for any _local_ applications. That's why disk: and disks: are recognised by Safari, although not in the list of Protocol Helpers.


Then you write:
Read the thread, again.
And then you summarize the exploit.

Then I write a summary of my hunt for additional URI shemas capable of mounting remote diretories and/or disk images. Trying to explain that I know the thread pretty well and I think we misunderstood each other somehow =)

Just because I started posting late doesn't mean I didn't read it from the beginning. Actually Mail.app flagged the MacNN registration email as spam
     
MindFad
Posting Junkie
Join Date: Sep 2001
Status: Offline
Reply With Quote
May 22, 2004, 03:31 PM
 
I'm sure Apple will fix this ASAP, but I'm surprised something that seems quite simple even got by them. Such a simple little loophole, yet possibly very devastating to one's data. I'm thinking Apple should be all over this and have an update by Tuesday. Maybe I'm taking this a little too seriously?
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 03:34 PM
 
Originally posted by theolein:
ftp: -> chess, and staying there as it still works well in the finder or terminal.
Actually, you can keep the functionality of ftp: links (which would be somewhat of pain to lose) by rerouting ftp: to the FTP program of your choice (Fetch, Transmit, Interarchy, etc.) instead of Chess. As long as it doesn't point to the Finder, I think you should be safe.

With that said, why on earth is LaunchServices caching application info on FTP servers anyway? Wouldn't launching an app from an FTP server be unacceptably slow? Seems to me like you'd have to download the whole app first, unless I'm missing something...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 03:38 PM
 
Originally posted by MindFad:
I'm sure Apple will fix this ASAP, but I'm surprised something that seems quite simple even got by them. Such a simple little loophole, yet possibly very devastating to one's data. I'm thinking Apple should be all over this and have an update by Tuesday. Maybe I'm taking this a little too seriously?
Perhaps. I don't think this will be fixed for at least a week. And (as I argued above) I don't think the risk is all that great.

The vulnerability is very severe. And it's really easy to create an exploit. But I just don't think it will be done. - And _if_ someone does it, the news will spread fast and few Mac's will be compromised. But I may just think too highly of my fellow Mac users
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 03:41 PM
 
Originally posted by CharlesS:
With that said, why on earth is LaunchServices caching application info on FTP servers anyway? Wouldn't launching an app from an FTP server be unacceptably slow? Seems to me like you'd have to download the whole app first, unless I'm missing something...
I think it's as simple as Finder showing the FTP directory... And when Finder shows any directory it apparently updates LaunchServices. Does that make sense ?

But as to fixing this I agree; we don't need automatic URI schema registration from remote locations
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 04:10 PM
 
Originally posted by Hugin777:
I think it's as simple as Finder showing the FTP directory... And when Finder shows any directory it apparently updates LaunchServices. Does that make sense ?
Well, of course I understand that that's what's happening. My question is why it would be caching this in the first place. It seems like a bad idea. You wouldn't want to run apps stored on an FTP server, even if they were legitimate.

In other words, I think that LaunchServices should never have been caching this data for apps on remote servers.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hugin777
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status: Offline
Reply With Quote
May 22, 2004, 04:15 PM
 
Originally posted by CharlesS:
Well, of course I understand that that's what's happening. My question is why it would be caching this in the first place. It seems like a bad idea. You wouldn't want to run apps stored on an FTP server, even if they were legitimate.

In other words, I think that LaunchServices should never have been caching this data for apps on remote servers.
Sorry. What I (implicitly) meant was: maybe it's just a side effect. Maybe nobody really thought about this.

Maybe I should just shut up now
     
theolein
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status: Offline
Reply With Quote
May 22, 2004, 04:22 PM
 
Originally posted by CharlesS:
Actually, you can keep the functionality of ftp: links (which would be somewhat of pain to lose) by rerouting ftp: to the FTP program of your choice (Fetch, Transmit, Interarchy, etc.) instead of Chess. As long as it doesn't point to the Finder, I think you should be safe.

With that said, why on earth is LaunchServices caching application info on FTP servers anyway? Wouldn't launching an app from an FTP server be unacceptably slow? Seems to me like you'd have to download the whole app first, unless I'm missing something...
You're right, I didn't think about ftp links, which I seldom use, to be honest, but every now and again do. I've pointed ftp now to Mozilla, in case I need to browse an ftp directory.

I would also love to know why LS caches application info on ftp servers. I suppose it was done as an afterthought to make the Finder more capable, but still...
weird wabbit
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 04:41 PM
 
Originally posted by Hugin777:
Sorry. What I (implicitly) meant was: maybe it's just a side effect. Maybe nobody really thought about this.
That nobody thought about this is my guess.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Diggory Laycock
Professional Poster
Join Date: Oct 2001
Location: London
Status: Offline
Reply With Quote
May 22, 2004, 05:02 PM
 
I just tried looking at my apps directory on my other mac through FTP in the finder.

I wouldn't suggest it - it takes a while.

The finder must walk an app's bundle looking for the info.plist then open it - so it can display the correct icon, version info etc..

Once it does that it already has the URL schemes provided by the remote app - I think we can assume it passes that straight to LaunchServices.
( Last edited by Diggory Laycock; May 22, 2004 at 05:07 PM. )
     
VValdo
Dedicated MacNNer
Join Date: May 2001
Status: Offline
Reply With Quote
May 22, 2004, 05:11 PM
 
Just got here late to the thread...

The savings grace is that this relies on user action (ie, visiting a bad web page), but does anyone see a scenario where the mal-code would spread itself via social engineering -- ie, either automatically IMing users in an iChat buddy list or sending an email message to Address Book people directing OS X users to the page with the malignant code?

W
     
dan7352
Fresh-Faced Recruit
Join Date: May 2004
Location: Golden, CO
Status: Offline
Reply With Quote
May 22, 2004, 05:33 PM
 
Originally posted by MindFad:
Paranoid Android v1.1 is out, by the way.
I'd like to see PA augmented with an option to report suspicious URLs.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 05:39 PM
 
Warning! The release notes for Paranoid Android 1.1 state this:

Added more permitted URL schemes. The permitted schemes are 'http', 'https', 'ftp', 'mailto', 'itms', 'addressbook', 'rtsp', 'pnm', 'ical', 'webcal', 'sherlock', 'guikit', and 'file'.
Notice that 'ftp' is in the list. If PA is permitting FTP, then it is not protecting you against that particular exploit by default.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Developer  (op)
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status: Offline
Reply With Quote
May 22, 2004, 05:57 PM
 
Originally posted by CharlesS:
Notice that 'ftp' is in the list. If PA is permitting FTP, then it is not protecting you against that particular exploit by default.
As long as it blocks the phantasy protocols ftp and disk are fine I think.

Not sure what guikit is for and why it allows it though.
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.
     
smeger
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status: Offline
Reply With Quote
May 22, 2004, 06:21 PM
 
Originally posted by CharlesS:
Warning! The release notes for Paranoid Android 1.1 state this:


Notice that 'ftp' is in the list. If PA is permitting FTP, then it is not protecting you against that particular exploit by default.
You're absolutely correct, and PA shouldn't be whitelisting ftp. I'll be resolving this for the next release (if Apple doesn't fix this first). Fortunately, this wasn't too bad of a screwup since you're still protected from the malware getting launched.

Developer, 'guikit' is a scheme registered by ShapeShifter, of which I'm also the author. Since I knew for sure it wasn't exploitable, I threw it into the whitelist too.

I think I need to make the whitelist user configurable.
Geekspiff - generating spiffdiddlee software since before you began paying attention.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
May 22, 2004, 06:32 PM
 
Originally posted by smeger:
You're absolutely correct, and PA shouldn't be whitelisting ftp. I'll be resolving this for the next release (if Apple doesn't fix this first). Fortunately, this wasn't too bad of a screwup since you're still protected from the malware getting launched.
Well, I may be protected, but the majority of users who have ftp: set to the Finder by default will not be...

I think I need to make the whitelist user configurable.
I concur.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
 
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 08:56 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,