Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#11

Post by emrox »

On a user level I agree, on a technical level I disagree.

Reason for disagreement is that the preview is generated once with the access rights for the user posting that link (with the permission Slacks Google Docs integration got from the posting user). For performance reason it would be quite costly to generate a preview for every viewing user since access rights could be different for every user. Also access rights can change every time, so it would be necessary to recheck permissions regularly to decide if the preview should be renewed (removed/added/changed). This also would mean users need to wait longer for the preview to generate.

So every user posting a link on Slack (or any platform which generates previews with a special integration) should be aware of that fact

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#12

Post by seanhunter »

emrox wrote: post #11

On a user level I agree, on a technical level I disagree. Reason for disagreement is that the preview is generated once with the access rights for the user posting that link (with the permission Slacks Google Docs integration got from the posting user). For performance reason it would be quite costly to generate a preview for every viewing user since access rights could be different for every user. Also access rights…

Every time someone says "for performance reasons" as a justification for wontfixing a security issue a million badguys rub their hands with glee.

If you can't do previews in a way that respects access permissions you shouldn't do them at all. This isn't a feature that is essential whereas security really is.

Moreover you really can't possibly have a security scheme that relies on every user being aware of something. Someone will either not know or will know but forget or make a mistake. Systems should be robust enough to accomodate usage by actual humans.

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#13

Post by 15457345234 »

throwaway167 wrote: post #8

Surely it is not just anyone that a link is shared with, but anyone with the link? It's link-bearer open access to a partial document (an entire page) an author marks as not having partial access. Circumvention of Google's authentication procedure. Is that understanding correct? If so, Google's seemingly OK with users believing something's secure, that isn't. And that could cause information leakage by Google's desig…

Isn't this just restating in an obscure and poorly worded fashion what the very clearly worded original post said?

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#14

Post by nonplus »

I reported to Google that I could harvest firebase JWTs and keep them alive forever in a cloud function by refreshing the access tokens from a cloud function hosted on their own platform. The key issue in my eyes was there was no way to revoke the exfiltrated JWT.

They closed the ticket as: 1) You had to compromise the frontend 2) We bought firebase within 120 days, so we won't bug bounty it.

Completely ignoring that the authentication could not be rolled. That was the last time I tried to disclose or improve a google product. I gave some talks about detecting the use of the same JWT across IP ranges, and using that as a litmus to revoke all user access until your application could contact the user.

Anyway, that was all to say my personal experience is that Google does not care about solving security issues and will actively suppress them until they reach some level of critical mass.

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#15

Post by skywhopper »

What team did you report this issue to? I think this is more about the Slack Google Drive plugin's behavior than Google Docs per se. If someone with permission to view the doc takes a screenshot of the first page of the doc and sends that to you, there's nothing really that Google Docs can do to stop that. That's analagous to what's happening here. The Google Docs Slack integration is what's sharing the preview image.

I agree that it's poor behavior and potentially could be part of a critical security compromise. But you'd need to get a hold of the right team. The Google Docs core engineers probably don't care and couldn't fix it anyway.

I don't know for sure (and can't check now since I no longer work there), but my impression at a former job that made heavy use of Slack and Google Docs was that in a corporate setting with Google Enterprise or whatever it's called, the Slack integration was far more cautious about showing previews. It even alerted you if you posted a document that not everyone in the channel could view, and gave you the ability to grant them access right then and there. IIRC, previews were hidden if you didn't have access. I don't know if that is a different plugin or just better behavior in a corporate setting.

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#16

Post by deepakjc »

filleokus wrote: post #6

This issue have been reported multiple times over the years: - https://news.ycombinator.com/item?id=37854159 (October 2023) - https://news.ycombinator.com/item?id=32770709 (September 2022) - https://twitter.com/matbennett/status/1171015871868874757 (September 2019) So you are at least not the first one to get dismissed. EDIT: Jogging the memory in the other threads, this happens when the person posting the link have…

Wow, 3 separate mentions on HN is pretty high (and those were the ones you were able to find). This must have been reported dozens of times to Google.

That said, if (a) this is only occurring with the 2 conditions you mentioned and (b) if Google Drive integrations are only allowed with vetted partners, then I suppose this is less exploitable. Someone would have to intentionally put the link into a 3rd party application that had some people who shouldn't have access.

Though it still be a problem I think, privacy is important even internally. Sometimes access needs to be revoked, or people are unaware of all the people who have access to a channel etc.

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#18

Post by deepakjc »

skywhopper wrote: post #15

What team did you report this issue to? I think this is more about the Slack Google Drive plugin's behavior than Google Docs per se. If someone with permission to view the doc takes a screenshot of the first page of the doc and sends that to you, there's nothing really that Google Docs can do to stop that. That's analagous to what's happening here. The Google Docs Slack integration is what's sharing the preview image…

Ah, this is a helpful insight. I didn't realise that this is how the integration works. It seems that, at most, Google could force Slack to update their integration's behaviour (and take down the integration till that happens). But as you mentioned, they can't really fix it themselves.

I probably wouldn't have posted this if I had received this explanation from Google. :)

This was their response: "Hi! We've decided that the issue you reported is not severe enough for us to track it as a security bug: when someone with access to a doc sends a link over slack, they express their intent to share this document, hence the preview shared independently from the sharing setup on the doc does not represent a significant risk."

Re: Google marked this vulnerability as "Won't Fix" but I disagree. Care to comment?

#20

Post by kevincox »

If I am understanding what is happening is that the sender has access to the document and via the Google Drive plugin for Slack they are effectively attaching a preview image when the share the link.

So the stance that Google is taking is probably taking is that this is equivalent to the user sharing the link also sharing a screenshot as a preview. (Something that they have permission to do)

I do agree that this may be a bit surprising but the sender has "opted-in" to this behaviour when they signed into the Google Drive plugin for Slack. But I don't find Google's perspective completely unreasonable.

Post reply on HN