[simoncion]

> I clicked on the extension link earlier...

Ah, I was mistaken. Inline installation is blocked, and inline installation is a special process which is described here. [0] So, AVG could change their site to not use inline installation for a little while until the investigation is completed.

Anyway, it's clear that you don't (and won't) agree with Ormandy. Ormandy has an established track record and is currently employed by a security-focused company, performing security bug elimination work. AFAIK, [1] you're a guy who knows how to spell XSS and nothing more.

Have you... like... even considered that a not-insignificant number of Chrome extensions also expose their users to XSS vulnerabilities? And that... like... maybe that's the current status quo, that the initial issues were beyond the pale, and the remaining possible XSS threat for just two domains -while shitty- is not substantially worse than average?

I mean, just spitballing here.

And if you did consider that, then why on earth would you expect a professional to mention that in a bug report? That's Grade-A gossip rag clickbait.

[0] https://developer.chrome.com/webstore/inline_installation

[1] Because, like, you've not offered up any information regarding your work history and training (formal or otherwise).

[ikeboy]

>Anyway, it's clear that you don't (and won't) agree with Ormandy. Ormandy has an established track record and is currently employed by a security-focused company, performing security bug elimination work. AFAIK, [1] you're a guy who knows how to spell XSS and nothing more.

I don't think he's made a factually incorrect claims. You think his closing implies the XSS was fixed, and if that's the case, I know enough about XSS to know it wasn't fixed (as I said, clicking on his link executes the alert(1) code). If he knows the XSS wasn't fixed but thinks it wasn't a big deal, then he hasn't said anything false. But in that case, I have a ethical problem with his actions, partly because they seem to violate Google's policy, and partly because he's revealing a 0-day in a chrome extension without even removing the extension from the store. The benefits of full disclosure can be debated. But if you currently offer software for download, don't continue to offer it after you've 0-day it without a patch. That seems unnecessarily nasty to your users.

No, I don't work in security. I'm actually in college now. But I know a bit more than just how to spell XSS. What about you?

>Have you... like... even considered that a not-insignificant number of Chrome extensions also expose their users to XSS vulnerabilities? And that... like... maybe that's the current status quo, that the initial issues were beyond the pale, and the remaining possible XSS threat for just two domains -while shitty- is not substantially worse than average?

According to the report, the extension bypasses chrome's detection, which presumably violates Google's policy. So I think it shouldn't have been publicized until the decision whether to keep the extension was completed. Also, I think Google shouldn't publicize information on a currently active XSS, as above.

Now, I just happened to look at the report again, and it has a new comment at the end. He says (in response to someone with the exact same concern as me) "The XSS you're referring to cannot be used as-is due to mixed-content, it was intended to be illustrative only."

So that might account for it, although it still seems like it shouldn't have been released before AVG finishes the audit, or decides not to, or whatever.

[simoncion]

> You think his closing implies the XSS was fixed...

If "the XSS" means "Any XSS/mixed-content issues presented by pages on the two whitelisted domains, as mentioned in Comment #7 of the issue in question.", then no, I don't think that at all, and don't understand how you'd think that I thought that.

As I've repeatedly said, Ormandy believes that the original issue reported by Ormandy is fixed. For the avoidance of doubt, "the original issue" is the issue reported in the issue description.

> ...I have a ethical problem with his actions... I think Google shouldn't publicize information on a currently active XSS ...

Oh, that's very obvious, and has been from the start.

> ...partly because they seem to violate Google's policy...

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

> ...and partly because he's revealing a 0-day in a chrome extension without even removing the extension from the store.

Strictly speaking, what you say is true. OTOH, XSS vulns are everywhere on the internet. Additionally, you have to consider that The Bad Guys were likely already aware of the problems that Ormandy uncovered.

> It still seems like it shouldn't have been released before AVG finishes the audit, or decides not to, or whatever.

Think about this:

* The broken extension allowed any MitM, or any evil webmaster to inject code into and effectively disable SSL for every site on the internet.

* The fixed extension only exposes its users to XSS from pages on two domains, both managed by AVG.

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?

[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.