Q&A uBlock, I exfiltrate: exploiting ad blockers with CSS

Gandalf_The_Grey

Level 59
Thread author
Verified
Helper
Top poster
Content Creator
Well-known
Apr 24, 2016
4,861
Ad blockers like uBlock Origin are extremely popular, and typically have access to every page a user visits. Behind the scenes, they're powered by community-provided filter lists - CSS selectors that dictate which elements to block. These lists are not entirely trusted, so they're constrained to prevent malicious rules from stealing user data.

In this post, we'll show you how we were able to bypass these restrictions in uBlock Origin, use a novel CSS-based exploitation technique to extract data from scripts and attributes, and even steal passwords from Microsoft Edge. All vulnerabilities discussed in this post have been reported to uBlock Origin and patched.
Interesting, saw it posted by @plat1098 on Wilders (y)
Wilders post:
Original article:
 

oldschool

Level 66
Verified
Top poster
Well-known
Mar 29, 2018
5,589
I'm increasingly drawn to using only built-in anti-tracking/adblocking for just this reason. My current concession to this is using Privacy Badger, though I don't know whether it suffers the same vulnerability.
 
F

ForgottenSeer 92963

I'm increasingly drawn to using only built-in anti-tracking/adblocking for just this reason. My current concession to this is using Privacy Badger, though I don't know whether it suffers the same vulnerability.

Privacy badger

This extension might have the same vulnerabilities, but that is very unlikely because Privacy badger
  1. Only seems to have two types of rules (blocking requests or cookies only, same two options as Edge Anti-tracking has), it does not seem to have the powerful CSS and CSP rules
  2. Only uses build-in lists (exploitation of uBO weakness was only possible by adding a custom blocklist in which the powerful CSS rules were used)
So I think you should be fine.



Tip for uBlockOrigin users

Only use filters which are maintained by well known trusted parties (e.g. EasyList, AdGuard, Fanboy) or use simple static syntax only (Peter Low, Squidblacklist, Kees1958). On top of this best practise, GorHill suggested a very old solution. Disable cosmetic filtering in settings and enable cosmetic filtering only for the websites you visit often. With this trick you will hit two birds with one stone: not only do you limit the options to misuse powerfull cosmetic filtering (CSS) rules, but you also use less resources (CPU time) by selectively enabling cosmetic filtering.

When you want to play it safe you could also add a disable content security policy injection rule for all websites (in My Filters tab): @@||*$csp
("...exception filter with empty csp option will disable all csp injections for matching page..."). I don't like my adblocker to inject javascript or mess with content security policies. You may call me paranoid, but it does not make sense to add Code Integrity Guard and AppContainer (extra) protections to Edge and on the other hand use an extension which punches a hole in these defenses. I fully understands @oldschool second thoughts on this.
 
Last edited by a moderator:

Jan Willy

Level 7
Verified
Well-known
Jul 5, 2019
338
@Jan Willy Try adding *$font,third-party to My Filters and check on CSS Exfil Vulnerability Tester do the same with *$stylesheet,third-party (check 1 is same origin and check 3 is import same origin, so IMO 1 and 3 are "the northpole and southpole are cold tests" tests because every website uses stylesheets).
Yeah, what I saw on Wilders was too good to be true.
 

oldschool

Level 66
Verified
Top poster
Well-known
Mar 29, 2018
5,589
This extension might have the same vulnerabilities, but that is very unlikely because Privacy badger
  1. Only seems to have two types of rules (blocking requests or cookies only, same two options as Edge Anti-tracking has), it does not seem to have the powerful CSS and CSP rules
  2. Only uses build-in lists (exploitation of uBO weakness was only possible by adding a custom blocklist in which the powerful CSS rules were used)
So I think you should be fine.
I figured #2 was the case since PB disables learning mode by default, with Badger Sett web crawler doing its "learning" work on its own.

