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.
previous month may 2004 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today