Slashdot Mirror

← Back to Stories (view on slashdot.org)

Safari Security Hole Allows Cookie Theft

Posted by pudge on from the shut-it-down dept.

An anonymous reader writes "MacSlash posted a story about a vulnerability in Safari. The exploit allows someone to steal any of your domain-based cookies (passwords, private info, etc.) from any website. Mozilla and Internet Explorer had the same bug in the past."

11 of 70 comments (clear)

  1. Re:I wonder. by Ianoo · · Score: 4, Informative

    Potentially, but I doubt it. The two browsers share a rendering engine, not much else. Cookies are purely a protocol issue, they add extra data when doing a GET/POST request on a web page. Nothing whatsoever to do with HTML rendering.

    Potentially a bug could exist in the Javascript engine, and since Javascript can access cookies, and they could be stolen this way. However this particular bug doesn't appear to be JS-related, rather it's something more fundamental (but easily fixed by Apple, hopefully).

    Since Konqueror uses KDE/QT's socket classes, whilst Safari uses the Carbon/Darwin sockets interface, it's unlikely the bug would rear it's head in Konqueror IMHO.

  2. Re:One good reason... by Ianoo · · Score: 3, Informative

    I find them rather useful when you just have to get that first post on a Slashdot article but can't remember your password. See, if you'd had cookies enabled, you might well have made it in time!

    But seriously, I think cookies are a safe and generally useful concept. I have third-party cookies blocked since these can be downloaded with adverts and track you using the http-referer field. However, first party cookies are almost always safe.

    Not having to log in again at every single site just makes it easier, IMHO. I back up my cookie data more often than my bookmarks.

  3. Doesn't affect me? by Anonymous Coward · · Score: 4, Informative

    I am trying the "test" and all I get is:


    Please wait while loading the script

    You are stuck on this page ?
    It means that your browser is not vulnerable, sorry, or maybe, not so
    sorry, it's how the things should be !!!.
    You can press the back button now :)

    I am running Safari 1.1.1 (v100.1). Could it be because
    of This Hint?

  4. Re:Fix it, but... what's the fuss? by Taran · · Score: 5, Informative

    If the web app allows you to edit your information once you've aquired an authorized session, then stealing that authorized session could allow someone to hijack your information and/or your identity with that web app/company.

  5. Re:That's not the biggest Safari bug by Anonymous Coward · · Score: 4, Informative

    This isn't a Safari bug, this is how your OS deals with virtual memory.

    Look in /var/vm

    And you will see... swapfile1, swapfile2... etc. The OS creates these as needed.

    Now for the OS to recover swap space, there has no be no pages addressed to a swap file. When you run Safari what gets paged out to disk? Not safari, but all the other applications you are running. Therefore, quitting Safari does nothing. The OS won't page in the swap unless you need access to that page of memory.

  6. Re:That's not the biggest Safari bug by Hes+Nikke · · Score: 2, Informative

    hmmm...
    Safari -> Empty Cache

    or you could push cmd-option-E

    i think your gripe is more that you can't control the size of your cache, but some creative partitioning with a side of fstab could fix that :)

    my gripe is that safari doesn't seem to take advantage of the cache to the same extent that IE and Moz do, slowing down loading of mostly static pages and images

    but i still prefer it to any other browser out there :)

    --
    Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
  7. PATCHED ALREADY! by goombah99 · · Score: 1, Informative
    move along. no story here. Uh hate to burst everyones' bubble but this is patched if you are using safari version 1.1.1

    as long as I'm reposting things from MacSlash here's one: see for your self by testing the exploit here.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:PATCHED ALREADY! by bill_mcgonigle · · Score: 2, Informative

      as long as I'm reposting things from MacSlash

      Hey, at least repost the right stuff. :)

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  8. temporary patch by Anonymous Coward · · Score: 1, Informative

    http://www.securityfocus.com/archive/1/345221

  9. OmniWeb and KHTML by Lagos · · Score: 3, Informative

    First of all note that OmniWeb is not affected by this bug. Outside of a lack of tabs, it's a very good Web Browser that should satisfy you until Apple patches this bug. Of course, I'm sure the Slashdot readership is aware of other options as well.

    As for the discussion as to whether this is a bug in KHTML in general, it is not. The bug is in the way browsers parse the hostname out of a URL differently for cookies and the connection itself. So in Safari the url:

    http://www.EvilSite.com%00.amazon.com/

    will connect to www.EvilSite.com, but be considered in the domain of .amazon.com for the purpose of cookie security. This seems to be a bug in the code around KHTML, not KHTML itself, since vulnerable OmniWeb uses the same WebCore framework that is used by Safari without being vulnerable.

  10. Here is the fix for this exploit: by Giffut · · Score: 3, Informative

    http://hetima.com/soft/cookiemonsterfix.html Scroll down for the english explanations. But you also can proceed to download the DMG file itself, as substancial english documentation is included there. G