If I had to guess: because at this point it's obvious that they have no idea what they're doing and will struggle to not just fix it, but maintain the level of quality needed to keep it that way.
Then tell AVG that. I've seen plenty of bugs where the original fix didn't fix everything, and the reporter explains why, and then they wait for another response. Here they didn't even keep the 90-day deadline.
> I've seen plenty of bugs where the original fix didn't fix everything
You're right, but plenty of bugs aren't for a browser extension that is supposed to enhance the user's security when browsing the internet. The initial fix appeared to show a complete lack of understanding of basic web security.
If you and an intelligent coworker have an agreement to review each other's code on commit, and that coworker responds to a valid complaint about what they've written with something that's probably lifted off of the first StackOverflow post they searched for that addresses the literal value of the complaint without actually solving the problem, you'd probably be a bit peeved that they're not doing their job. Here, the Chrome developers are just showing frustration at AVG's apparent lack of basic skill.
Frustration is fine. I'd even be fine if they banned AVG. But revealing a 0-day publicly without giving time to respond is worse, and is also not in line with Google's policies as I understand.
Many security bugs are for things that one might think are basic after hearing about them, and that shouldn't make it right to 0-day them.
edit: why would revealing a vulnerability to the world before it's been fixed be the right response to incompetence on the part of the vendor?
Do you think 0-days should be reported as soon as they're found if the vendor is incompetent? If yes, what's the argument, if not, why is this different?
When you find critical vulnerabilities in popular antivirus software, you can establish a 90 day publishing schedule, or a requirement not to publish until all related vulnerabilities are fixed, or whatever other policy you deem sensible.
Tavis Ormandy is one of the best known vulnerability researchers in the world; whatever publishing decision he and his team made, I think they probably put more thought into it than any combination of the comments on this HN thread did.
It sounds like you're saying he's above criticism for some reason related to fame? That doesn't make sense to me.
If there are details I don't know about that explain it, fine (but it doesn't look like that from what I do see) but arguments over ethics shouldn't be won by appealing to authority.
I might place more stock in your point here if he'd actually given a reason and acknowledge that he's opening up users to exploits, and say it's worth it because of X. As is it doesn't look thought out at all.
I'm suggesting that the implication you're generating all over this thread that (a) there are hard-and-fast rules for disclosure and (b) Tavis Ormandy has somehow broken them is probably built on something other than firsthand knowledge of how vulnerability research works --- to say nothing of firsthand knowledge of how this particular vulnerability was handled.
Google does have a policy not to release within 90 days unless a patch is released, and this does seem to be pointing out a vulnerability that hasn't been patched. What am I getting wrong? Am I misunderstanding something?
Separately, even if they had no such policy or it was an independent researcher, I don't think discussing the ethics of disclosure should be off bounds by someone not directly involved.
If the vendor is incompetent and the bug is being actively exploited, then it's reasonable to violate the 90-day policy, which is designed in the spirit of cooperation with competent vendors.
6 months ago they decided to limit inline installations [1] and they probably started reviewing poorly-rated add-ons like this one at that time.
There's no indication that the bug was being actively exploited.
Anyway, it's not clear what benefit was had over releasing the report but without the XSS link. Maybe even say "there's XSS on your site" but don't mention the exact link.
Again, they should ban the extension completely if they think it's insecure, and if they haven't done that, they shouldn't be publicizing exploits.
Tavis Ormandy started tweeting at AVG about this subject several months ago.
And it's been pointed out that they aren't able to remove the extension from users' machines due to how it bypasses the Chrome security system. So their best bet was to ask AVG to do the right thing. AVG won't or can't.
So, what can Google do? Just silently accept it? The 90-day policy is worthless in this case.
I went back through his tweets to 2014, searched AVG, and found nothing before Oct, and that wasn't a request for contact, which came in December.
The report is dated from this month.
Re removing it: they can remove it from the webstore. As long as it's in the webstore, they shouldn't be releasing 0-days that haven't been patched yet.
You expended a lot of effort on what could have been easily resolved by asking me. The XSS that you're concerned about was for illustrative purposes only, and could not be used in an attack due to mixed-content errors.
I don't really want to discuss disclosure ethics with you, but will say that our documented policy was followed to the letter.
Yes. 90-day windows are for us, not for companies/projects/teams. They are an acknowledgement that the producer of the software is best suited to patch and get that update to users. If they aren't suited for the task notifying users that they are at risk is the right thing to do.
1. Tell the company, maybe it takes another week to get it fully fixed
2. Tell users, most of whom will never hear about it, while hackers will
The first still seems better. As long as Google isn't pulling the extension and uninstalling it from all chrome users, it seems like disclosure is only hurting most users.
That is a perfectly respectable and intellectually coherent rationale for not disclosing bugs you find prior to the availability of their patches.
However, on the off chance that you are somehow (despite it being 2015) new to the Great Disclosure Debate, you should be aware that there are other respectable and intellectually coherent rationales for other disclosure schedules, and that you are vanishingly unlikely to be the Internet Message Board Commenter That The Prophets Foretold Would Resolve The Disclosure Debate.
So while it's one thing to use this incident to give voice to your own reasoning about how disclosure should be handled, it's another thing entirely to moralize about it --- in this case, repetitively --- with a tone suggesting that the debate has somehow been settled, and you've somehow found out about that before the rest of us.
Your opinions about vulnerability research also get a lot more interesting if you can tell us about your own VR/xdev experience. Because, like it or not, and I know from your comments thus far that you do not like this, if Tavis Ormandy said "new rule: you can disclose 15 seconds after discovery, patch or no patch, so long as you yourself are wearing a pirate eye patch with a large googly eye glued to it", a pretty big swath of the security research community would accept that as The New Rule.
I think that this violates Google's stated policy, or at least would like an explanation of why it doesn't. I think that publicizing against your own policy may be worse than publicizing independently.
Is your only problem my tone? And do you think the point about Google's policy is entirely moot, and if so, why?
Re disclosure debate: In this specific instance it seems like it either would have been fixed relatively soon with an audit, or it would not have been fixed and Google would need to remove it from their store. Given that the person making the choice to publicize also has the power to "patch" it by getting Google to ban the extension, the specific choice they made doesn't make sense to me. Either publicize and leave out the unfixed detail, or ban it, then publicize.
As a chrome user, I have the right to be annoyed that Google would disclose an issue with an extension on their store, without giving enough time to fix it nor banning the extension. That makes it different from other instances of disclosure, and to my mind shifts the balance closer to not disclosing.
Regarding tone: several of my "shoulds" were implicitly "if they follow their own policy, then they should". If that wasn't clear, then my comments may have sounded more confident than warranted, although even that implication still seems like a valid position to take.
Edit: also, my argument that it hurts users is also presuming that full disclosure hurts users, which is what Google believes, which is why they have the 90 day policy.
If they manage to keep XSS vulnerabilities off of the pages on their domain(s) for longer than a year I'll be very surprised.
Personally speaking, I'd rather know. If it's a piece of security software it's reasonable to assume the bad guys are already looking at it or using it.
As far as I can tell, only the first issue was fixed. Is the XSS issue fixed as well? There doesn't seem to be any acknowledgement of a fix on the page after that's mentioned.
Perhaps the employee considers the reported vulnerability in the extension resolved and the XSS issue was just a side note. I'm sure a lawyer could argue that Google is in full compliance with its policies which are probably noted in a EULA and T&C as being subject to the discretion of Google employees.
Ostensibly the 90-day window is to protect everyone, not protect companies. It gives them time to develop and test a patch which is good for all users of the software. It's not to give a company mishandling security more time to be idiots. Especially a security company. Better that users get the information to act on immediately.
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.)
