uBlock, I exfiltrate: exploiting ad blockers with CSS | Hacker News Reader

uBlock, I exfiltrate: exploiting ad blockers with CSS

portswigger.net

270 pointstodsacerdoti99 comments

Although not having an easy path for security researchers to report vulnerabilities is not exactly great, what is commendable here is the speed at which these were addressed.

>2021-11-03 11:51 - I reported my bypass to uBlock Origin

>2021-11-03 12:52 - uBlock Origin patched my bypass on master

>2021-11-08 13:25 - Reported bug in cosmetic filter

>2021-11-08 14:19 - uBlock Origin patched my cosmetic bypass

>2021-11-08 15:35 - I bypassed the patch without using comments

>2021-11-08 16:18 - uBlock Origin patched the cosmetic filter bypass

61 minutes, 54 minutes, 43 minutes. Pretty quick!

Can we put these people in charge of Windows Update?

No i don't want every 2 minutes a reboot update ;)

That's super impressive imo, and exactly what I would hope to see on a security product

Let's take a moment to thank gorhill for his work!

Thank you!

I have a long list of "thank you"s for gorhill. This guy is responsible for keeping me mentally sane in today's web.

Just remain on the human side

Yes you can objectively say that ublock origin is a very active project.

> This works because document.querySelector tolerates malformed selectors

Of course it does. Is there a single web API that doesn't intentionally enable exploit smuggling by allowing malformed input?

That’s a pretty big leap to malice you just made there.

Don't think poster meant the APIs were designed to maliciously allow exploits. He meant they were intentionally developed to allow rotten code to work (because, sadly, rotten code is everywhere), and a by-product of that lax attitude unintentionally allows exploits.

“intentionally enable exploit smuggling” seemed pretty clear to me, but happy to be wrong

It may not be malice, but it is a design decision often made for robustness or future proofing that seems to backfire every time it ends up in a security critical context.

I personally blame the robustness principle[1], which I think explains a lot of the accidental complexity in web programming.

[1] https://en.m.wikipedia.org/wiki/Robustness_principle

https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai...

Over the years I've switched my philosophy to "be paranoid about what you accept, normalize inputs, randomize outputs, and fail loud and on purpose."

Make it so that if the caller/client works at all then it must work correctly. Force them to handle errors and retry on things that might fail, values that might change, and if the result is something that must be parsed send it back in varying formats so they have to parse it.

I understand the benefit of randomize output, but that's very costly.

Agreed. That’s why I liked XHTML when it came out – it’s hard to believe that’s more than two decades ago! While HTML5 had lots of goodies, I liked the rigour that XHTML imposed on web authors.

In theory XHTML was nice as it allowed easier parsing of pages, but in practice it was doomed to fail from the moment a single bracket off made entire sites to stop working. That W3C put their hands in their ears going all lalalalala while ignoring how the world actually used HTML is what led to their irrelevance in defining HTML and essentially giving control to Google, et al.

IMO the "robustness principle" is a good thing because it realizes that people make mistakes and their goal isn't to make something correct but something that produces the results they want to see. Even if browsers started with XHTML-like strictness with no alternative, that strictness would quickly have eroded during the first browser wars.

And after all these years, those people surrendered and started to stick to mandatory closing tags when React was introduced, proving XHTML was right. How amusing.

Yes, because everybody has willingly surrendered to the horrors of React hegemony

> And after all these years, those people surrendered and started to stick to mandatory closing tags when React was introduced, proving XHTML was right.

I would argue HTML has been way more successful than React and thus XHTML hasn't been proven right.

JSX requires a build though, it's easier to enforce syntax when a missing character will just work while writing it. There are no JSX errors at runtime for this reason.

> but in practice it was doomed to fail from the moment a single bracket off made entire sites to stop working.

Maybe the solution was to not publish sites that are a bracket off.

I think half the problems with JavaScript are because of its weak typing. 1 + {} should be a type error.

No, half the problems with JavaScript are because people refuse to learn it. Just don't write 1+{}. Every time people start bashing JavaScript, it's with these odd-ball examples that they make up.

And this is how add_two_numbers becomes embedded in the node_modules of 73,000 projects on GitHub.

It's okay if JS has warts, but denying they exist doesn't help anyone.

If JS just had stuck to LISP like syntax it'd be quite a bit more usable IMO.

Delete a semicolon from a C/C++/Java/C# program, and it won’t compile.

Delete a byte from a zip file, and it won’t unzip.

I don’t see why HTML should be different…

Yeah I don’t see how that is supposed to be a benefit?

Why _shouldn’t_ people have to make actually-valid-html? We don’t tolerate “only sort of correct JSON” tightening the acceptable requirements for valid HTML and CSS would likely make using those formats in more places _easier_.

Compiling is something that happens locally and is static - it either compiles now or it doesn't and once you have the final executable you can distribute to your users the syntactical errors or whatever of your source code doesn't matter after that.

HTML is different because it is parsed by the browser the end user is using when it is using it. If a site completely broke like, f.e. how Mozilla treated bad XHTML sites (instead of showing the site itself you'd get some yellow page with the error) when you got a tiny syntax error then anything with user generated content (forums, blogs, etc) or even just generated could be a potential minefield. Especially as websites started adding code from external sources (be it for ads or for things like youtube embeds or whatever).

That's basically mantra of one of the most popular technologies of the past - php. And javascript to a degree.

> Do anything, even the wrong thing, just work.

On Error Resume Next

It's so bad that this ever existed.

It's even worse than PHP and JS were built around it.

Errors should never pass silently unless explicitly silenced.

Why? Very little on the web is critical. If it mostly renders, it's mostly good enough. shrug It's not like the big vendors with fancy programmers and difficult types release without bugs and security issues. But so what? Life goes on.

> unless explicitly silenced.

Which is what "On Error Resume Next" was doing by overwriting the current error handler. Seems to me that it was simply overused. Implicitly ignoring errors is more a C thing.

I suppose you're technically right. It's just the worst way to do it.

IMO, if someone is trying to use an API in a malformed way, they just should get a message back saying it is malformed. Possibly with potential causes. I prefer endpoints to shout at me, rather than accepting it and trying their best.

Was this also tested against the CSS Exfil Protection addon? [1][2]

[1] - https://www.mike-gualtieri.com/css-exfil-vulnerability-teste...

[2] - https://addons.mozilla.org/en-US/firefox/addon/css-exfil-pro...

Not trying to be snide or make an accusation at all, but how is anyone supposed to know if this is actual protection or is a socially engineered exploit itself? When you go to the Firefox addon page it has a warning saying that Mozilla does not monitor it and that you should trust it yourself before using it.

Mozilla added that warning for all add-ons unless developers pay to have theirs recommended and further vetted. IIRC Mozilla still does some sanity checks and validation for all uploads.

This is essentially the same problem seen with various antivirus software implementations: uBlock helps prevent malicious ads from running, but (by nature) has access to run on just about any site and itself has to handle potentially malicious code. So it's a tempting target for attack, just like AV software is a tempting target for attack.

Funny that I had not considered this particular attack vector before. Not only do you have to trust an extension to not be malware, you also have to trust that a good extension itself is not being exploited.

I'm not sure I follow how this is useful. How does the CSS injection send that information back to anyone to make this useful? The most likely scenario is the font loading that they mention but that doesn't actually give the bad actor any useful information except for the characters used (without the order or number of times they're used) and potentially the site they're being entered on.

This might work for very basic info/passwords but seems mostly useless unless someone has a way of then brute-forcing that information.

I feel like there has to be something I'm missing here...

> that doesn't actually give the bad actor any useful information except for the characters used (without the order or number of times they're used)

Keep reading until the part where they use first-line to filter which part of the text to apply the font to and CSS animations to vary how long that first line is.

And the animation part to steal dupes. This guy is insane. I'm scared of everything now. If I was the author of Ublock Origin I probably would have just thrown up my hands and switched to pottery.

Raymond Hill (author of uBlock Origin) is doing a fantastic work at the addon on both technical level and the politics, which an AdBlock addon tends to get bashed at often.

Even the smartest of us make mistakes. The right thing to do is fix, learn, and move on.

The author of the addon triaged and fixed it in just five days, which is super impressive.

I did. That still only tells you the first time those characters are used forwards and backwards. It's unhelpful for email addresses where the likelihood of repeated characters goes up a lot and for any passwords where there are multiples of the same character.

It's still a security issue but it doesn't seem like one that would be very practical.

Let's say your password is Refridg3r@t0r. How hard is it to guess that password if you are given the strings Refridg3@t0, r0t@3gdifeR? What about f.lastname@gmail.com => f.lastnme@gico, moc.liag@entsf? You try a handful of possible combinations using this knowledge, and if they don't work, you move on to the next target. Personally, some of my credentials would be very, very easy to guess given this information.

That would be an easier target because it's a dictionary word and it's a single word. But what if your password is 'dogeatdogworld'? What if your password is 'x8GiuG08geejXx'?

It just seems like it would only be useful for the most insecure username/password combos. Again, I'm not saying that it's not a security breach, but the usefulness seems limited unless someone is willing to try and brute force things for an unknown gain.

I think it's fair to say that most laypeople's passwords are not particularly secure, but it's still not feasible to brute-force them unless you can conduct an offline attack. I think this makes an online attack much more feasible on an insecure (read, most) password.

Look at every time a huge password list leaks. I had access to a several million entry user table at the company I worked at in the early 2000s and the #1 pass was "trustno1" and the #2 was "12345678".

Looking back, I have no idea why we stored the passwords in plaintext and I assume it stayed that way until the code was phased out in 2009. This app was used by some of the largest corps in the world, including Microsoft, and was live on the web.

Did anyone go through the existing lists to see if someone had already been using this vulnerability? Didn't see anything about this in the write up... seems like it should be a part of responsible disclosure.

Interesting - the attack relies on a compromised rule list, but that doesn't seem super hard. I have no idea what goes into building one of those, where they're sourced from, etc.

You can select which "lists" you want to subscribe to when setting up the extension. One of the popular ones would be EasyList: https://github.com/easylist

Compromising one of these would be as "simple" as getting a PR merged that wasn't reviewed carefully.

> Compromising one of these would be as "simple" as getting a PR merged that wasn't reviewed carefully.

I think it's less scary than this. A hypothetical PR would have to contain all the keylogger rules. The person who approves the PR would have to be in cahoots. I hope the filter-list repository owners have 2FA turned on...

> The person who approves the PR would have to be in cahoots.

Not really unfortunately:

https://www.theverge.com/2021/4/30/22410164/linux-kernel-uni...

I wouldn't be surprised if, given the volume of new domains to be blocked (like for a malware list), there's some automation involved. And since malicious domains can be absolutely nutty it seems particularly hard to manually review for an attack like this.

Ultimately I suspect that getting fuzzing integrated, lots of testing, etc, would be wise. It would also make sense to limit the lists you subscribe to - there's not really a ton of reason, in my opinion, to subscribe to more than a basic list.

I wonder if a strict CSP employed by individual web sites could prevent it? There really shouldn't be any excuses to not use a CSP rule to allow-list origins for fonts, for example.

I had used uBlock Origin since 2016, but I switched to Adguard last year, when I had problem with YouTube ads on Chrome. There is no problem until now.

weird, I haven't ever had a problem with youtube, nor seen a youtube ad while using uBlock for years.

But somehow I've completely boogered up imgur, I just use a different browser for that site because I can't figure out which of my various blockers broke it.

Imgur has been broken for me lately, too. I suspect it's my pi hole, since it's effecting all of my devices.

On Chrome/Chromium I can routinely expose myself to youtube ads if I have a video open, close the browser, and re-open with that tab loaded first. I figured it was some conflict in initialization of extensions and the page, but good to know a different extension might not have the problem. Firefox doesn't, which I use for everything but youtube livestreams anyway.

It's a known issue

https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

1.32.4 is the last "legacy" version of ublock

is it vulnerable to this as it won't likely get an update?

I don't mind seeing ads, in some way I even want it so I can support whoever supply whatever content I am consuming. What I don't like is the tracking of everything I do. What is the best extension to block the tracking but not the ads?

Web security is completely broken. We have super complex web browsers (written in unsafe languages such as C++) that we try to secure by installing 'add-ons' and those have vulnerabilities that can steal our data.

Who thinks this is a good idea for online banking?

That's why banks are responsible for the fraud risk, not the customer. It's pretty much the only way this can work. It's also why something like bitcoins will never replace traditional banking. Because people make mistakes or have their stuff stolen due to no fault of their own and they would have no recourse.

That's right, as interesting as crypto currency may be it doesn't solve the customer fuck up problem in a way that the masses would tolerate.

Couldn't insurance cover that gap?

Sure, who is going to provide that? FDIC is a government backed insurance. I imagine there is little to replace government backed insurance with a private equivalent. If there is it would surprise me but even if this were to happen but is the benefit over a non-crypto currency?

This is exactly my thoughts on crypto as well. Being unable to fix a "whoopsy" is the biggest weakness. Humans make mistakes, and computers make mistakes. When it comes to money, you need to be able to apply common sense and be able to reverse those mistakes.

Crypto seems too absolutist for this use case. (Although I should mention that they seem to discuss rolling back the blockchain whenever a big heist takes place. But if you can rollback then chain, then doesn't that circumvent the core tenant of no trust needed as now you have to trust that the group doesn't decide to rollback the chain?)

I can't imagine any scenario where a majority of the miners decided to rollback the blockchain with Bitcoin itself surviving unscathed.

we saw that pretty much with ethereum vs. ethereum classic

Ethereum has a clear leader.

>Being unable to fix a "whoopsy" is the biggest weakness.

Who decides what is a "whoopsy" a legitimate user made, and what is a pretend-"whoopsy" conjured by a malicious actor? Giving people & automated systems ability to flag something as "whoopsy" and revert it or lock down entire account enables malicious abuse and honest mistakes; either can end up very costly or even effectively irreversible in some cases.

Trivial example: every day we see a new post on HN about somebody's Apple/Google/YT/payment processor/etc operation/content/account being marked as "whoopsy" by the support or anti-fraud team, and they losing access to data/finances.

The best way to think of cryptocurrencies being "too absolutist" (irreversible) is as of a complementary counterpart to the (fiat) money which is too open to interpretation and always subject to unexpected third party decisions.

The irreversable transactions of money are primitive operations. Reversible transactions of money will be built on top of this.

It's time to retire javascript and css and any Turing complete scripting/styling, running random code from random websites is just never gonna be safe.

May as well have the web just be a series of PDFs, I've never heard of exploits in those! /s

Even just rendering engines can have bugs that can be exploited by specially crafted content. While it reduces the attack surface, it would be a massive hit to usability of web pages.

You should have specified somewhere that PDFs are also vulnerable. It is not common sense.

On that, PDFs run scripts and use graphic libraries, they are not text documents.

agreed, it was a bad example. You can fill them out like forms and the like.

PDFs can have full-on javascript and everything, too

Gemini ¯\_(ツ)_/¯

You write this seemingly as a joke, but someone a few months back actually posted a link to a blog that entirely consists of pdfs. What we really need is blogs that are all .txt files, to avoid the exploits in pdf active content.

I dunno, 20 years ago it gave us an instant cup holder

For those who might not have seen this reference: https://www.youtube.com/watch?v=gbVMdPDS1ak . Oh, VBScript, those were the times!

Laptops were so sexy back then.

If you got rid of JavaScript, it will mean that a lot of things that can be websites today would have to move to an application on your computer/phone. It is just shifting the security risk somewhere else.

Both of my computers (laptop and pinephone) get their native applications through secure, vetted channels that have practically never let malware through (their distro’s package repos).

And I have a browser that has practically never let malware through... and I get to visit any website without needing someone's approval.

I'll take open and a slight risk vs closed and a slight risk.

You can't know how many times your browser's let malware through, there's practically no supply chain security, no reproducible builds, no way to know what code has been executed.

I don't need anyone's approval to run native apps either, both my PCs run C apps I built from source and shell scripts I wrote myself without it, languages of my choice with implementations simple enough to write myself, not runtimes that literally no one that's not Google can afford to independently maintain. That's real openness.

computer security is generally broken, and will always be. Code will always have bugs, some of them will be security bugs. Always.

Yeah. But the web is like a VW Bug four-cycle motor rigged to a ratty tricycle overlaid with a stage-looking platform where large bears perform pole dances (poles glued to the tricycle's handle), and there's classrooms for ants on top of the heads of the bears and underneath it all the water level keeps rising...

Maybe we should have a dozen protocols for different kinds of applications. (I mean user-facing applications!) Maybe online banking shouldn't involve CSS and JavaScript. Spending some time with Gemini is a real eye opener in this respect.

What's Gemini?

https://gemini.circumlunar.space/

Name any CSS or JS exploit that had meaningful real-world impact in the last decade.

In 20 years on the Internet, most without an ad blocker, I haven't suffered from any lapses in browser security (that I know of, sure, but I don't much care about those I don't know about)

The tale of frequent compromises of browsers via ads is told merely to legitimize the practice of blocking even entirely plain and benign ads.

Great, but you're computer-savvy. You know not to click the 9 phony "Download" buttons and to find the nondescript text that says "Download link (slow)", and you probably don't even end up on sites like that in the first place.

Nowadays, the first thing I do when "cleaning up" a non-tech friend/relative's computer is to install uBlock Origin. Since I started doing that, the number of repeat calls dropped precipitously. (To be honest, it's probably good for their fake news intake, too...)

The web is a lot scarier for most people than you might realize if you've been successfully navigating away from sketchy sites for 30 years.

People lose website account credentials, with meaningful life impacts, all of the time. Even simple image ads that are fake "click here to login" have tricked my elderly relatives before. I install an ad blocker on the computers of relatives out of reaction to real events that happened, not paranoia.

You were never clickjacked?

Never had pop-up or pop-under ads/windows created without your consent? Recursively? Crashing your browser?

Never visited a page that was hijacked with an iframe?

I've experienced a lot of malicious ads in my time on the internet, it baffles me that someone has not.

> Name any CSS or JS exploit that had meaningful real-world impact in the last decade. The tale of frequent compromises of browsers via ads is told merely to legitimize the practice of blocking even entirely plain and benign ads.

I think the actual malware infections themselves legitimize the practice of blocking even entirely plain and benign ads.

Ads do still infect people with malware. https://blog.confiant.com/tag-barnakle-the-malvertiser-that-... Hell, yahoo was hit not that long ago and users were at risk of infection just by loading yahoo.com.

JS exploits and malware written in JS are common, but so far I haven't seen CSS used to infect systems, just steal data/log keystrokes and add a lot of privacy concerns which is bad enough. I'm already keeping an eye out for a CSS blocker that will only allow a sane subset of CSS and block or limit externally hosted resources.

Last time I tried reading a website without an ad blocker my sanity got compromised.

Reply on news.ycombinator.com