I read the whole page, and nowhere is mitigation for the xss mentioned, nor is permission given to publish. Given that, I don't see why they didn't stick to the 90-day release deadline.
I read that as saying the fix for the first issue, which wasn't sufficient. If it was for the second, then they would have submitted it directly first like they did the first, not by uploading to the webstore.
> I read that as saying the fix for the first issue, which wasn't sufficient.
Eh?
The reported issue is fixed. If it wasn't, Ormandy wouldn't have marked the bug as "Fixed", and said "I believe this issue is resolved now". Presumably, AVG has also promised to "...get a professional web audit of those whitelisted domains...".
Ormandy's no hack, dude.
> ...they would have submitted it directly first like they did the first, not by uploading to the webstore.
...how else would AVG get the update into the hands of users? Email a copy to them?
>The reported issue is fixed. If it wasn't, Ormandy wouldn't have marked the bug as "Fixed", and said "I believe this issue is resolved now". Presumably, AVG has also promised to "...get a professional web audit of those whitelisted domains...".
The XSS is not fixed. Loading the link still executes arbitrary javascript. If the audit is agreed but not performed (which doesn't seem evident from the page) then they should wait until it's complete before publicizing this.
>.how else would AVG get the update into the hands of users? Email a copy to them?
I meant as they submitted the previous fix to the bug finder for approval. It sounds to me like the following happened:
1. Guy finds a bug, reports it
2. They build a fix, send it to him
3. He finds a problem with the fix
4. They submit the flawed fix to the webstore (unclear if this happened before or after 3)
5. Guy is happy and publishes bug, including details of wide-open hole, enabling exploitation of any AVG user with the extension.
The reported issue "AVG: "Web TuneUP" extension multiple critical vulnerabilities" is fixed. The issue submitter, investigator, and closer is the same person, Tavis Ormandy.
As reported by Ormandy: "This isssue appears to be resolved in version 4.2.5.169 of the chrome extension, which looks like it's about to be made available for update on the webstore..." and then, a few days later: "I believe this issue is resolved now, but inline installations are disabled while the CWS team investigate possible policy violations.".
> It sounds to me like the following happened...
It's clear to me that that's not how it went down. From the bug report:
"This isssue appears to be resolved in version 4.2.5.169 of the chrome extension, which looks like it's about to be made available for update on the webstore..." (Emphasis mine)
How could Ormandy investigate and report on a new version of the software before it was uploaded to the Webstore, if AVG never sent it to him to evaluate, and he had to download it from the Web store to investigate it?
Pause for a moment and think about that. It's an important question.
After you've achieved enlightenment, remember that Tavis Ormandy is not some hack. Go do a bit of research on him and who he works for.
>The reported issue "AVG: "Web TuneUP" extension multiple critical vulnerabilities" is fixed. The issue submitter, investigator, and closer is the same person, Tavis Ormandy.
If you could stop condescending for a minute and pay attention to what I've said, you'll see the issue is still there. If you aren't convinced, just click http://webtuneup.avg.com/static/dist/app/4.0.5.0/interstitia... : as of the writing of this comment, that produces a javascript alert. Mind explaining how the issue was fixed?
>How could Ormandy investigate and report on a new version of the software before it was uploaded to the Webstore, if AVG never sent it to him to evaluate, and he had to download it from the Web store to investigate it?
It sounded like they did send it to him to evaluate, and it had only fixed the other issues. The XSS on AVG's website isn't something that can be fixed by the extension, it needs the audit, which clearly hasn't completed yet, or the link above wouldn't produce an alert.
Which specific part of the timeline do you differ from me on?
I'm not condescending. I carefully read everything you wrote.
Carefully read Ormandy's report. Notice how the reported issue is:
"This extension adds numerous JavaScript API's to chrome... Anyway, many of the API's are broken, the attached exploit steals cookies from avg.com. It also exposes browsing history and other personal data to the internet, I wouldn't be surprised if it's possible to turn this into arbitrary code execution."
According to Ormandy, that issue is fixed. Or is your claim that he's lying about this and marking it as Resolved-Fixed just to get it off of his plate or something?
Talking about achieving enlightenment sounds condescending, and I wasn't sure how else to interpret it.
>Or is your claim that he's lying about this and marking it as Resolved-Fixed just to get it off of his plate or something?
The issue in 1 is fixed. The last issue in 5 is not.
You can clearly look at the given link and see the issue is not resolved. Perhaps he didn't consider the XSS part of the core issue, only being mentioned in comment 5. Or maybe his anger at AVG clouded his judgement? I really shouldn't be trying to figure out why, it's sufficient to point out the what.
> Talking about achieving enlightenment sounds condescending...
I guess you're not one for Zen koans and The Codeless Code, eh? Guess I'm getting old.
> Or maybe his anger at AVG clouded his judgement?
Ormandy's no hack. That didn't happen.
> The last issue in 5 is not. You can clearly look at the given link and see the issue is not resolved.
You can clearly look at the bug report and see that Mr. Ormandy thinks that the issue he reported is resolved. I don't know what you do for a living, but Ormandy does security research for a living. Have you looked into his credentials, reputation, and employer yet? :)
Like I said, I don't want to speculate on why he published it.
>You can clearly look at the bug report and see that Mr. Ormandy thinks that the issue he reported is resolved. I don't know what you do for a living, but Ormandy does security research for a living. Have you looked into his credentials, reputation, and employer yet? :)
I'm aware this is for Google, and have mentioned that in comments in this thread. I'm not sure why I should believe his implication that everything was resolved over "my own lying eyes". Perhaps if he'd said "this XSS is not an issue" without explanation, I'd be happy, but he doesn't even acknowledge the point in what I can see.
Whether the bug report implies everything is resolved: I'm not so sure. Maybe he considers it resolved because every issue in the original was fixed, and AVG didn't acknowledge the last issue? I have no idea, and he hasn't given enough information for me to have an idea.
I'd sooner believe that something's wrong with the closing of the bug report than something's wrong with my understanding of how this is still a bug. Note that nobody yet has given me any explanation of how it might not be a bug, and HN is probably full of people who could explain it if it was the case.
> I'd sooner believe that something's wrong with the closing of the bug report than something's wrong with my understanding of how this is still a bug.
Your credentials and ability in the field have not been established despite enquiries by many folks in this sub-thread. At the moment, I'm far more likely to believe that Mr. Ormandy has a far better understanding of the security issues with the AVG Chrome extension and their implications than you do.
> Perhaps if he'd said "this XSS is not an issue" without explanation, I'd be happy...
He marked the bug as Resolved-Fixed and removed the disclosure embargo. I don't know what more you want.
> Note that nobody yet has given me any explanation of how it might not be a bug...
tptacek and many others gave you a couple of really coherent replies in the subthread attached to your initial comment. None of them provide you with the answer you're looking for, but -frankly- you haven't demonstrated that you understand why it's reasonable the embargo on a security bug for a Chrome extension that AVG has made publicly available in the Chrome Webstore and that its security researcher (and -I suppose- AVG) feels fixes his reported problem was removed. :)
Maybe it'd help to know that the extension is currently not available pending an investigation into whether or not it violates any Webstore policies.
I clicked on the extension link earlier and it was still available in the webstore for installation. If they pulled it, I may have had a different opinion.
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.
>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.
> 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?
>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?
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.
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.
>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.
> 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.)
>...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.
