[ikeboy]

>Given that Google can't remotely remove the extension from Chrome browsers if it has been installed, what would you do? Refuse to permit AVG to update the extension in the Web Store until they fix all of the XSS issues on those two domains? If so, why?

I'm not sure that's a given. They can update it, so why can't they update to a dummy version? (It looks like extensions in the store are signed by Google, not the developer, so they can update themselves if needed. Or at least that's what https://developer.chrome.com/extensions/packaging#upload seems to imply).

But even if we accept the premise, they can allow AVG to update the extension without revealing that there are existing XSS vulns that expose 9 million users.

Even the knowledge that "if you find an XSS in insecure-sites A and B, you can pwn 9 million users) seems highly sensitive, and should not be publicized according to Google's policies as far as I can tell.

>If they did, he would no longer be working for Google.

That's not really an answer. Does it make sense to you that it doesn't violate Google's policy, and if so, how?

[simoncion]

> That's not really an answer.

If Ormandy violated Google's vuln disclosure policies, he would no longer be doing security research at Google. Ormandy is still doing security research at Google. Therefore, he did not violate Google's vuln disclosure policies.

> (It looks like extensions in the store are signed by Google, not the developer, so they can update themselves if needed. Or at least that's what https://developer.chrome.com/extensions/packaging#upload seems to imply).

They might be able to do that. Read the whole page. You'll see that extension authors can decide to either upload an already-signed extension (as is done with Android), or let Google sign it for them.

Assume that AVG -seeing as how they're a security software company- is uncomfortable with keeping their code signing keys on Google's servers, and is uploading already-signed packages to Google. [0] What's your answer to the question I posed in my previous comment? Feel free to take some time to think through your answer.

[0] This means that Google can't silently replace the code that their client uploaded with code of their own choosing. [1]

[1] And -I mean- it would be EXTREMELY bad news if Google did use the signing keys they're -presumably- (for some devs) holding in escrow to replace a dev's code with some other code that Google thinks is better. That's an enormous violation of trust. I don't think you understand how very serious that would be.

[ikeboy]

>If Ormandy violated Google's vuln disclosure policies, he would no longer be doing security research at Google. Ormandy is still doing security research at Google. Therefore, he did not violate Google's vuln disclosure policies.

I understood what you said before. But that doesn't tell me why it's not a violation. It's like knowing something's a theorem without knowing a proof.

>They might be able to do that. Read the whole page. You'll see that extension authors can decide to either upload an already-signed extension (as is done with Android), or let Google sign it for them.

It says if they do that, then they either need to upload the private key, or it will have a different id, and I assumed the second was because Google's resigning it.

>Assume that AVG -seeing as how they're a security software company- is uncomfortable with keeping their code signing keys on Google's servers, and is uploading already-signed packages to Google. [0] What's your answer to the question I posed in my previous comment? Feel free to take some time to think through your answer.

I answered that: update the extension, but don't publicize the issue.

>[1] And -I mean- it would be EXTREMELY bad news if Google did use the signing keys they're -presumably- (for some devs) holding in escrow to replace a dev's code with some other code that Google thinks is better. That's an enormous violation of trust. I don't think you understand how very serious that would be.

I think that once Google decided not to allow unsigned extensions for some platforms, it's also okay for them to remotely remove extensions that pose a security risk. I honestly don't know if they have that capability, and a few searches didn't answer that for me.

Also, taviso popped up here: https://news.ycombinator.com/item?id=10813460 to repeat what he said on the report, and that the policy was followed. I assume he means that since the release wasn't directly exploitable, there's no problem with releasing it.

[simoncion]

> Also, taviso popped up ... to repeat what he said on the report, and that the policy was followed.

...does that satisfy you, or are you still dissatisfied?

> ...they either need to upload the private key, or it will have a different id...

The documentation isn't 100% clear on what that means. What I would expect to happen is that the signed code package gets re-signed once by Google's systems, the ID changes, and then -just as long as you keep uploading with the same private key- that ID will remain the same. [0]

Notice how [1] mentions that you have to point to your locally-stored private key that was created back when you locally signed your Chrome Extension to package and publish updates? That wouldn't be required if Google's systems didn't check to make sure that the key that signed the current version of the package is the same as the one that signed the previous version. [2]

If they are re-signing already-signed Chrome extensions and _ignoring_ the dev-supplied signature, then that's really nuts, super squicky, and a rather dramatic departure from the entirely reasonable model that they use in Android.

I really doubt that they're doing that. That would make dev-held keys completely useless.

> ...update the extension, but don't publicize the issue.

Ah, I missed that. I should go caffeinate. :/

So, should Google have a possibly indefinite disclosure embargo period? Or maybe just have a policy of never putting any details at all into security bug reports?

> ...it's also okay for them to remotely remove extensions that pose a security risk.

You see that that removal from the store (or -assuming that they have the power to do so- remote removal from Chrome) is entirely and dramatically different from modifying uploaded code on behalf of the dev, right?

[0] The key phrase for me here is "This different ID might be a problem if you've distributed your extension package..." (Emphasis mine.)

[1] https://developer.chrome.com/extensions/packaging#update

[2] Or -obviously- if Google was making a show of checking, but that sort of subterfuge would be trivial to demonstrate and a huge breach of trust.

[ikeboy]

>...does that satisfy you, or are you still dissatisfied?

Like I said, I'm satisfied that it followed the policy. I don't fully understand why, though, and want clarification. I assume that if he'd found a usable exploit then he wouldn't have published it: note that until he posted, I was assuming he did find a usable exploit, and was arguing that that shouldn't have been disclosed, a position people disagreed with me on.

>So, should Google have a possibly indefinite disclosure embargo period? Or maybe just have a policy of never putting any details at all into security bug reports?

Their 90-day policy seems reasonable.

>You see that that removal from the store (or -assuming that they have the power to do so- remote removal from Chrome) is entirely and dramatically different from modifying uploaded code on behalf of the dev, right?

I only mentioned that as a way to remove the extension. I had assumed they can update an extension, and therefore thought they can replace an extension by one that does nothing.

I'm no longer sure. They could do with better documentation.