|
|
Serious Security Flaw in Mac OS X/Safari/Help Viewer (Page 8)
|
|
|
|
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Sep 2001
Status:
Offline
|
|
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?
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Sep 2001
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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 . . .
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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.
)
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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.
)
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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.
)
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Ireland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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...)
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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.
)
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Nov 2000
Location: Norway (I eat whales)
Status:
Offline
|
|
Originally posted by theolein:
Pudge is a clown.
I agree. I saw his parade in the Slashdot discussion.
|
Sniffer gone old-school sig
|
|
|
|
|
|
|
|
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Jun 2003
Location: Dangling something in the water… of the Arabian Sea
Status:
Offline
|
|
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.
)
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
Secunia has now issued a new advisory.
I recommend turning off auto-opening of "safe" files, and disabling afp: disk: disks: and ftp:...
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Status:
Offline
|
|
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?
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Sep 2001
Status:
Offline
|
|
Well, I got paranoid enough to install Paranoid Android, as much as I dislike having APE installed.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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)...
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Ireland
Status:
Offline
|
|
[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
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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:.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Sep 2001
Status:
Offline
|
|
Paranoid Android v1.1 is out, by the way.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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:
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
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Sep 2001
Status:
Offline
|
|
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?
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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...
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Denmark
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Feb 2001
Location: zurich, switzerland
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Oct 2001
Location: London
Status:
Offline
|
|
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.
)
|
|
|
|
|
|
|
|
|
Dedicated MacNNer
Join Date: May 2001
Status:
Offline
|
|
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
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2004
Location: Golden, CO
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Apr 2001
Location: europe
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Sep 2000
Location: Tempe, AZ
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|