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
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.
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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?)
>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.
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?
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 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.
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).
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.
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.
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.
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.
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.
> 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.
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.
>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!