Hacker News new | ask | show | jobs
by nephyrin 3831 days ago
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.

7 comments

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.

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