disk:// and help:// security problems
-
Safari, when accessing disk:// and help:// URLs, presents an enormous
potential security risk -- automated execution of arbitrary code from an
external source.
I suggest:
1) Apple's Safari developers remove this kind of conveninent (?) but
boneheaded feature
2) Use FireFox, Mozilla, Opera, etc. until (1) is accomplished
There's something to be said for browsers that don't tie themselves too
intimately to the host OS.
-----
F-D post:
http://lists.netsys.com/pipermail/full-disclosure/2004-May/021582.html
Forum discussion:
http://forums.macnn.com/showthread.php?s=&threadid=213043&perpage=5
0&pagenumber=1
-----
(excerpts from forums discussions below).
Disk images are mountable via the disk: protocol and automatic forwarding
to disk: and help: can be done with meta refresh tags.
With an URL of the type help:runscript=... HelpViewer can then be used to
execute any script. This can be done with a refresh meta tag to such an
URL. The script can then execute arbitrary code.
Summary:
Deleting or modifying the OpnApp.scpt doesn't protect from this
vulnerability
Deleting the MacHelp.help doesn't protect from this vulnerability
Deleting the help protocol with MisFox doesn't protect from this
vulnerability
Changing the help protocol to something else than Help Viewer (I use
Chess) seems to help
I suggest you download MisFox and change the application for the help
protocol from Help Viewer to something else.
Get MisFox here:
http://www.clauss-net.de/misfox/misfox.html
and click the Protocol Helpers tab.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am 17.05.2004 um 21:50 schrieb Michael Rothwell:
> Safari, when accessing disk:// and help:// URLs, presents an enormous
> potential security risk -- automated execution of arbitrary code from
> an
> external source.
>
> I suggest:
>
> 1) Apple's Safari developers remove this kind of conveninent (?) but
> boneheaded feature
>
> 2) Use FireFox, Mozilla, Opera, etc. until (1) is accomplished
>
> There's something to be said for browsers that don't tie themselves too
> intimately to the host OS.
>
> -----
>
> F-D post:
> http://lists.netsys.com/pipermail/full-disclosure/2004-May/021582.html
>
> Forum discussion:
> http://forums.macnn.com/showthread.php?
> s=&threadid=213043&perpage=50&pagenumber=1
>
> -----
>
> (excerpts from forums discussions below).
>
> Disk images are mountable via the disk: protocol and automatic
> forwarding
> to disk: and help: can be done with meta refresh tags.
>
> With an URL of the type help:runscript=... HelpViewer can then be used
> to
> execute any script. This can be done with a refresh meta tag to such an
> URL. The script can then execute arbitrary code.
>
>
> Summary:
>
> Deleting or modifying the OpnApp.scpt doesn't protect from this
> vulnerability
> Deleting the MacHelp.help doesn't protect from this vulnerability
> Deleting the help protocol with MisFox doesn't protect from this
> vulnerability
> Changing the help protocol to something else than Help Viewer (I use
> Chess) seems to help
>
> I suggest you download MisFox and change the application for the help
> protocol from Help Viewer to something else.
>
> Get MisFox here:
>
> http://www.clauss-net.de/misfox/misfox.html
>
> and click the Protocol Helpers tab.
As a programmer I would say it's not a bug it's a feature.
If you don't like it, just turn it off ("Open 'safe' files after
download").
And pay attention to rule 1: Never download from a source you can't
trust.
Peter
> ______________________________________________________________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Upon further reflection, I think that #2 below won't bypass the whole
problem, as any browser that respects system settings for protocol
handlers can be (mis)used in this manner. It's really a problem with
help:// and disk:// rather than, specifically, safari.
Michael Rothwell
<Michael...>
On May 17, 2004, at 3:50 PM, Michael Rothwell wrote:
Safari, when accessing disk:// and help:// URLs, presents an enormous
potential security risk -- automated execution of arbitrary code from an
external source.
I suggest:
1) Apple's Safari developers remove this kind of conveninent (?) but
boneheaded feature
2) Use FireFox, Mozilla, Opera, etc. until (1) is accomplished
There's something to be said for browsers that don't tie themselves too
intimately to the host OS.
-----
F-D post:
http://lists.netsys.com/pipermail/full-disclosure/2004-May/021582.html
Forum discussion:
http://forums.macnn.com/showthread.php?
s=&threadid=213043&perpage=50&pagenumber=1
-----
(excerpts from forums discussions below).
Disk images are mountable via the disk: protocol and automatic
forwarding
to disk: and help: can be done with meta refresh tags.
With an URL of the type help:runscript=... HelpViewer can then be used
to
execute any script. This can be done with a refresh meta tag to such an
URL. The script can then execute arbitrary code.
Summary:
Deleting or modifying the OpnApp.scpt doesn't protect from this
vulnerability
Deleting the MacHelp.help doesn't protect from this vulnerability
Deleting the help protocol with MisFox doesn't protect from this
vulnerability
Changing the help protocol to something else than Help Viewer (I use
Chess) seems to help
I suggest you download MisFox and change the application for the help
protocol from Help Viewer to something else.
Get MisFox here:
http://www.clauss-net.de/misfox/misfox.html
and click the Protocol Helpers tab.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 17, 2004, at 6:23 PM, Peter Wollschlaeger wrote:
>> http://forums.macnn.com/showthread.php?
>> s=&threadid=213043&perpage=50&pagenumber=1
>>
>> Deleting or modifying the OpnApp.scpt doesn't protect from this
>> vulnerability
>> Deleting the MacHelp.help doesn't protect from this vulnerability
>> Deleting the help protocol with MisFox doesn't protect from this
>> vulnerability
>> Changing the help protocol to something else than Help Viewer (I use
>> Chess) seems to help
> As a programmer I would say it's not a bug it's a feature.
> If you don't like it, just turn it off ("Open 'safe' files after
> download").
> And pay attention to rule 1: Never download from a source you can't
> trust.
With apologies to all for the cross-post...
Turning off that option is NOT sufficient to prevent the exploit. Read
through the discussion thread; this is a serious issue with OS X. The
help:runscript feature is absolutely a feature, and is probably
intended as a replacement for Apple Guide automation; however, it
should have been implemented in Help Viewer, not WebCore/WebKit.
-- Gwynne, key to the Code that runs us all
Formerly known as Sailor Quasar.
Email: <squasar...>
Web: http://musicimage.plasticchicken.com/
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I'll go further and say that it's not a problem with disk:// either,
which is actually a handy feature. The problem is with help:. No matter
what, it is *never* a good idea to have it possible to execute
arbitrary scripts via a URL. I really can't imagine what the engineers
were thinking when they implemented this.
Charles
On May 17, 2004, at 5:58 PM, Michael Rothwell wrote:
> Upon further reflection, I think that #2 below won't bypass the whole_______________________________________________
> problem, as any browser that respects system settings for protocol
> handlers can be (mis)used in this manner. It's really a problem with
> help:// and disk:// rather than, specifically, safari.
>
> Michael Rothwell
> <Michael...>
>
>
>
> On May 17, 2004, at 3:50 PM, Michael Rothwell wrote:
>
> Safari, when accessing disk:// and help:// URLs, presents an enormous
> potential security risk -- automated execution of arbitrary code from
> an
> external source.
>
> I suggest:
>
> 1) Apple's Safari developers remove this kind of conveninent (?) but
> boneheaded feature
>
> 2) Use FireFox, Mozilla, Opera, etc. until (1) is accomplished
>
> There's something to be said for browsers that don't tie themselves too
> intimately to the host OS.
>
> -----
>
> F-D post:
> http://lists.netsys.com/pipermail/full-disclosure/2004-May/021582.html
>
> Forum discussion:
> http://forums.macnn.com/showthread.php?
> s=&threadid=213043&perpage=50&pagenumber=1
>
> -----
>
> (excerpts from forums discussions below).
>
> Disk images are mountable via the disk: protocol and automatic
> forwarding
> to disk: and help: can be done with meta refresh tags.
>
> With an URL of the type help:runscript=... HelpViewer can then be used
> to
> execute any script. This can be done with a refresh meta tag to such an
> URL. The script can then execute arbitrary code.
>
>
> Summary:
>
> Deleting or modifying the OpnApp.scpt doesn't protect from this
> vulnerability
> Deleting the MacHelp.help doesn't protect from this vulnerability
> Deleting the help protocol with MisFox doesn't protect from this
> vulnerability
> Changing the help protocol to something else than Help Viewer (I use
> Chess) seems to help
>
> I suggest you download MisFox and change the application for the help
> protocol from Help Viewer to something else.
>
> Get MisFox here:
>
> http://www.clauss-net.de/misfox/misfox.html
>
> and click the Protocol Helpers tab.
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18. May 2004, at 0:23, Peter Wollschlaeger wrote:
>> 1) Apple's Safari developers remove this kind of conveninent (?) but
>> boneheaded feature
I think the problem is with the Help Viewer. Custom handlers for URL
schemes are useful in many different contexts. But the scheme handler
should never allow the URL to specify code to be executed (which the
help viewer does).
> As a programmer I would say it's not a bug it's a feature.
> If you don't like it, just turn it off ("Open 'safe' files after
> download").
> And pay attention to rule 1: Never download from a source you can't
> trust.
Did you read the exploit? I can post an innocently looking http link to
this forum, and by clicking it (w/o taking further actions) you allow
me to execute custom code on your machine.
I click dozen of links every day from sources which are impossible for
me to verify in advance, and I am not sure that this "feature" can be
easily disabled, cause it is not about opening files I download, it is
about having the browser follow a link using Launch Services, which I
do not think can be disabled, and if it could, it would also break
ftp:, mailto:, or other stuff not handled by Safari itself.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 17, 2004, at 21:53, Allan Odgaard wrote:
>> As a programmer I would say it's not a bug it's a feature.
>> If you don't like it, just turn it off ("Open 'safe' files after
>> download").
>> And pay attention to rule 1: Never download from a source you can't
>> trust.
>
> Did you read the exploit? I can post an innocently looking http link
> to this forum, and by clicking it (w/o taking further actions) you
> allow me to execute custom code on your machine.
>
Actually that's slightly incorrect I believe. You need two URL's one to
download a malicious AppleScript and then the help:// URL to cause it
to execute.
Also the user must have auto-open 'safe' downloads turned on _and_ have
his/her download location known to the attacker (probably ~/Desktop).
Technically you can get rid of the first URL if there are already
inadvertently malicious AppleScripts installed as part of a basic Mac
OS X installation. But I'd be surprised if any default Mac OS X
apple-scripts would be anything other than annoying/inconvenient.
Jon.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am 18.05.2004 um 03:53 schrieb Allan Odgaard:
> and I am not sure that this "feature" can be easily disabled, cause it
> is not about opening files I download, it is about having the browser
> follow a link using Launch Services, which I do not think can be
> disabled, and if it could, it would also break ftp:, mailto:, or other
> stuff
Get More Internet (http://www.monkeyfood.com/software/moreInternet/) or
MisFox (http://www.clauss-net.de/misfox/misfox.html) and set the "help"
helper application to something other than Help Viewer.
This does not break other protocols and avoids Help Viewers misfeature.
Andreas
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18. May 2004, at 5:58, Jonathan Wight wrote:
> Actually that's slightly incorrect I believe. You need two URL's one
> to download a malicious AppleScript and then the help:// URL to cause
> it to execute.
This is why the disk:-URL was also mentioned in the exploit.
> Also the user must have auto-open 'safe' downloads turned on _and_
> have his/her download location known to the attacker (probably
> ~/Desktop).
Let index.html have two frames, the first with a disk:-URL to a
disk-image and let the second use meta-refresh with a small delay and
the new target
help:runscript=/Volumes/DiskImageWeJustMounted/Dangerous.scpt -- it's
that simple!
I didn't test it, other than verify that entering a help:-URL with a
runscript does execute the script, and likewise does a disk:-URL mount
the disk image. There might be some security measures in Safari, like
only adhering to Launch Services when the URL was clicked or entered
manually, which would make it a less likely exploit, but I doubt it, as
that would probably break a lot of stuff, like redirects to ftp-sites
etc. -- the fix should be to *not* allow help:-URLs (from the outside
world) to execute arbitrary scripts.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 17, 2004, at 8:53 PM, Allan Odgaard wrote:
> On 18. May 2004, at 0:23, Peter Wollschlaeger wrote:
>
>>> 1) Apple's Safari developers remove this kind of conveninent (?) but
>>> boneheaded feature
>
> I think the problem is with the Help Viewer. Custom handlers for URL
> schemes are useful in many different contexts. But the scheme handler
> should never allow the URL to specify code to be executed (which the
> help viewer does).
>
>> As a programmer I would say it's not a bug it's a feature.
>> If you don't like it, just turn it off ("Open 'safe' files after
>> download").
>> And pay attention to rule 1: Never download from a source you can't
>> trust.
>
> Did you read the exploit? I can post an innocently looking http link
> to this forum, and by clicking it (w/o taking further actions) you
> allow me to execute custom code on your machine.
>
> I click dozen of links every day from sources which are impossible for
> me to verify in advance, and I am not sure that this "feature" can be
> easily disabled, cause it is not about opening files I download, it is
> about having the browser follow a link using Launch Services, which I
> do not think can be disabled, and if it could, it would also break
> ftp:, mailto:, or other stuff not handled by Safari itself.
You can disable it by downloading More Internet from
http://www.monkeyfood.com and using it to change the helper app for
"help:" from Help Viewer to something else.
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 17, 2004, at 10:58 PM, Jonathan Wight wrote:
> Actually that's slightly incorrect I believe. You need two URL's one to
> download a malicious AppleScript and then the help:// URL to cause it
> to execute.
Wrong. With JavaScript you can automatically execute these after a
delay. All you'd have to do is visit the page.
> Also the user must have auto-open 'safe' downloads turned on _and_ have
> his/her download location known to the attacker (probably ~/Desktop).
Wrong again. The disk:// URL's do not require auto-opening 'safe'
downloads to be on, and the download location is completely irrelevant
since the image will be mounted to /Volumes.
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 18, 2004, at 1:00 AM, Allan Odgaard wrote:
>> Also the user must have auto-open 'safe' downloads turned on _and_
>> have his/her download location known to the attacker (probably
>> ~/Desktop).
>
> Let index.html have two frames, the first with a disk:-URL to a
> disk-image and let the second use meta-refresh with a small delay and
> the new target
> help:runscript=/Volumes/DiskImageWeJustMounted/Dangerous.scpt -- it's
> that simple!
But, as Jonathan pointed out, it fails if 'Open "safe" files after
downloading" is off. Now _I_ don't understand why that option is on by
default. I found it extremely annoying that I noticed it happening. And
I turned it off. It's that simple.
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18.5.2004, at 3:53, Allan Odgaard wrote:
> ...I am not sure that this "feature" can be easily disabled...
Perhaps I've misunderstood something, but I believe it is fully
sufficient to remove the Help Viewer $#%#$%$^# as a help: scheme
handler (e.g., as the original discussion proposes, replacing it by
Chess ;)).
---
Ondra Hada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18 May 2004, at 12:11, Gregory Weston wrote:
...
> But, as Jonathan pointed out, it fails if 'Open "safe" files after
> downloading" is off.
No, this is simply not true. Automatic opening .dmg files fetched
using the HTTP protocol is stopped when you switch off the 'Open "safe"
files...' option but the auto-mounting of disk:... URLs is not. These
disk:... URLs are handled by the finder and don't show up in the Safari
downloads window. The disk image is put in a temporary location and
removed once ejected.
Nicko
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
>> ...I am not sure that this "feature" can be easily disabled...
>
> Perhaps I've misunderstood something, but I believe it is fully
> sufficient to remove the Help Viewer $#%#$%$^# as a help: scheme
> handler (e.g., as the original discussion proposes, replacing it by
> Chess ;)).
This is the working work-around. You can replace the help: handler with
anything you want. Chess is amusing, textedit will show you the text of
the attempted exploit script, etc. The important thing is to replace the
handler, not delete it or the help app.
It's just a work-around, though. I would like to see Apple step forward
with a real fix. Or at least an acknowledgement and statement of the
work-around. Something public.
--
Michael Rothwell
<michael...>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Hi Charles,
During the Y2K scare, many US Banks were required to show that a third
party had performed a Y2K date and security test on any publicly
available machines. One of my clients was doing these tests for banks
in Oklahoma. It was pretty funny, actually, because if a bank had a
certain version IIS installed without the latest security patches,
they'd automatically fail the test, because there was an app on it that
could execute any script on the server, regardless of the file's
location (like in an open dropbox).
This was considered the absolute worst security problem ever created,
and I'm as amazed as everyone else that Apple decided to put this into
MacOSX.
Here's a thought--Apple could remove Help altogether. The Help
application seems to be a hybrid of Apple's previous 'Guide' technology
and a web browser/search engine, failing to achieve any of these goals.
Instead of Help, Apple could add an option to the Finder's 'Search'
screen, for searching Help & Documentation. The Help key (command+?)
could then launch the 'Find' box with the Help & Docs option selected.
The Help menu could have links into the documents directly (using #s).
What about launching AppleScripts from Help? The reason this worked at
all under the Guide metaphor was that the guide could draw on the
screen, point at things, pull down menus, and stay the hell out of the
way while the actions were executing, but be visible enough that the
user could read about what they're seeing. With the current Help
design, the Help window obscures everything, and the user either finds
themselves with suddenly opened windows (but unable to read why this
happened) or the Help app stays in the foreground while the script does
something in the background. Neither of these is actually helpful. So
my vote would be for Apple to abandon the idea of running scripts and
launching apps from within the Help documentation, and focus instead on
writing better help documentation.
-Chilton
On May 17, 2004, at 8:26 PM, Charles Srstka wrote:
> I'll go further and say that it's not a problem with disk:// either,_______________________________________________
> which is actually a handy feature. The problem is with help:. No
> matter what, it is *never* a good idea to have it possible to execute
> arbitrary scripts via a URL. I really can't imagine what the engineers
> were thinking when they implemented this.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 18, 2004, at 9:34 AM, Chilton Webb wrote:
> This was considered the absolute worst security problem ever created,
> and I'm as amazed as everyone else that Apple decided to put this into
> MacOSX.
I agree, it is completely ridiculous that this showed up, especially
after Microsoft did the same thing. Apple should have been aware of
this!
Color me amazed, disappointed, frustrated, confused...
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 18, 2004, at 9:34 AM, Chilton Webb wrote:
> This was considered the absolute worst security problem ever created,
> and I'm as amazed as everyone else that Apple decided to put this into
> MacOSX.
I am amazed, shocked, disappointed, and crestfallen.
In case anyone still thinks that this only affects you if you have
"safe" files turned on, check this out. It doesn't even involve a DMG.
This hole has *many* evil uses.
http://bronosky.com/pub/AppleScript.htm
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Yes, I noticed this this morning and have advised everyone I know to
use either the IE preferences or MisFox to change the Help helper to
preview or Textedit (preview for those who don't want to see the script
command passed). There are very few limitations in what even a script
string passed in the url is capable of doing and, as pointed out, as
this doesn't require a dmg or anything to be downloaded, turning off
'open safe files' has no effect. After all, the applescript could
easily use curl to download anything it wants and run it from a known
location...
It is interesting to note that, according to talk on /. the problem is
only in 10.3 - 10.2 seems to be 'immune' so this was caused by a recent
braindread action on the part of an Apple developer rather than an old
one you could blame on 'didn't know better' ... Of course, Apple
removing the 'Helpers' preference pane in 10.3 didn't really help
either, nor does the use of CM coding for the preference file holding
all the settings :(
It is also very reminiscent to the Windows Help bug that was capable of
formatting your hard drive :(
The most common form of attack on platforms with few email client bugs
is via common protocols such as ssh, ftp, http/url coding etc. and
anyone working with this type of tcp connection must really think hard
of the knock-on consequences!
Robert
---
GnuPG public key:
http://www.Far-Blue.co.uk/
[demime 0.98b removed an attachment of type application/pgp-signature which had a name of PGP.sig]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 18, 2004, at 12:01 PM, Robert Goldsmith wrote:
> Yes, I noticed this this morning and have advised everyone I know to
> use either the IE preferences or MisFox to change the Help helper to
> preview or Textedit (preview for those who don't want to see the script
> command passed).
FWIW, here's how I resolved this problem without changing any IC
settings:
sudo chmod a-x "/System/Library/CoreServices/Help
Viewer.app/Contents/MacOS/Help Viewer"
If Help Viewer isn't executable, then it can't be launched, and if it
can't be launched, then this security hole is closed. This can be
useful in multi-user situations where everyone has different IC
settings, although it also means that the online help feature present
in some applications will stop working.
But this thread is off-topic, so shall I suggest we take this to the
macosx-talk[1] mailing list?
Nick Zitzmann
<http://www.chronosnet.com/>
[1] <http://www.omnigroup.com/developer/mailinglists/>
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
So the obvious solution is for Apple to modify WebKit to prevent
passing of URIs with certain schemes to LaunchServices if the source of
the URI isn't the local machine.
The trouble with that method is that we only know about two URI schemes
that currently are dangerous. Wouldn't it be better to encode this
information in the URI scheme itself so that any future URI schemes can
be defined to be local only? One way would be replace the 'help' URI
scheme with 'x-local-help'. WebKit (or any other code that can
potentially open a URI from the outside world) would check the URI
scheme name and refuse to load 'x-local-*' URIs that aren't from the
local machine?
Jon.
On May 18, 2004, at 14:01, Robert Goldsmith wrote:
>> http://bronosky.com/pub/AppleScript.htm
>
> Yes, I noticed this this morning and have advised everyone I know to
> use either the IE preferences or MisFox to change the Help helper to
> preview or Textedit (preview for those who don't want to see the script
> command passed). There are very few limitations in what even a script
> string passed in the url is capable of doing and, as pointed out, as
> this doesn't require a dmg or anything to be downloaded, turning off
> 'open safe files' has no effect. After all, the applescript could
> easily use curl to download anything it wants and run it from a known
> location...
>
> It is interesting to note that, according to talk on /. the problem is
> only in 10.3 - 10.2 seems to be 'immune' so this was caused by a recent
> braindread action on the part of an Apple developer rather than an old
> one you could blame on 'didn't know better' ... Of course, Apple
> removing the 'Helpers' preference pane in 10.3 didn't really help
> either, nor does the use of CM coding for the preference file holding
> all the settings :(
>
> It is also very reminiscent to the Windows Help bug that was capable of
> formatting your hard drive :(
>
> The most common form of attack on platforms with few email client bugs
> is via common protocols such as ssh, ftp, http/url coding etc. and
> anyone working with this type of tcp connection must really think hard
> of the knock-on consequences!
>
> Robert
> ---
> GnuPG public key:
> http://www.Far-Blue.co.uk/
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
This can probably still be defeated. Just have the disk image
mount and then, instead of having the help:// URL load, load an http:// or
file:// URL off the disk image - and *that* has the help:// URL.
Sounds a little convoluted, but all of this can still be automated
and happen fairly quickly.
Really, the help viewer (and any other app that looks at
unverified data) should be running either sandboxed code or no code at
all.
Eric
On Tue, 18 May 2004, Jonathan Wight wrote:
> So the obvious solution is for Apple to modify WebKit to prevent_______________________________________________
> passing of URIs with certain schemes to LaunchServices if the source of
> the URI isn't the local machine.
>
> The trouble with that method is that we only know about two URI schemes
> that currently are dangerous. Wouldn't it be better to encode this
> information in the URI scheme itself so that any future URI schemes can
> be defined to be local only? One way would be replace the 'help' URI
> scheme with 'x-local-help'. WebKit (or any other code that can
> potentially open a URI from the outside world) would check the URI
> scheme name and refuse to load 'x-local-*' URIs that aren't from the
> local machine?
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 18, 2004, at 1:01 PM, Robert Goldsmith wrote:
> It is interesting to note that, according to talk on /. the problem is
> only in 10.3 - 10.2 seems to be 'immune' so this was caused by a recent
> braindread action on the part of an Apple developer rather than an old
> one you could blame on 'didn't know better' ... Of course, Apple
> removing the 'Helpers' preference pane in 10.3 didn't really help
> either, nor does the use of CM coding for the preference file holding
> all the settings :(
Actually, I asked someone I know who is still running 10.2.8 to try
this, and according to what he told me, the vulnerability seemed to
affect his machine. So apparently it does affect 10.2.8 as well.
(BTW, sorry for the previous duplicate message. I thought the first one
didn't get sent. Whoops...)
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On 18 May 2004, at 18:31, Charles Srstka wrote:
> On May 18, 2004, at 9:34 AM, Chilton Webb wrote:
>
>> This was considered the absolute worst security problem ever created,
>> and I'm as amazed as everyone else that Apple decided to put this
>> into MacOSX.
>
> I am amazed, shocked, disappointed, and crestfallen.
>
> In case anyone still thinks that this only affects you if you have
> "safe" files turned on, check this out. It doesn't even involve a DMG.
>
> This hole has *many* evil uses.
>
> http://bronosky.com/pub/AppleScript.htm
>
Well, the above is not all...
The URI schemes mixed with LaunchServices is *extremely* dangerous. See:
<http://daringfireball.net/2004/05/unsafe_uri_handlers>
and especially
<http://www.unsanity.com/haxies/pa/whitepaper>
Regards,
izidor
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On May 23, 2004, at 7:45 AM, Izidor Jerebic wrote:
> Well, the above is not all...
> The URI schemes mixed with LaunchServices is *extremely* dangerous.
> See:
>
> <http://daringfireball.net/2004/05/unsafe_uri_handlers>
>
> and especially
>
> <http://www.unsanity.com/haxies/pa/whitepaper>
Not only that, it's also possible to create an app with a creator code
of 'GFTM' and set it up to recognize the tn3270: protocol. Since the
default settings already specify an app with creator code 'GFTM' as the
helper app for tn3270:, this exploit could conceivably still work even
if Apple fixed the problem of LaunchServices automatically registering
protocols for helper apps.
Charles
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
