Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Security Apple

Safari Security Hole Allows Cookie Theft 70

Posted by pudge 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."
This discussion has been archived. No new comments can be posted.

Safari Security Hole Allows Cookie Theft More

Safari Security Hole Allows Cookie Theft

Comments Filter:

  • One good reason... (Score:3, Funny)

    by BrokenHalo ( 565198 ) on Friday November 21, 2003 @01:04PM (#7529349)
    to make a symlink from your cookies file to /dev/null. Who needs persistent cookies anyway?

    • Re:One good reason... (Score:4, Informative)

      by Ianoo ( 711633 ) on Friday November 21, 2003 @01:22PM (#7529534) Journal
      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.

  • I wonder. (Score:2, Interesting)

    by dtfinch ( 661405 ) *
    Might the Konqueror browser be affected by this?

    • Re:I wonder. (Score:5, Informative)

      by Ianoo ( 711633 ) on Friday November 21, 2003 @01:17PM (#7529484) Journal
      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.

  • Should watch similar products (Score:4, Insightful)

    by shaka999 ( 335100 ) on Friday November 21, 2003 @01:08PM (#7529395)
    Just goes to show that companies should closely monitor security holes in competing products.

  • Cookie Theft (Score:5, Funny)

    by dpdawson ( 624716 ) on Friday November 21, 2003 @01:12PM (#7529437) Homepage
    Marc Slemko: Apple stole the cookie from the cookie jar.

    Apple: Who me?

    Marc Slemko: Yes, you.

    Apple: Couldn't be.

    Marc Slemko: Then who?

    • Re:Cookie Theft (Score:3, Funny)

      by Anonymous Coward
      Apple: Bill Gates stole the cookie from the cookie jar.

      Slashdot: BURN HIM!

      MacSlash: BURN HIM!

      AppleLust: BURN HIM!

      Think Secret: BURN HIM!

      Steve Jobs: Tee hee. What a bunch of sheep.

    • Re:Cookie Theft (Score:2, Offtopic)

      by TClevenger ( 252206 )
      Bastard! That song'll be in my head for a week!

  • Safari and Konqueror (Score:2, Redundant)

    by CliffH ( 64518 )
    Just a quick question to throw out there.

    I know Safari uses KHTML as its rendering engine (ala Konqueror). How much more of the Konqueror code is used in Safari and could Konq possibly face this same issue and no one has stumbled on it? Forgive me if it's a stupid question, I've had about 2 hours sleep, my car broke down after taking my wife to work at 4am, and now I have to wait up because it's too late to get back to sleep before picking her up and waking up my son. Sounds like a lousy country song, huh.
    • This is a repeat of the earlier parent on the same issue. See my comment here [slashdot.org]. Basically I'm pretty sure the answer is no.
      • Sorry about that. :) As it was early early in the AM over her (NZ), I was typing kinda slow and started posting that when there were three posts up. I'm pretty sure you're right too. I think we would have heard about it by now if it were the case, but, to be on the safe side, we should all check out our Konqueror installations against any sites that test for it (I'd advise caution if you have any cookies saved with sensitive passwords for sensitive sites though). Now, I think I'm going to try and get some s

  • Doesn't affect me? (Score:4, Informative)

    by Anonymous Coward on Friday November 21, 2003 @01:45PM (#7529731)
    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 [macosxhints.com]?
    • I doubt that hint is the answer you think it is. they are talking about stealing your existing cookies. in the case of the test site i would imagine they are writing and then stealing back a test cookie. since this takesplace all in one session the lock should be irrelevant.
    • It doesn't affect me either (Safari 1.0 v85). I'm assuming this is because I have Privoxy [privoxy.org] running.

  • Fix it, but... what's the fuss? (Score:5, Insightful)

    by jtheory ( 626492 ) on Friday November 21, 2003 @01:51PM (#7529805) Homepage Journal
    The exploit allows someone to steal any of your domain-based cookies (passwords, private info, etc.) from any website.

    Any security hole should be fixed, but this is not as serious as they make it sound.

    Passwords? Private info? What serious web developer would be keeps these in a cookie? Cookies are not secure. They are stored unencrypted on the user's hard drive (where they are easily rifled through), and (as mentioned) there have been plenty of bugs in the past that have made their data accessible to John Q. Hacker.

    Cookies are mostly used for storing session ids, or another meaningless number that links back to the real info stored in a database on the server (yes, you don't want a hacker reading your session id, but this is a much lower risk).

    This is not just for security reasons -- it's because cookies are not reliable. Cookies get wiped out all the time (all browsers that I know of let you delete them, and I see lots of ads for software that offers to manage, delete, filter, or "clean them up" for me.

    Also, cookie size is limited (and does this differ on the diff browsers? I know GET request size does), so you could screw yourself over if you were storing a user's personal info and their address was really long.

    Why would you store username/password data in a cookie anyway? Most browsers do this for you now, *and* they are more secure about it. Hm.

    These are the best practices I was taught, at any rate. I didn't checked slashcode before posting this... and I suppose it is true that best practices are not always followed.

    Does anyone have a real sense of how often sensitive data is stored unencrypted in a cookie?

    • Re:Fix it, but... what's the fuss? (Score:5, Informative)

      by Taran ( 119812 ) on Friday November 21, 2003 @02:01PM (#7529915)
      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.
      • This is true, and is one of the reasons that this is indeed a potential problem, but nonetheless, for a well-designed session implementation, this should be a relatively small window of opportunity for a hacker to exploit. I'm not saying it can't be done, just that the risk isn't particularly huge, especially when you consider that, (as I understand it), this exploit only allows malicious code to access cookies from a domain that it requests, not to scan through all available cookies. In other words, hacker
      • I've never understood why sites such as Slashdot want to use cookies for authorization... what's wrong with the standard username/password dialogue box that the browser is able to pop up and which servers like Apache easily support? That means a consistent user interface for logging in across sites, and if the user presses Cancel then he's taken to a sign-up page. The New York Times site seems to be one of the few that does this right.
    • Passwords? Private info? What serious web developer would be keeps these in a cookie?

      Well... your Slasdot login is (hashed but stealable) in a cookie right now.

      javascript:alert(unescape(unescape( document.cookies)))
      Perhaps that doesn't qualify as "serious", but don't come crying to me when your karma bottoms out after "you" post 500 goatse trolls in a row.

      • Hash in your cookie (Score:3, Interesting)

        by jtheory ( 626492 )
        Heh, aren't brownies the more traditional medium?

        Anyway, my post did have the caveat that I did NOT review slashcode before posting.... Honestly, though, slashdot seems to be designed so that you can have as much security as you want, even if that cookie has a hash of sensitive data instead of a temporary session id.

        You can control whether your login (held in the cookie) lasts for the browser session only, vs. a whole year. You can also manually logout whenever you want (again, deletes the cookie).

        If y
  • was real the first time i saw him on Sesame Street. everyone protect your cookies, ill bbl i need to find the count to make sure mine are all there.

  • Another Hole... (Score:2, Funny)

    by Anonymous Coward
    Apple needs to fix the disappearing laptop bug first. Every time I leave my laptop on a library desk and use the bathroom, my laptop is gone when I get back. Apple needs to fix this ASAP.
  • Safari is horrible with regards to clearing cached items and gobbling up disk space.

    I have a gig free on my Ti and after a morning of browsing, it's down to 500Meg. Quitting Safari does not free up this space. Restarting does.

    One would expect Safari to be much more well behaved because when the hard drive fills up, other apps often lose their prefs and general hell breaks lose.

    REAL PITA.

    • Re:That's not the biggest Safari bug (Score:4, Informative)

      by Anonymous Coward on Friday November 21, 2003 @02:35PM (#7530328)
      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.
    • 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 :)

  • Symptom of underlying problem (Score:3, Interesting)

    by TheLink ( 130905 ) on Friday November 21, 2003 @02:33PM (#7530298) Journal
    The real problem seems to be using a programming language that uses null termination. When you allow "commands" and data to intermingle so closely you are inviting trouble.

  • temporary patch (Score:1, Informative)

    by Anonymous Coward
    http://www.securityfocus.com/archive/1/345221 [securityfocus.com]

  • Firebird (Score:1, Troll)

    by lordDallan ( 685707 )
    While you're waiting for Apple to patch this why not check out Mozilla Firebird 0.7 [mozilla.org] for OS X.

    It is a great, feature rich [mozilla.org] browser. Of course you could also check out Mozilla 1.5 [mozilla.org], Camino [mozilla.org], Netscape [netscape.com], iCab [www.icab.de], Omni Web [omnigroup.com], Opera [opera.com], or even IE 5 or MSN for the Mac [microsoft.com]

    All of these can be downloaded from their respective sites, or from the Internet Utilities [apple.com] section of Apple's Mac OS X Downloads [apple.com] page.

  • Cookie theft?! (Score:1, Funny)

    by Anonymous Coward
    Oh no! Where's the key for the safe?! I don't want anybody taking my oreos!

  • OmniWeb and KHTML (Score:3, Informative)

    by Lagos ( 67371 ) on Friday November 21, 2003 @05:11PM (#7531899) Homepage
    First of all note that OmniWeb [omnigroup.com] 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 [mozilla.org] 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.
  • Does this affect the CURRENT version of Safari, v=1.1.1? I don't think so since I tried the http://alive.znep.com/~marcs/security/mozillacooki e/demo.html, link and it didn't send anything back.

  • But if you proxy... (Score:2, Interesting)

    by sitharus ( 451656 )
    I'm not vulnerable because Squid catches the URL and says 'NO! Bad!'. Using a proxy means the whole URL gets passed to the proxy, creating an error page.

    Still, irritating bug.

  • Here is the fix for this exploit: (Score:3, Informative)

    by Giffut ( 695196 ) on Saturday November 22, 2003 @07:10AM (#7535557)
    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
  • FYI, French mac site Macbidouille [macbidouille.com] recommends a fix: CookieMonsterFix [hetima.com].
    I ran it against 10.2.8 + Safari 1.0.1 (v85.6) and it looks like it works. The readme says it works with Panther as well.

  • 3rd Party Fix (Score:4, Interesting)

    by stefanb ( 21140 ) * on Saturday November 22, 2003 @09:41AM (#7535850) Homepage
    This BugTraq post [securityfocus.com] links to a Japanese page with a fix [hetima.com] (English text at the bottom).

    I was bit dubious at first, but the patch includes source code. I did install the supplied binary, though...

    What I'm really surprised about however is the fact that a) a third-party developer can fix a problem like this at all, and how easily the fix can be hooked into Safari. It appears that this OpenStep/Cocoa framework stuff is really flexible...

    Oh and yes, it does work!

    • I just went ahead and rebuilt it, and the binary is indentical to the one that they ship:

      64446 18 /Library/InputManagers/CookieMonsterFix/CookieMons terFix.bundle/Contents/MacOS/CookieMonsterFix
      64446 18 /Users/stb/working/cookiemonsterfix/build/CookieMo nsterFix.bundle/Contents/MacOS/CookieMonsterFix

Slashdot Top Deals

Say "twenty-three-skiddoo" to logout.

Close