Slashdot Mirror
GMail Vulnerable To Contact List Hijacking
Anonymous Coward writes "By simply logging in to GMail and visiting a website, a malicious website can steal your contact list, and all their details. The problem occurs because Google stores the contact list data in a Javascript file. So far the attack only works on Firefox, and doesn't appear to work in Opera or Internet explorer 7. IE6 was un-tested as of now."
So is this a Firefox, Gmail, or javascript vulnerability?
RTFA:
I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three.
Does the submitter have some agenda against Firefox?
My server
We are lucky it was not Microsoft's Hotmail!
http://www.digg.com/programming/GMail_Hacked_VisiIn illa quae ultra sunt
http://docs.google.com/data/contacts?out=js&show=A LL&psort=Affinity&callback=google&max=99999
It can be exploit by writing a callback function in Javascript, that can do anything, and then passing it to the above link, which gives your function all the users contact info.
I'll probably be modded down for this...
Slashdot says:
"So far the attack only works on Firefox, and doesn't appear to work in Opera or Internet explorer 7"
TFA says:
"I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three."
Got any jobs going? I could do nice armchair job at Slashdot. I'd be willing to work the full 3 hours a week.
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
How can one page get access to another page's data? Javascript or not? Aren't pages that don't have a parent child hierarchy supposed to have no way to communicate (aside from same site cookies)? How does this work
Some drink at the fountain of knowledge. Others just gargle.
Thank goodness. I was beginning to think that no one cared about my contacts.
Loading script files to exchange data with the server is a very common mechanism. It even has a name: JSON. It wouldn't surprise me to find that there are many more web applications which could be exploited in this way. This isn't a browser vulnerability or a simple bug. It is a design flaw of a widely used communication protocol.
http://googlified.com.googlepages.com/contactlist
The page now says: Causing too much trouble already... I am sorry if it causes any inconvenience to you, or make you feeling the insecure of Google.
plugging googlified.com.googlepages.com into google
brings us to this url: http://blog.outer-court.com/forum/79255.html
Which in turn has a link to this site:
http://googlified.com/2006download-the-google-map
A whois lookup on googlified.com
P.S. http://googlified.com/about/
"More deeply, I am a 16 year old from the political battle ground in the United States - Ohio. I am currently a sophomore in a not-so-bad high school."
[Fuck Beta]
o0t!
I think the keys in JSON needs to be strings
I'm glad that I run Firefox on Linux!
Oh wait...
That's funny. I can't seem to find the download link for Linux?
http://blogs.zdnet.com/Google/?p=434
it is fixed.
just FYI, it works with Galeon (2.x) as well.
I think it can be solved by Google checking HTTP referer before sending out the contact list via JSON, as long as the browser does not use cached content.
me, at 843 hours (PST), using FF 2.0.0.1, the problem is not fixed.
damaged by dogma
These problems will not go away. Software engineers will always make mistakes and malevolent people will always want your private data. The Web is "open" by design and therefore open to exploits.
With the Web browser becoming an application portal, users need to understand that doing transactions that involve their personal data must be separate from general Web browsing.
You can switch off cookie permission and Javascript but this limits the functionality of many sites. I think the best solution is to use two different browsers, one for personal transactions, the other for wandering the Web.
Rich And Stupid is not so bad as Working For Rich And Stupid.
Sure, I can hack the referrer to get into my own gmail account. Wooo, scary!
My browser should not grant this ability to random javascript it finds on the web.
C'mon, /. You're reporting this now? It's already been fixed.
"We are lucky it was not Microsoft's Hotmail!"
/. hardcore fully appreciate how skittish end-users have become about this stuff, esp since they can't tell fact from rumor, or javascript from egg nog (well, neither can i). step back and think about how the poor unwashed masses will feel when stories start circulating about some deadly hole, crack or loose gear in gmail.
i'm always happy to tell the tale of MS's FTC privacy bust in 2002. but there's a not so funny side to software vulnerabilities for the millions of poor slobs who aren't reading this thread, or any like it. i don't think the
the good news is that awareness and suspicion levels about software have gone way up in the last 18 months. the bad news is that skill and effort levels for dealing with this shit haven't gone anywhere. i get my read from the 3rd and 4th year undergrads i teach. smart as they may be, most are just beginning to sense that working on redmond's software may have a downside. the students in question were stunned recently when attachments created in Word were banned until further notice.
so what's the bottom line here? has google been getting too much whitewash? is the problem solved? should people be falling all over themselves to revive their hotmail accounts? can non-geeks ever find a realistic way to manage their software expectations?
disclaimer: we're doing several weeks this term on google. then vista's drm nightmare. i am not, however, prepared to disclose how many gmail invitations i sent out in 2006.
Lots of ways:
a. Place a 128-bit random number (UUID/GUID) into the URL for the contacts info.
b. Check the referrer. (foreign javascript should not be able to forge this)
c. Place an encrypted copy of the cookie into the URL of the contacts info.
d. Embed the contacts info in the page instead.
Who has the gmail cookie?
Who wants to do the spoofing?
How is the spoofer going to get the cookie?
Right...
This is only a problem for people who are violating one of the primary security policies in the first place, and that's putting your contact list in Gmail in the first place. While Google may claim to not be evil now, there's no guarantee at any time in the future, all the information they collect from you and on you won't be given or sold to other entities or otherwise exploited for nefarious purposes. In fact, it's pretty much an inevitability this will happen, so it's not smart in the first place to store much information on their systems when more secure alternatives already exist.
As reported, it is fixed, at least in my case where I'm using Firefox 2.0 on Linux.
I like how open source software bugs get fixed (usually) really fast when compared to non-open source software.
David
Still works for me. You can run this script from a local html file to check:
s how=ALL&psort=Affinity&callback=google&max=99999"> </script></head>
<html>
<head>
<script>
function google(a) {
document.write("<ol>");
for (i = 0; i < a.Body.Contacts.length; i++) {
document.write("<li>" + a.Body.Contacts[i].Email + "</li>");
}
document.write("</ol>");
}
</script>
<script src="http://docs.google.com/data/contacts?out=js&
<body>
Hello
</body>
</html>
ENDUT! HOCH HECH!
It looks to me as if the real culprit is 3rd party cookies. These have almost no legitimate use, and are mainly used by advertisers like doubleclick.net to track users. Third party cookies are turned on by default in the browsers, but you can turn them off. This is another reason to turn them off.
You forgot AJAX: Store the contacts on the server as an XML resource and let the browser cache the XML. Replace the JSON load/unload code with stuff that loads the XML contact resources in the background and invalidates the cache with blank data at logout.
Only happens in FireFox....and not IE7 (IE6 wasn't tested). at the time of my posting this, only 66 replies.
/. fanbois ignore things that are exposures of security issues with Firefox...
Funny. If it said "this only happens in IE" there would be 500+ replies, all saying how badly IE sucks and how you should use Opera or FF.
Funny how the
"By simply logging in to GMail and visiting a website, a malicious website can steal your contact list, and all their details. ..."
In other words, the submitter says that when a malicious website logs into Gmail and visits a website, it can steal my contact list.
Someone needs to learn how to use dependent clauses. The subject of the sentence above is a malicious website, and that's who is being described in the dependent clause as logging into Gmail and visiting a website.
How can get to front page an article about some browser vulnerabilities that says it's untested on the most used one?
"With some cell phones you can call for free. It works with Phillips and Siemens, it does not on Panasonic, and has not been tested on Nokia, SonyEriccson or Motorola."
Lol, then test it before wasting our time.
I'm using one Firefox instance only for GMail/Yahoo!/eBay/banking website and another one for surfing. Both instances are launched from separate user accounts, displayed on the same X (but in different 'virtual desktops'). I don't ever enter any personal information in the 'unsafe' user account I use for surfing. It's a sad state of affair, but it's a fact that the lists of vulnerabilities for every single browser is lloonngg (browser more secure than IE [not hard] have regularly vulnerabilities rated 'critical'). So a long time ago I decided that surfing from my main user account was not a good idea. This post brougth to you by a throwaway user called 'temp' that has only one non-hidden dir: ~/firefox/. For some time I was even surfing using a temp user on a throwaway Xen para-virtualized Linux guest, but sometimes I watch some Youtube/Metacafe crap and it wasn't nice over VNC.
Waaahhhh!!!
I like how so many of you are pointing the blame to anyone BUT Google.
Susbsitute Hotmail for GMail in the article, and see if you have the same spin.
We all know that if hotmail had this vulnerability, there'd be hundreds of posts here gloating. Instead, we have Google sycophants spinning like crazy!!
Get it through your thick skulls - Google's programmers are no better than anyone elses. They all come from the same universities. Google programmers are not gods, they're humans, and just as capable as screwups as anyone else. Maybe even more so, given the arrogance of the company that leads their employees to believe their own press clippings about how superiour they are to anyone else.
This is not the first time that Google has been extremely sloppy and careless with users' personal info, and it won't be the last.
And to think, this is the company that slashdotters advocate businesses use for corporate email and corporate document storage!! LOLOLOL
C'mon, mods. Follow the links and read before moderating.
I don't care why you're posting AC
I spoof the referrer all the time, using the "wget" command. That does no good for attacking gmail though, because how am I to get the required cookie?
The spoof would have to work from Javascript or Java, creating connections on behalf of the user. Merely opening a TCP/IP socket won't do, because you'd not be able to shove the cookie down the wire.
You shouldn't be suprised... as you all know GMail is still in beta.
It doesn't seem to work in Opera 9.02, despite some people saying that it works on every browser. Either Google has changed something or the example code isn't working.
Worth noting that this exploit doesn't work at all if you use Google Apps For Your Domain, you just get a JS file saying "success: false"
I posted this on reddit which broke the story earlier, and on my blog. Thought you might find it useful.
. txt
Quick follow-up. On digg someone posted the un-obfuscated code: http://www.cc.gatech.edu/~achille/contacts-source
How it works
The code is pretty straightforward. Basically, Google docs has an embedded script that will run a callback function, passing the function your contact list as an object. The embedded script presumably checks a cookie to ensure you are logged into a Google account before handing over the list.
Unfortunately, the script doesnt check what page is making the request. So, if you are logged in on window 1, window 2 (an evil site) can make the function call. Since you are logged in somewhere, the cookie is valid and the request goes through.
Also, if you check the object that is returned, you see fields for the contact's name, email and "affinity". Presumably, a higher affinity means a more-emailed contact, so it may be possible to know the relative weight of links.
Possible solutions
Google is run by smart people and I'm sure they'll have this fixed soon. A few suggestions appear to be popping up, all centered on making sure the user is on a Google.com page and not a random site:
Referrer blocking: Block all requests from sites not in the google.com domain. However, some people run referrer-blocking software. It may be the price they have to pay for security, but there could be other consequences.
Script checks: An idea I had was to check the window.location (just like you check the cookie) to make sure it's coming from a google.com domain. This is another way to see what page is making the request.
Challenge-response: Google pages (like Gmail) can have some token or unique, computed data that they submit with their requests. Random pages won't have access to this token when they make the function call.
(From user JRF on reddit): Include part of cookie in the request URL as a unique token that only a "real" Google page would know. Need to watch out for proxies/browser history (accessible from other pages) being able to access this unique data. May need to seed or salt it in a challenge-response system.
It's interesting thinking of fixes for this - do you have any other suggestions for how Google would fix this?
I tried the first link in the article and I got a page with only this text: google ({ Success: false, Errors: [] }) It seems to not work. I'm using Firefox v. 1.5.0.9, and I was logged in to gmail at the time. Can anyone explain this?
When it comes to pastry theft, I take the cake.
It's a CSRF attack. For more details see this blog post http://getahead.ltd.uk/blog/joe/2007/01/01/csrf_at tacks_or_how_to_avoid_exposing_your_gmail_contacts .html#preview
DWR is Ajax for Java
XML has no special cross-domain security over plain JSON.
JSON is not the problem here. The problem was the stupid google({}) function call wrapped around the JSON in the reply. Remove that stupid function call and everything is fine. Since you cannot receive or send data via XmlHttpRequest to a domain other than the one that served up the HTML, you will not be at risk if only JSON is returned.
The sky is falling!
The sky is falling!
Sheesh.
I agree completely. It is a Google bug, plain and simple. JSON in a browser is perfectly safe if used correctly.
google has already fixed this problem
It has now been fixed.
This was a complete waste of a post! Unless its intent was to drum up some reader responses due to a decline in web activity which perhaps led to a decline in revenue for this site. Just thinking out loud.
I run gmail and other google services requiring login from a separate browser. Set the theme so this browser is visually distinct from your main browser. On Linux use a wrapper script to start with a different user. On Windows you can use K-Meleon (unfortunately, PortableFirefox cannot run in parallel with regular firefox).
Not perfect, but it works for me.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.