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."
Of course, you then must live with being an utterly pathetic individual, but if you were considering doing something like this, it's probably too late to avoid that anyway.
to make a symlink from your cookies file to /dev/null. Who needs persistent cookies anyway?
That's it! Every hacker is grounded for the rest of the day.
Might the Konqueror browser be affected by this?
I'm a lazy bum you insensitive clod!
Free as in mason.
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
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?
Cookie monster wanted for questioning..
Keebler stocks plummeted in the morning hours of the stock exchange, analysts predict its going to get worse before it gets better.
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.
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.
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.
WTF? I can't believe people are spamming Slashdot!
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.
- Zav - Imagine a Beowulf cluster of insensitive clods...
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.
Well, I don't frequent those pages so as far as I know this is my very own anonymously cowardly play on words
Regarding the similar holes in other browsers:
Those that don't learn from histories/cookies are bound to repeat them. Also, those that don't learn from histories/cookies are bound to repeat them.
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.
http://www.securityfocus.com/archive/1/345221
While you're waiting for Apple to patch this why not check out Mozilla Firebird 0.7 for OS X.
It is a great, feature rich browser. Of course you could also check out Mozilla 1.5, Camino, Netscape, iCab, Omni Web, Opera, or even IE 5 or MSN for the Mac
All of these can be downloaded from their respective sites, or from the Internet Utilities section of Apple's Mac OS X Downloads page.
Oh no! Where's the key for the safe?! I don't want anybody taking my oreos!
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
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.
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.
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
FYI, French mac site Macbidouille recommends a fix: CookieMonsterFix.
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.
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!
Your, not very imaginative I gather.
Hey, now; be nice. I thought I talked about this somewhere, but here's more detail.
You're right that session cookies are a security hole, but it's much harder to use them, because most of the time when you steal them they're useless. Sessions expire, or are closed on log-out.
If you do your banking online, do you log out? Do you close the browser? Or do you even wait 15 minutes before browing to the shadier parts of the internet? Any of those and you're safe.
Here's what would have to happen for your banking session to be hijacked:
1) You log into your bank.
2) Without logging out or closing the browser first, you go to a hacker-controlled website.
3) The hacker's code requests the cookie for yourbank.com -- it must grab the cookie for that exact domain name.
4) The hacker, within the next 10-15 minutes, uses the cookie to jump into your logged-in session at yourbank.com..
Not so easy. The big problem is how to get you to visit h4x0rh0m3.com with an active session cookie from a known site.
And this is all assuming that yourbank.com doesn't do that extra check to see if your IP changes mid-session... and I'll bet most sites with dangerous access like that do.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.