AVG: “Web TuneUP” extension multiple critical vulnerabilities | Hacker News Reader

AVG: “Web TuneUP” extension multiple critical vulnerabilities

code.google.com

246 pointspfg109 comments

So:

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

It seems like whenever someone checks antivirus software for exploits (Black Hat in 2008, Google Project Zero 2015), they find them in droves.

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.

I had a recent conversation with a McAfee engineer regarding the use of MD5 in the whitelisting system. If it has "seen" an executable before, it assumes it clean and doesn't scan it, based on a hash.

He absolutely promised me that:

    * No stronger hash exists
    * MD5 collisions are literally impossible

I pointed him to a paper his own research department released, referring to the Flame malware utilising an MD5 collision, and he informed me he had previously looked at it, and it was a "typo" that he would get fixed.

This is a senior developer responsible for many of the design decisions in the product. It's frightening.

This is I think exactly correct.

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.

That's one way to see it. I usually don't think about security in terms of individual programmers' capabilities but more what the company behind them wants to accomplish. Security should be a process. Compare the code coming out of Microsoft in 2000 with 2010 -- still not great perhaps, but what a difference a change in objective can make.

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.

It's almost hard for me to accept them as a "security vendor" at this point. I've requested information from them on a virus definition that was flagged on a PC, as an enterprise customer with a service contract, and they were unable to tell me ANYTHING about the virus definition in question. Not even when they added it to their detection library.

I have yet to cease to be amazed by AVG's lack of knowledge about their own product.

They are basically malware. They take over your browser and search bar, obviously diverting all search queries to them first, so they can have a nice little index to sell.

AVG is not a security vendor - they are a malware company disguised as a security vendor. They're just like all the other browser highjacking bullshit companies like Perion. Look at AVG's logo and how similar it is to Windows'...the whole thing is designed to confuse people.

I've also seen them directly involved in affiliate toolbar installers and hosting "safe site"-style badges for sites that are pushing scamware/malware. Agree that AVG is not a security vendor.

Google is being far too lenient with them. The extension should be blacklisted.

Since "the installation process is quite complicated so that they can bypass the chrome malware checks" (second paragraph), it probably can bypass blacklisting checks too.

The fact that the blacklist checks can be bypassed is troubling in and of itself; the fact that a security company would knowingly do so is even more troublesome. I just finished removing AVG from my mother's laptop yesterday, it's not very often you get a choice validated so quickly.

As Raymond Chen would say, the code is on the same side of the "airtight hatchway". There's nothing Chrome can do to protect itself against processes at the same privilege level, much less against processes at higher privilege levels. Any blacklist check Chrome does can be nothing more than a speed bump.

That makes sense, thank you for the explanation. That said, I suppose I'm still disappointed that a security vendor would manipulate extension installation to bypass checks on a platform, but I'm not particularly surprised that it's the kind of thing AVG would do.

Also, you probably don't want them to. I've got a huge problem with software that goes out of its way to prevent the user from doing something they explicitly want to do.

How is code supposed to determine user intent? The AVG developers would no doubt say the user intended to install their software and didn't want to have to learn all of the details, just like every other malware / adware vendor claims; the Chrome developers would say that users want to be secure but if you ask, millions of people will be insecure because they made a mistake or were encouraged to believe something was safer than it actually is.

There simply isn't a simple solution to this problem.

Chrome already blocks extensions not from the webstore on Windows, unless you use a developer branch. See http://chrome.blogspot.com/2014/05/protecting-chrome-users-f...

> I've got a huge problem with software that goes out of its way to prevent the user from doing something they explicitly want to do.

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.

Yes. Yes I do. I wasn't aware that wanting complete control of my devices was somehow a controversial stance around here.

it's not evident there's a lot of user intent here; almost certainly the user doesn't intend to break web security.

Are you saying that it's impossible for Windows apps to provide a level of executable trust for "normal" applications? If Chrome (or any other app) can't protect its cert/trust store from external abuse, why should anyone ever trust any web browser?

Do not confuse security vendors with snake oil vendors.

Which companies, if any, in the anti-virus business would you not consider as "snake oil vendors"?

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.

Honestly, for some time the security software from MS has been "good enough" for most people. Then again, there's plenty of people that will click "OK" to just about anything that pops up... which is why when one of my grandmother's PCs finally died, I bought her a chromebook... best option for those not technically inclined.

None.

grsecurity (Well, Open Source Security, Inc.) is a good example of an actual security vendor.

Microsoft

Microsoft has by far the best AV product (from a code quality aspect, at the very least), but I'm not sure if it qualifies as a vendor in this context. After all, MSE is essentially free.

Its almost 2016, any Antivirus Software is snake oil at this point. Bypassing _every single product on the market_ is trivial, few nops here, powershell script there and you are in.

https://www.youtube.com/watch?v=8Z7L498dNB0 https://www.youtube.com/watch?v=DzC8jJ0ESJ0

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?!?:)

Why is Google publishing this before the XSS has been fixed? Shouldn't they wait for further response from AVG?

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?

Regardless of policy it was the right thing to do.

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.

http://blog.chromium.org/2015/08/protecting-users-from-decep...

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.

Out of the following two outcomes:

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.

Um, I'm not considering it settled.

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.

I think you should take this to @thegrugq on Twitter. He's like Judge Wapner for stuff like this. He'll know what to do.

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.

