5 ms·

More Security Loopholes Found In Google Docs

25 points by vaksel 18y ago

bcl 18y ago
These recent problems with Google Docs highlight a bigger problem with keeping your data 'in the cloud', you are trading security for ease of use and even if you have the best development team in the world behind the app there are still going to be leaks. If your docs are inside your organization's firewall you have some assurance that leaks can be discovered before everyone in the world has access. With services like Google Docs all bets are off.
electromagnetic 18y ago
Oh blah, blah, blah. The first two aren't major privacy blunders, they're definitely not good but they already violate two long existing recommendations. First, never upload a picture that you care if other people see, so basically no compromising pictures. Second, if you're conducting secret/illegal business, use a fucking pen and paper! The third isn't even valid because he provides no proof. > "If that last claim turns out to be valid, I’m leaving Google Docs and never coming back." Ugh, there goes my respect for yet another TC writer. I really can't stand how TC seems to have gone down the drain so fast, they used to be respectable but now it seems like bogus semi-fraudulant article after another.
TweedHeads 18y ago
Enough of techcrunch mudslinging propaganda already! What is HN becoming?
- mbrubeck 18y ago
  Yeah, couldn't we at least link to the original blog post? The TechCrunch writeup adds nothing. http://peekay.org/2009/03/26/security-issues-with-google-docs/ http://peekay.org/2009/03/26/security-issues-with-google-doc...
lsb 18y ago
The bad thing about keeping your data in the cloud is that you don't really know 100% if it's secure. The good thing is that you all get security updates at exactly the same time without doing anything.
- dsil 18y ago
  Well, even if you don't keep it in the cloud you don't really know if its 100% secure. And if you do "know" its 100% secure, you're wrong. So its just a choice of who you trust more - google, your own company, some other company, etc
neilo 18y ago
Do these issues really warrant such an article? That closing statement was pretty silly
deleted 18y ago
[deleted]
kwamenum86 18y ago
These exploits sound similar to the recent Facebook photo exploit. Google keeps information in redundant server farms so they can continue to server billions of pages a day. Complex permissions usually do not mesh well with this method of keeping data because it is impractical and maybe impossible to use sessions or cookies to see if the user attempting to access a file has permissions to do so. A (startup?) company could do a lot to solve these problems by rethinking the way permissions work with distributed data. I think the space is wide open and the market needs a better solution.
mustpax 18y ago
Ok, I'm gonna try to address each of these "loopholes" one by one, because this whole thing smells like fishy PR stunt (I'd say FUD, but HN ain't slashdot right?): 1. Non-private uploaded images: This is the image URL http://docs.google.com/File?id=dczjts34_227g3234gdg_b http://docs.google.com/File?id=dczjts34_227g3234gdg_b. That looks like a pretty secure random UUID to me. You have as much chance of guessing that as guessing an account password. So the only problem here is revoking view access for someone to the document after they have viewed it. They can keep accessing the Document, if they have a copy of it. Which will always be true unless you want to start serving DRMed PDF files or something. I wouldn't put that past this particular security researcher. 2. User can view earlier revisions of a diagram: Fair enough. Once again, it doesn't seem like a complete breakdown of security if your collaborators can view earlier versions of a document or a diagram within a document. Personally, when I share a versioned document with someone, I expect they will be able access the versioning information. I don't know if Google makes any express guarantees about earlier versions being blocked off from viewers, maybe they should, but it's worth making it explicit. 3. Someone somewhere may be able to grant herself access to your documents: I am not even going to address this one. Without an actual account of the vulnerability, this is just irresponsible insinuation.
- sounddust 18y ago
  I disagree with you about #1. There is no reason that serving these images shouldn't go through the same authentication that accessing the document requires (not DRM'd PDFs, just checking the cookies of the request for that image to make sure the user is logged in and has access to the doc). Just because they're available through a non-guessable URL doesn't make them secure; there are dozens of ways that URL can leak without leaking the whole document. Also the fact that the image is permanently retained after the document is deleted is completely unacceptable. It's obvious that they are trying to save money on bandwidth and CPU here, but it's not an acceptable place to cut corners. As for #3, I think that it's pretty easy to guess what this vulnerability is. It's probably the following: When you get an invite to view a shared document, either 1) Accepting the invitation after the document has changed and permission redacted still gives you permission to see it 2) After your permission is revoked, you can use that URL to regain permission to the document.
chanux 18y ago
If Free Software concepts spread in cloud, things will be better anyway.