Manifest V3 is coming sooner than we think, which has had me reexamining my use of adblockers generally. Strange as it seems, Privacy Badger may be one of the adblockers which makes the transition to Manifest V3 with the least amount of problems but only time will tell.
 

oldschool

Level 66
Verified
Top poster
Well-known
Mar 29, 2018
5,589
I assume that cosmetic handling is out of the question with PB, right?
Indeed, as far as I know. Honestly, I don't see many empty placeholders on sites I visit.
I wonder what Ghostery will do with Mv3 since they use a minimum ruleset and is quite effective without a need for big filterlists.
I'll bet they handle it as well as anyone since it's a promotional vehicle for their paid service.
 
F

ForgottenSeer 92963

@wat0114

Thanks and in addition to Jan Willy's tip, you can stil enable cosmetic filtering for websites you visit a lot.

I also have added two rules in My Filters (which are good security practice rules to add anyway), note that the *## does not triggers uBlock's DOM inspector so this rule is processed even when you have enabled the "ignore generic cosmetic filters" option Filter lists.
Code:
! Remove any Content Security Policies set by filters on all websites (by setting a CSP exception with no values)
@@||*$csp

! Block the use of the much abused EVAL javascript command bij using uBO's no-eval scriptlet on all websites
*##+js(noeval)

I have read a little more about it and my take is that when you stick to ublock's own filterlists in combination with AdGuard's filterlists, you essentially use only closed group maintainer lists, with near zero chance of misuse of abuse.
 
Last edited by a moderator:

wat0114

Level 6
Verified
Well-known
Apr 5, 2021
264
@wat0114

Thanks and in addition to Jan Willy's tip, you can stil enable cosmetic filtering for websites you visit a lot.

In addition I have added two rules in My Filters
Code:
! Remove any Content Security Policies set by filters on all websites (by setting a CSP with no values)
@@||*$csp

! Block the use of eval javascript command bij using uBO's no-eval scriptlet on all websites
*##+js(noeval)

I have read a little more about it and my take is that when you stick to ublock's own filterlists in combination with AdGuard's filterlists, you essentially use only closed group maintainer lists, with near zero chance of misuse of abuse.

Very nice (y)

I've added those filter as well. Thanks again Kees!
 
  • Like
Reactions: ForgottenSeer 92963
F

ForgottenSeer 92963

adguard full fledged software.
;) that is not the solution for this problem

It is not the AdGuard software which will keep safe, but ONLY using AdGuard's filter lists which will keep you safe, because Adguard's filter lists are maintained under the supervision of AdGuard these list are maintained by a closed trusted group. When list are maintained by an open community (like easylist) one of the maintainers could turn bad, he/she could misuse one of the powerful commands (example).

This is one of the reasons (I think) AdGuard uses a slightly different code and parameters for complex rules. AdGuard has an automated import of ABP filters and uBO filters. During the conversion e.g. ##+js(noeval) to #%#//scriptlet('noeval'), AdGuard has an option to check and sanatize (reject) malformed or invalid commands.

This is why I would advise uBO users (when they don't use my blocklist :) ) to only use AdGuard maintained filter lists in uBO. Use the predefined AG filter lists in uBO, but replace Easylist and EasyPrivacy with AG Easylist (optimized) and AG EasyPrivacy (optimized). You can find your AG specific country code filter at AG-website.
 
Last edited by a moderator:

Jan Willy

Level 7
Verified
Well-known
Jul 5, 2019
338
@Kees1958
In your post # 6 you referred to CSS Exfil Vulnerability Tester. This gives the impression that this test can find out the CSS-vulnerability in uBlock('s filterlists). However, for the testresult it makes no difference when I have the cosmetic filtering in uBlock enabled or disabled. So, the test isn't able to discover the CSS-vulnerability in uBlock òr disabling cosmetic filtering isn't enough.
 

SeriousHoax

Level 41
Verified
Top poster
Well-known
Mar 16, 2019
3,086