F
ForgottenSeer 92963
@Jan Willy
This is a test page to promote the author's own extension. The test just fetches and imports first and third-party style sheets with the vulnerability and when the image appears your browser allowed it. So the test-page has nothing to do with the vulnerability Tavis Ormandy (of Google) and Gareth Hayes
Short answer: no it is not enough
Long answer
Imagine a three staged attack. Stage 1 hide code in a adblock filter list. Stage 2 pull in the malicious code which does all the bad things. Stage 3 execute the code. Let me help to explain by quoting parts of the article
Stage 1
To prevent misuse of these powers, the Adblockers put constraints and limitations on what input they accept. Because this is complex, not all combinations and input situations are tested, so a unforseen combination of inputs might slip through the adBlocker's rule sanitizing mechanism.
The most important thing to remember the larger a community sourced blocklist is and more people contribute to this list, the harder it is to test all rules to prevent someone adding rules to find holes in the input check of an dblocker. It is even better when a more closed group of trusted people write the rules like Brave and AdGuard who have their own versions of community sourced lists (Easy List).
This is the rational behind my advice to use blocklist of AdGuard in stead of EasyList (reduce source risk)
Stage 2
An external font file also contains data which can be used import code. There are many ways to import code as shown by this reply of GorHill
Because Gareth used an external fonts file, blocking external fonts helps to close one door. This is the reason why GorHill offers to block fonts in the popup screen. It helps to block third-party fonts, but most websites use third-party fonts, so this also could prevent websites to display stuff correctly. Websites can set with Content Security Policies from which websites third-party content is allowed to be used. Well developed websites use this to reduce the attack surface (only allow stuff from trusted parties to minimize breeches).
This is the rational behind my advice to remove all Content Security Policies set in any filter (with the My Filter rule: @@||*$CSP). It does not make a badly secured website stronger, but it prevents an attacker to change a website's content security policies by sneaking in a CSP modifier in a static filter to make the security of that website weaker.
Stage 3
After malicious code is imported it has to be executed. One of the most abused javascript commands is the EVAL which executes dynamically pulled in code. This is the rational to block eval with *##+js(noeval) rule. This enforcement could potentially break a website, but I would not visit a website which relies on dynamically executing code from other sources.
Sum up
None of the above advices complete rules out misuse of an Adblocker powerful website manipulation capabilities (at least until Manifest V3 is implemented), but they make it harder to craft a staged misuse of errors in the internal 'rules checker' of an adblocker.
This is a test page to promote the author's own extension. The test just fetches and imports first and third-party style sheets with the vulnerability and when the image appears your browser allowed it. So the test-page has nothing to do with the vulnerability Tavis Ormandy (of Google) and Gareth Hayes
Short answer: no it is not enough
Long answer
Imagine a three staged attack. Stage 1 hide code in a adblock filter list. Stage 2 pull in the malicious code which does all the bad things. Stage 3 execute the code. Let me help to explain by quoting parts of the article
Stage 1
Because of the ongoing struggle between advertising publishers and adblockers the advertising links are randomized and obfuscated everywhere in and on a website. To match these advertising tactics Adblockers need to dig deeper into a webpage and offer more powerful means to block advertisements.Gareth Hayes said: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. .....A while ago one of my heroes, Tavis Ormandy mentioned on Twitter that uBlock Origin was vulnerable to CSS injection in their filter rules.
To prevent misuse of these powers, the Adblockers put constraints and limitations on what input they accept. Because this is complex, not all combinations and input situations are tested, so a unforseen combination of inputs might slip through the adBlocker's rule sanitizing mechanism.
The most important thing to remember the larger a community sourced blocklist is and more people contribute to this list, the harder it is to test all rules to prevent someone adding rules to find holes in the input check of an dblocker. It is even better when a more closed group of trusted people write the rules like Brave and AdGuard who have their own versions of community sourced lists (Easy List).
This is the rational behind my advice to use blocklist of AdGuard in stead of EasyList (reduce source risk)
This is the rational behind my advice to disable cosmetic filters system wide and enable it only on the websites you often visit (reduce target risk)Gareth Hayes said:uBlock Origin also has cosmetic filters that allow more powerful CSS selectors they even let you define your own CSS rules but are restricted (limiting the use of URL requests), so I thought this would be a good place to look for another bypass.
Gareth Hayes said:Next Gareth Hayes used an external font to pull code in (stage 2) and create a keylogger. can't show the original text
Stage 2
An external font file also contains data which can be used import code. There are many ways to import code as shown by this reply of GorHill
This is the rational behind my advice to remove all Content Security Policies set in any filter (with the My Filter rule: @@||*$CSP). It does not make a badly secured website stronger, but it prevents an attacker to change a website's content security policies by sneaking in a CSP modifier in a static filter to make the security of that website weaker.
Stage 3
After malicious code is imported it has to be executed. One of the most abused javascript commands is the EVAL which executes dynamically pulled in code. This is the rational to block eval with *##+js(noeval) rule. This enforcement could potentially break a website, but I would not visit a website which relies on dynamically executing code from other sources.
Sum up
None of the above advices complete rules out misuse of an Adblocker powerful website manipulation capabilities (at least until Manifest V3 is implemented), but they make it harder to craft a staged misuse of errors in the internal 'rules checker' of an adblocker.
Last edited by a moderator: