PSA: jQuery is bad for the security of your project

For some time I thought that jQuery was a thing of the past, only being used in old projects for legacy reasons. I mean, there are now so much better frameworks, why would anyone stick with jQuery and its numerous shortcomings? Then some colleagues told me that they weren’t aware of jQuery’s security downsides. And I recently discovered two big vulnerabilities in antivirus software 1 2 which existed partly due to excessive use of jQuery. So here is your official public service announcement: jQuery is bad for the security of your project.

By that I don’t mean that jQuery is inherently insecure. You can build a secure project on top of jQuery, if you are sufficiently aware of the potential issues and take care. However, the framework doesn’t make it easy. It’s not secure by default, it rather invites programming practices which are insecure. You have to constantly keep that in mind and correct for it. And if don’t pay attention just once you will end up with a security vulnerability.

McAfee WebAdvisor: From XSS in a sandboxed browser extension to administrator privileges

A while back I wrote about a bunch of vulnerabilities in McAfee WebAdvisor, a component of McAfee antivirus products which is also available as a stand-alone application. Part of the fix was adding a bunch of pages to the extension which were previously hosted on, generally a good move. However, when I looked closely I noticed a Cross-Site Scripting (XSS) vulnerability in one of these pages (CVE-2019-3670).

Now an XSS vulnerability in a browser extension is usually very hard to exploit thanks to security mechanisms like Content Security Policy and sandboxing. These mechanisms were intact for McAfee WebAdvisor and I didn’t manage to circumvent them. Yet I still ended up with a proof of concept that demonstrated how attackers could gain local administrator privileges through this vulnerability, something that came as a huge surprise to me as well.

McAfee WebAdvisor shattered like glass

Insights from Avast/Jumpshot data: Pitfalls of data anonymization

There has been a surprising development after my previous article on the topic, Avast having announced that they will terminate Jumpshot and stop selling users’ data. That’s not the end of the story however, with the Czech Office for Personal Data Protection starting an investigation into Avast’s practices. I’m very curious to see whether this investigation will confirm Avast’s claims that they were always fully compliant with the GDPR requirements. For my part, I now got a glimpse of what the Jumpshot data actually looks like. And I learned that I massively overestimated Avast’s success when anonymizing this data.

Conveyor belt putting false noses on avatars in a futile attempt of masking their identity

In reality, the data sold by Jumpshot contained plenty of user identifiers, names, email addresses, even home addresses. That’s partly due to Avast being incapable or unwilling to remove user-specific data as they planned to. Many issues are generic however and almost impossible to avoid. This once again underlines the central takeaway: anonymizing browser history data is very hard. That’s especially the case if you plan to sell it to advertisers. You can make data completely anonymous, but you will have to dumb it down so much in the process that advertisers won’t have any use for it any more.

Why did I decide to document Avast’s failure in so much detail? My goal is to spread appreciation for the task of data anonymization: it’s very hard to ensure that no conclusions about users’ identity are possible. So maybe whoever is toying with the idea of collecting anonymized data will better think twice whether they really want do go there. And maybe next time we see a vendor collecting data we’ll ask the right questions about how they ensure it’s a “completely anonymous” process.

Avast’s broken data anonymization approach

Avast used to collect the browsing history of their users without informing them and turn this data into profits via their Jumpshot subsidiary. After a public outcry and considerable pressure from browser vendors they decided to change their practices, so that only data of free antivirus users would be collected and only if these explicitly opt in. Throughout the entire debacle Avast maintained that the privacy impact wasn’t so wild because the data is “de-identified and aggregated,” so that Jumpshot clients never get to see personally identifiable information (PII).

Conveyor belt putting false noses on avatars in a futile attempt of masking their identity
Symbolic image, not the actual Avast De-identification Engine

The controversy around selling user data didn’t come up just now. Back in 2015 AVG (which was acquired by Avast later) changed their privacy policy in a way that allowed them to sell browser history data. At that time Graham Cluley predicted:

But let’s not kid ourselves. Advertisers aren’t interested in data which can’t help them target you. If they really didn’t feel it could help them identify potential customers then the data wouldn’t have any value, and they wouldn’t be interested in paying AVG to access it.

From what I’ve seen now, his statement was spot on and Avast’s data anonymization is nothing but a fig leaf.

Pwning Avast Secure Browser for fun and profit

Avast took an interesting approach when integrating their antivirus product with web browsers. Users are often hard to convince that Avast browser extensions are good for them and should be activated in their browser of choice. So Avast decided to bring out their own browser with the humble name Avast Secure Browser. Their products send a clear message: ditch your current browser and use Avast Secure Browser (or AVG Secure Browser as AVG users know it) which is better in all respects.

Avast Secure Browser is based on Chromium and its most noticeable difference are the numerous built-in browser extensions, usually not even visible in the list of installed extensions (meaning that they cannot be disabled by regular means). Avast Secure Browser has eleven custom extensions, AVG Secure Browser has eight. Now putting eleven extensions of questionable quality into your “secure” browser might not be the best idea. Today we’ll look at the remarkable Video Downloader extension which essentially allowed any website to take over the browser completely (CVE-2019-18893). An additional vulnerability then allowed it to take over your system as well (CVE-2019-18894). The first issue was resolved in Video Downloader 1.5, released at some point in October 2019. The second issue remains unresolved at the time of writing. Update (2020-01-13): Avast notified me that the second issue has been resolved in an update yesterday, I can confirm the application version not being vulnerable any more after an update.

Malicious actors coming through Avast software

Note: I did not finish my investigation of the other extensions which are part of the Avast Secure Browser. Given how deeply this product is compromised on another level, I did not feel that there was a point in making it more secure. In fact, I’m not going to write about the Avast Passwords issues I reported to Avast – nothing special here, yet another password manager that made several of the usual mistakes and put your data at risk.

Avast complies to respect users’ privacy

December last year has been an interesting month in Avast-land. After my investigation into Avast’s data collection practices didn’t attract any attention initially, Mozilla and Opera removed Avast’s browser extensions from their respective add-on stores immediately after I reported them. Google spent two weeks evaluating the issue but eventually did the same. The matter of Avast selling users’ data even attracted attention of high-level politicians.

Avast watching you while browsing the web

Avast’s official communication throughout that month was nothing short of amazing. I found it hard to believe that a company could keep denying any wrongdoing despite all the evidence to the contrary. Avast’s CEO Ondrej Vlcek even gave an interview to the Forbes magazine where he claimed that there was no privacy scandal here. Users clearly disagreed, and so did most journalists. But the company’s stance didn’t change: all the data collected is necessary to protect users, and selling it later without user’s agreement is completely unproblematic due to the data being “anonymized.”

So when on December 22nd they finally brought out updated versions of their extensions, I was very curious to see what they changed other than writing a usable privacy policy. The updates have been accepted by all browser vendors and, at the time of writing, all four extensions are available for Firefox and Chrome. The Opera Add-ons site currently lists three extensions, with Avast Online Security still missing.

Let’s say this much up front: the changes are far more extensive and far more convincing than I would have expected. While Chrome and Opera versions appear identical however, there are some additional changes in the Firefox version. That’s presumably to comply with stricter privacy requirements of the Mozilla Add-ons site.

Update (2020-01-10): Avast contacted me to clarify the situation. One piece of information stood out here: “we completely discontinued the practice of using any data from the browser extensions for any other purpose than the core security engine.” In other words, Avast isn’t merely doing the bare minimum required to comply with store policies, they completely give up collecting too much data via their browser extensions and they won’t share this data with anybody either. That’s a massive privacy improvement for any Avast users out there. The open question is whether this policy change also applies to the Avast SafePrice extension and Avast Secure Browser. I’ll update the post again once I have the answer. Update (2020-01-16): The quoted statement from Avast seemed unambiguous, yet further communication established that sharing data with Jumpshot is going to be opt-in functionality for users of the free antivirus application. It’s still an improvement of course but quite different from the initial statement. As to Avast SafePrice and Avast Secure Browser, improvements are expected here in future. Supposedly, the data collected by these was never used, a statement that is impossible to validate.

Just to be clear: with the large codebases and without any official information from Avast I might have overlooked some of the changes. On Firefox I looked at Avast Online Security 19.4.426, on Chrome at Avast Online Security 19.4.433 and on Opera at AVG Online Security 19.4.433.

Problematic monetization in security products, Avira edition

A while back we’ve seen how Avast monetizes their users. Today we have a much smaller fish to fry, largely because the Avira’s extensions in question aren’t installed by default and require explicit user action for the additional “protection.” So these have far fewer users, currently 400 thousands on Firefox and slightly above a million on Chrome according to official add-on store numbers. It doesn’t make their functionality any less problematic however.

That’s especially the case for Avira Browser Safety extension that Avira offers for Firefox and Opera. While the vendor’s homepage lists “Find the best deals on items you’re shopping for” as last feature in the list, the extension description in the add-on stores “forgets” to mention this monetization strategy. I’m not sure why the identical Chrome extension is called “Avira Safe Shopping” but at least here the users get some transparency.

Avira user interface offering Browser Safety extension as protection feature

Mozilla and Opera remove Avast extensions from their add-on stores, what will Google do?

A month ago I wrote about Avast browser extensions being essentially spyware. While this article only names Avast Online Security and AVG Online Security extensions, the browser extensions Avast SafePrice and AVG SafePrice show the same behavior: they upload detailed browsing profiles of their users to The amount of data collected here exceeds by far what would be considered necessary or appropriate even for the security extensions, for the shopping helpers this functionality isn’t justifiable at all.

Avast watching you while browsing the web

After I published my article I got the hint to look at Jumpshot, a company acquired by Avast in 2013. And indeed, that suddenly made perfect sense. On their website, Jumpshot praises its “clickstream data” product:

Rendering McAfee web protection ineffective

Now that I’m done with Kaspersky, it’s time to look at some other antivirus software. Our guest today is McAfee Total Protection 16.0. Let’s say this up front: it’s nowhere near the mess we’ve seen with Kaspersky. It doesn’t break up your encrypted connections, and the web protection component is limited to the McAfee WebAdvisor browser extension. So the attack surface is quite manageable here. The extension also uses native messaging to communicate with the application, so we won’t see websites taking over this communication channel.

Of course, browser extensions claiming to protect you from online threats have some rather big shoes to fill. They have to be better than the browser’s built-in malware and phishing protection, not an easy task. In fact, McAfee WebAdvisor “blocks” malicious websites after they already started loading, this being not quite optimal but rather typical for this kind of extension. I also found three issues in the way McAfee WebAdvisor 6.0 was implemented which made its protection far less reliable than it should be.

Rusty WebAdvisor shield

More Kaspersky vulnerabilities: uninstalling extensions, user tracking, predictable links

I’m discuss three more vulnerabilities in Kaspersky software such as Kaspersky Internet Security 2019 here, all exploitable by arbitrary websites. These allowed websites to uninstall browser extensions, track users across Private Browsing session or even different browsers and control some functionality of Kaspersky software. As of Patch F for 2020 products family and Patch I for 2019 products family all of these issues should be resolved.

Kaspersky functionality shattered

Note: This is the high-level overview. If you want all the technical details you can find them here. There are also older articles on Kaspersky vulnerabilities: Internal Kaspersky API exposed to websites and Kaspersky in the Middle - what could possibly go wrong?