Surely such a glaring vulnerability would have been caught by the open source community and, to some extent, Mozilla, Google and Microsoft through their web extension store review processes?
I believe your concern is legitimate, but the attack surface you’re describing could equally apply to any sufficiently privileged extension. uBO filters are essentially a series of instructions with the ability to exercise some pretty powerful extension capabilities. The difference is that they’re being developed and scrutinised in the open, so you’d expect anything malicious or suspicious to get caught and patched pretty damn quickly.
But I think the bigger point is that the whole thing is ultimately built on a mutual agreement that this crowdsourced firewall, with its wide-ranging permissions, is being used as a force for good. You’re trusting uBO and its filter maintainers not to abuse those capabilities. So IMO the interesting question isn’t really whether uBO can do these things, you’ve proved that it can, but how robust the safeguards are around who can introduce trusted rules and how those changes are reviewed.
I like what you are implying OP. Some sandboxing to enforce that filters do what they say on the tin can. Or taking it to the next level a trustless system where all filters that are not explicitly signed are untrusted and users have to grant permissions that a filter requests. I just think that would require a big revamp and cause a lot of UX friction so most people trust that the community is vigilant instead. Eh just my 2 cents.
It is not a vulnerability, it is by design. It has not been caught, It is the example that open source does not mean that people examine and scrutinize the source code,
Ghostery uses an eval-bridge between isolated and main world has not been caught either. I also found out about it when I implemented worry-free (checking how Ghoster had implemented the never consent). Both (uBo's json-edit.js and Ghostery's eval-bridge) are examples of sub optimal programming practices (as Cruel Sister probably would say).
It has nothing to do with signing a scriptlet, A scriptlet uses input parameters, which gives it the swiss-army knife like capabilities, that is the problem.
When a rogue maintainer drops a rule in a trusted filter list using a signed scritplet with the wrong parameters on the wrong website, and you are using that websites, you are probably screwed, no matter whether the scriptlet is signed or not.
AdGuard maintains it own filters with its own filter team. They also have a supply chain risk, but before becoming a member/employee AG will probably have a thorough selection process where the indentity of the member is established based on verifiable data (passport, birth certificate or driving license), where as the identity check of Github only is an e-mail address response.
The supply chain risk is related to the github maintainers of the uBlock Assets team, so the interesting question is how solid is the identification and authentification proces when new members are added to uAssets team. Does it go any further than the e-mail confirmation of Github?
That is the real (trust) question and it is related to uBO specifically.