If you check the linked page, you'll see that it has been fixed and only then the bug was opened to the public

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.

And loading http://webtuneup.avg.com/static/dist/app/4.0.5.0/interstitia... still shows an alert, the issue has not been fixed.

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.

Scroll down. Read.

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.

https://code.google.com/p/google-security-research/issues/de...

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 XSS is not fixed.

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?

> If you could stop condescending for a minute...

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? :)

>Ormandy's no hack. That didn't happen.

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.

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

>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?

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

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

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

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

> 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

Occam's razor plays against you.

If I have a windows machine or VM, I simply don't run anti-virus. There's no point. At Kiwicon last year, some French researcher showed how most anti-virus scanners were so badly written, he could exploit their scanning engines with basic malformed PDFs and JPEGs. Most of those scanners run as the SYSTEM user, so you basically can control a system with a PDF.

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

I generally try to get whatever anti-virus/malware Microsoft is offering, if not already bundled. There are way less perverse incentives at play, and if I'm running windows and worried about MS having extra info about what I'm doing... well, that boat has sailed. Anything I truly want separated from my identity (browsing wise), I use a VirtualBox instance running Linux. Even then I'm sure it's associated with my identity through IP address alone, but at least it may be seen as someone else at the same location if I'm lucky.

> There are way less perverse incentives at play

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.

Can you explain this? Why would Microsoft have less incentives to make a good AV for their OS?

It's not their business, it doesn't make them money. They don't need to be competitive. They do what they need to do to protect their users (from clogging their hotline). I don't mean to say they do poor AV on purpose (or that it's poor in the first place). 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.

> It's not their business, it doesn't make them money.

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.

I do the same. Downvoters please explain.

If you're using virtualbox anyway, why not use whonix or a livecd of tails?

Why would I use a livecd over a VirtualBox instance? Wouldn't that require me to restart?

I mean booting the iso livecd in virtualbox.

Ah. First, since I just said I run Linux in the instance, what would make you think I'm not doing that, and second, because I'm not doing that ;), it's because there's multiple purposes to having that VirtualBox Linux instance. For example, it came in handy when testing out obscure (or not) systemd features, such as how to boot into read-only root[1] without using a production system for testing when a bunch of people complain that it's a pain and a shortcoming of systemd.

1: https://news.ycombinator.com/item?id=10213608

Not to mention other AV vendors probably already do the same thing.

with Windows 10, the OS itself is spyware

Also, "don't be stupid about what you install". Even intelligent programmers fall for this. Yes, I know the app says it will download files faster for you, no that doesn't make sense, don't install it.

Actually, opening a bunch of connections in parallel can and will improve your download speed on some sites, if there's per-connection rate limiting.

http://www.downthemall.net/howto/faq/#faq7

'Some' sites also includes S3 downloads -- https://github.com/htcat/htcat

I don't run antivirus either. And I haven't had a problem. But most people work with computers.. differently. I honestly think an antivirus is a must for most.

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.

> most anti-virus scanners were so badly written, he could exploit their scanning engines with basic malformed PDFs and JPEGs

Isn't there still a point in running anti-virus because a "regular" virus is far more likely than an "anti-virus virus"?

I would imagine that, if this starts becoming common knowledge, "regular" viruses will happily start exploiting the hell of this free elevator to SYSTEM privilege, as part of many other tools those malwares unfortunately have at their disposal.

The "anti-virus virus" could very well become the painfully ironic norm.

this one? http://joxeankoret.com/download/breaking_av_software_44con.p...

Yep, that's the one

Something called "Web TuneUP" just screams crapware. It sounds like one of those browser toolbar things advertised via flashing banner ads that hijack your browser.

A company that bundles something like that is no longer credible as a security vendor.

AVG's CEO, Gary Kovacs, was formerly CEO of Mozilla. There must be a strong cognitive dissonance field surrounding AVQ's corporate headquarters to publish this level of "security" software.

I wonder if anyone at Mozilla have a current contact.

I remember using AVG many years ago when it was a decent product. I recently had the displeasure to have to install it again. AVG Free right now is malware, plain and simple. It highjacks your home page in every browser, changes your search page, and silently installs an extension. And if you go and switch the home page back, it shows you a popup asking you to set it back to AVG. This is pure malware behavior.

Can a class action lawsuit be started to deal with this sort of criminal incompetence?

I'm primarily a Windows user on the desktop/laptop side (though I do also use a lot of Linux/Unix/embedded systems) and my advice to everyone who asks (as the token 'IT advice guy' to lots of friends and family) is just don't install anti-virus software. Modern Windows is better off without it. As far back as XP the best option was to install Microsoft's own Windows Defender and uninstall everything else, now just use what the OS already comes with.

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.

At one point it looked like Microsoft was going to kill the scammy Windows "security" industry by releasing their own anti-virus. But then they backed-off and now MSE seems to be purposefully curtailed.

MSE was absorbed into Windows Defender in Windows 8 & 10. I don't recall any publicity from Microsoft telling their users this - I only know because I did google searches on how to install MSE on Win8 which turned up the answer that its already in there, just renamed.

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.

Ref: https://en.wikipedia.org/wiki/Windows_Defender

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.

I long stopped using AVG because their business model seemed to transition to largely something predatory - browser bars, hijacked home pages, "tune-ups".

Who the fuck would get something called Web TuneUP?

Reply on news.ycombinator.com