- Anyone with this extension installed could be trivially owned by any website.
- AVG's initial fix was to incorrectly whitelist their own domains without requiring SSL.
- The follow up fix (after more harsh words from google) whitelists the AVG domain with SSL. Google engineer points out a obvious XSS on the domain that would again allow any chrome user to get owned.
This is a security extension from a security vendor. No words.
Which isn't surprising, since most of the big vendors have very old code bases on which are piled many new parsers every year for documents, archives, whatever can contain code these days. The .doc parser in your antivirus isn't better than, say, the one in Libreoffice.
You should assume that your antivirus scanner is trivially exploitable. When you need to scan incoming files sandbox that scan as tight as you can.
He absolutely promised me that:
* No stronger hash exists
* MD5 collisions are literally impossible
This is a senior developer responsible for many of the design decisions in the product. It's frightening.
It's always funny to see people suggest that security companies should somehow be better at secure code than other companies, as if narrowing the set intersection of possible programmers from "capable programmers" to "capable programmers who can quickly write lots of different file format parsers" somehow makes it easier to find "programmers with an intuitive knack for secure programming".
No. The more specialized your application domain, the harder it usually gets to source programmers who are also incredibly diligent.
Security companies as a general rule have poorer code quality than other companies.
Antivirus programmers are paid to add new parsers. Not to assess the security implications of the software. The result is predictable. Sourcing competent programmers would make zero difference as long as they have no incentives to change their process.
I have yet to cease to be amazed by AVG's lack of knowledge about their own product.
There simply isn't a simple solution to this problem.
I guess you have a huge problem with Windows 7 or later or OS X 10.9 or later, which really go out of their way to prevent you from loading unsigned kernel-space device drivers.
I'm genuinely curious, I haven't had to deal with Windows systems for so long, I'm not well acquainted with AVG and their competitors.
grsecurity (Well, Open Source Security, Inc.) is a good example of an actual security vendor.
I could go as far as calling them fraud for giving false sense of security. Recent case of malware swapping bank account numbers on the fly for example:
ESET fail https://www.youtube.com/watch?v=7MR2PvX3OBY
McAfee fail https://www.youtube.com/watch?v=Go-qqOOE6oY
Trend Micro was also a fail https://www.youtube.com/watch?v=DpS501wRvuo but curiously google removed this clip?!?:)
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.
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?
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.
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.
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.
6 months ago they decided to limit inline installations  and they probably started reviewing poorly-rated add-ons like this one at that time.
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.
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.
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.
I don't really want to discuss disclosure ethics with you, but will say that our documented policy was followed to the letter.
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.
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.
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.
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.
And loading http://webtuneup.avg.com/static/dist/app/22.214.171.124/interstitia... still shows an alert, the issue has not been fixed.
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.
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?
>.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 126.96.36.199 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 188.8.131.52 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.
>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:
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?
>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.
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.
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.
Ah, I was mistaken. Inline installation is blocked, and inline installation is a special process which is described here.  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,  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.
 Because, like, you've not offered up any information regarding your work history and training (formal or otherwise).
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.
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?
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.
> (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.  What's your answer to the question I posed in my previous comment? Feel free to take some time to think through your answer.
 This means that Google can't silently replace the code that their client uploaded with code of their own choosing. 
 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 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.  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.
> 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.
Occam's razor plays against you.
...but I hesitate to tell non-developers to uninstall their anti-virus. I don't want to be responsible for them getting exploited, but I usually do tell them why I don't run anti-virus and that the choice is up to them.
I always emphasize the biggest thing you need to do as far as security goes is to run all updates. Never skip or delay updates. The moment Chrome/FF wants you to restart, you restart them. Run Windows update (even though Windows 10 is another beast/debate entirely, if you chose to run it, you should run updates).
Then again, they have less incentives to make a good AV. And it shows. But it's definitely better than nothing. And it's finally installed and on by default.
They used to think this. They got such bad press for a buggy, exploitable OS that it cost them quite a lot.
> They don't need to be competitive.
The OS needs to be competitive, and I think you're mistaken if you think the AV team at MS doesn't work tightly with the OS team, if they're in fact different.
> They just don't invest that much in it and as a result the protection is on a different level when compared to other major AVs.
At a different level because they don't put a bunch of crap on top of the OS which in most cases is really just a placebo? MS running a traditional AV division would be the height of stupidity. They are the OS vendors. Their fixes should be structural, not scaffolding.
And whatever bullshit people write here, most of the major AVs do work (whether their business model entails installing toolbars or not). And again, unlike belief of many people here, viruses and malware do actually exist. And it really sucks if you somehow end up with a ransomwere and lose everything on your PC.
So, while people who are tech savvy don't need antivirus at all, most of people desperately do. At least the MS one if nothing else.
Isn't there still a point in running anti-virus because a "regular" virus is far more likely than an "anti-virus virus"?
The "anti-virus virus" could very well become the painfully ironic norm.
A company that bundles something like that is no longer credible as a security vendor.
Microsoft's goal with virus elimination is to make Windows work better, 3rd party vendor's goals with virus elimination are to upsell you on a lot of crap you don't need. It isn't difficult to see why the 3rd party stuff is all a bunch of crap that floods you with false positives while bogging your system down in an attempt to seem like it is doing something useful.
Yes, there are occasionally exceptions to the rule, but they all eventually follow a logical progression from useful lightweight tool to bloated piece of shit that is worse than most viruses they could possibly save you from.
In my experience, a lot of people, including IT people who should know, have not gotten the message. There are a lot of people paying a lot of money for crap snake oil when they could have free (arguably better) snake oil.
In Windows 8, functionality has increased to offer antivirus protection as well. Windows Defender in Windows 8 resembles Microsoft Security Essentials and uses the same virus definitions.
* Tavis Ormandy is the researcher doing the reporting. He's currently employed at Google as a security researcher. Given his reputation, and Google's reputation, I trust that his reports are true reports, rather than fiction.
* The report covers a span of ~13 days. It's entirely possible that the AVG commentary that you read was posted on or after 2015-12-21, the date on which Mr. Ormandy mentions that AVG reports that they're going to be pushing the fixed version of the extension into the Chrome Webstore.
* It's also entirely possible that the AVG commentary that you read is either a pack of lies, or -when read very closely- says a _bunch_ of things but ultimately utterly fails to say anything like "The thing reported by Mr. Ormandy in Google Security Research Issue #675 is actually not a problem. Mr. Ormandy's reports are untrue.".