Slashdot Mirror
Safari Security Hole Allows Cookie Theft
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."
to make a symlink from your cookies file to /dev/null. Who needs persistent cookies anyway?
Just goes to show that companies should closely monitor security holes in competing products.
One should not theorize before one has data. -Sherlock Holmes-
Apple: Who me?
Marc Slemko: Yes, you.
Apple: Couldn't be.
Marc Slemko: Then who?
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.
sigs are like a box of chocolates, they all suck remove the underscores to email me
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.
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?
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?
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
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.
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.
This isn't a Safari bug, this is how your OS deals with virtual memory.
/var/vm
Look in
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
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.
Safari 1.1.1 (v100.1)
Still see my ebay cookies.
Maybe you cleared your cookie cache or have accepting them turned off?
You're just jealous because the voices only talk to me.
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.
.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.
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
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 you do either of those (and don't visit possible cracker-owned sites while you're logged in) you are perfectly safe, since the hacker won't ever be able to see the slashdot cookie.
[I'm assuming that's a hash of the username AND password -- if it's only the username, that's insecure, since the cracker could just figure out the hash algorithm and make cookies from whatever username they wanted.]
Slashdot is unusual in that we have that option (because Taco figures we'll understand it, I guess). In general, sites decide this for you, and don't allow "eternal login" if there's sensitive data at risk -- at most they will save your login name for you (but not the password).
See? No goatse.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
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)
no it is not already patched. I am running Safari 1.1.1 (v100.1), and the insecure website's proof-of-concept DOES show me ALL cookie stored in the .ebay.com domain.
Extraordinary Vacations. Exceptional Prices
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.
--sitharus
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
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!