25 points by vaksel 18y ago

bcl 18y ago

These recent problems with Google Docs highlight a bigger problem with keeping your data 'in the cloud', you are trading security for ease of use and even if you have the best development team in the world behind the app there are still going to be leaks. If your docs are inside your organization's firewall you have some assurance that leaks can be discovered before everyone in the world has access. With services like Google Docs all bets are off.

electromagnetic 18y ago

Oh blah, blah, blah. The first two aren't major privacy blunders, they're definitely not good but they already violate two long existing recommendations. First, never upload a picture that you care if other people see, so basically no compromising pictures. Second, if you're conducting secret/illegal business, use a fucking pen and paper! The third isn't even valid because he provides no proof. > "If that last claim turns out to be valid, I’m leaving Google Docs and never coming back." Ugh, there goes my respect for yet another TC writer. I really can't stand how TC seems to have gone down the drain so fast, they used to be respectable but now it seems like bogus semi-fraudulant article after another.

TweedHeads 18y ago

Enough of techcrunch mudslinging propaganda already! What is HN becoming?

mbrubeck 18y ago
Yeah, couldn't we at least link to the original blog post? The TechCrunch writeup adds nothing. http://peekay.org/2009/03/26/security-issues-with-google-docs/ http://peekay.org/2009/03/26/security-issues-with-google-doc...

lsb 18y ago

The bad thing about keeping your data in the cloud is that you don't really know 100% if it's secure. The good thing is that you all get security updates at exactly the same time without doing anything.

dsil 18y ago
Well, even if you don't keep it in the cloud you don't really know if its 100% secure. And if you do "know" its 100% secure, you're wrong. So its just a choice of who you trust more - google, your own company, some other company, etc

neilo 18y ago

Do these issues really warrant such an article? That closing statement was pretty silly

deleted 18y ago

[deleted]

kwamenum86 18y ago

These exploits sound similar to the recent Facebook photo exploit. Google keeps information in redundant server farms so they can continue to server billions of pages a day. Complex permissions usually do not mesh well with this method of keeping data because it is impractical and maybe impossible to use sessions or cookies to see if the user attempting to access a file has permissions to do so. A (startup?) company could do a lot to solve these problems by rethinking the way permissions work with distributed data. I think the space is wide open and the market needs a better solution.

mustpax 18y ago

Ok, I'm gonna try to address each of these "loopholes" one by one, because this whole thing smells like fishy PR stunt (I'd say FUD, but HN ain't slashdot right?): 1. Non-private uploaded images: This is the image URL http://docs.google.com/File?id=dczjts34_227g3234gdg_b http://docs.google.com/File?id=dczjts34_227g3234gdg_b. That looks like a pretty secure random UUID to me. You have as much chance of guessing that as guessing an account password. So the only problem here is revoking view access for someone to the document after they have viewed it. They can keep accessing the Document, if they have a copy of it. Which will always be true unless you want to start serving DRMed PDF files or something. I wouldn't put that past this particular security researcher. 2. User can view earlier revisions of a diagram: Fair enough. Once again, it doesn't seem like a complete breakdown of security if your collaborators can view earlier versions of a document or a diagram within a document. Personally, when I share a versioned document with someone, I expect they will be able access the versioning information. I don't know if Google makes any express guarantees about earlier versions being blocked off from viewers, maybe they should, but it's worth making it explicit. 3. Someone somewhere may be able to grant herself access to your documents: I am not even going to address this one. Without an actual account of the vulnerability, this is just irresponsible insinuation.

sounddust 18y ago
I disagree with you about #1. There is no reason that serving these images shouldn't go through the same authentication that accessing the document requires (not DRM'd PDFs, just checking the cookies of the request for that image to make sure the user is logged in and has access to the doc). Just because they're available through a non-guessable URL doesn't make them secure; there are dozens of ways that URL can leak without leaking the whole document. Also the fact that the image is permanently retained after the document is deleted is completely unacceptable. It's obvious that they are trying to save money on bandwidth and CPU here, but it's not an acceptable place to cut corners. As for #3, I think that it's pretty easy to guess what this vulnerability is. It's probably the following: When you get an invite to view a shared document, either 1) Accepting the invitation after the document has changed and permission redacted still gives you permission to see it 2) After your permission is revoked, you can use that URL to regain permission to the document.

chanux 18y ago

If Free Software concepts spread in cloud, things will be better anyway.