Circumvents uMatrix (& uBlock Origin) blocked connections

[Poonkraft]

When CSS-Exfil-Protection is enabled it allows behind-the-scene (or Tabless in case of uBlock) connections that are supposed to be blocked by uMatrix (or uBlock).

Steps to reproduce (simplest way) Firefox (68.11ESR):
Create new profile (just to make sure everything is plain vanilla)
Install uMatrix & CSS-Exfil-Protection, enable them both.
Set up uMatrix really strict (it happens with other settings too, but just to cut everything down to minimum): block everything except 1p images and CSS
Start uMatrix logger
Go to your test website
Open uMatrix panel: everything is blocked except www.mike-gualtieri.com images and CSS
Look at the uMatrix logger: there are allowed behind-the-scene connections to goeris.com and google fonts.
Disable CSS-Exfil-Protection, reload your test website and look at the logger: no more behind-the-scene connections (uMatrix panel shows the same blocked and allowed connections as before).

Note 1: same thing with uBlock logger, but I have not tested that thoroughly, so sticking with uMatrix for the now.
Note 2: it happens with many other sites too, not just your test site, some sites behave like this, some don't. I don't know what the difference is.
Note 3: uMatrix can be enabled on behind-the-scene, and then those attempts are blocked too (see logger), but that is not recommended because it might interfere with necessary browser functions.

[mlgualtieri]

Thanks for the report! A few people in the past have reported this, and I was never able to replicate. I tried again today and looked at it in a new way. When I block the domains with UBlock they don't appear in Firefox's network tab in developer tools. I incorrectly thought this meant the connection was not being made. I listened to network traffic with tcpdump and although the network tab shows nothing, network traffic is sent to the domain.

I have an idea how to 'fix' this. In general, it can't be actually fixed, since it's not possible to understand the settings one may have applied with other plugins. But, I'll be releasing a big update to the plugin today. One of the updates is to allow the user to change the scan/sanitize settings on a per-domain basis.

These new features alone won't be useful to solve the issue, but now that the framework is in place for these new settings, I can create additional default options that will be more compatible for privacy. The increase in privacy will unfortunately be a reduction in security, as if we avoid scanning cross-domain stylesheets, the user may not be aware of an attack, but this may be tolerable for most situations.

What I envision is that for users more concerned about privacy, the settings can be made so cross-domain stylesheets are not scanned by default. Then it's up to the user to enable scan/sanitize for more sensitive domains where data is at more risk, for example ecommerce sites.

I can't add this to the release I'm staging now, but should be able to extend the functionality in the subsequent release.

[Poonkraft]

Thank you for the response and the new version.
I did a quick test with the new version and I have a few questions and comments. I do not know the first thing about extension development and how they work (technical details), so these are purely from an end user perspective.

1. What is the difference between scan and sanitize? Why do one but not the other?
2. Looking at the uMatrix logger, I noticed that the behind-the-scene connections happen whether the original connection is blocked or not. (This is not about the fix, as you said there is no fix yet.) If the 3p domain is blocked, there is only the behind-the-scene connection. If the 3p domain is not blocked, there is the real connection, and after that the behind-the-scene connection. Why does the extension reload something that has been already loaded?
3. I blocked all behind-the-scene connections in uMatrix as an experiment to see how the browser behaves afterwards. I see no difference so far, it could update, the extensions could update, all my regular sites work just as before. I tested your extension with the tester and worked fine (i.e tester site stating the browser is not vulnerable). So why are those behind the scene connections needed? Can't the extension do its thing with what has been loaded and not worry about anything else? That way there seems to be no compromise between security and privacy, but I could be wrong.

Scan search after the exploit, sanitize remove the exploit and try to not break the website in the process

[mlgualtieri]

The newest update doesn't address this issue, but the framework is in place with 1.1.0 to add the enhancements to address.

Like @Aelisya said, "scan" only scans for the issue, but doesn't actually block anything. "sanitize" will attempt to block any bad CSS rules that might exfil data. But, neither of these will fix the problem addressed in this bug. I'll be adding another setting for privacy that will fix this.

[Poonkraft]

Disregard my first question, my bad. I removed the CSS-Exfil-Protector icon from the toolbar as I only keep the ones that I want to interact with sometimes (I just wanted to have this in the background doing its job). I did not realise the icon actually tells me if something is going on with the site and the extension. Now that I put it back I understand the difference, makes perfect sense.

[B00ze64]

I'm not sure I understand which requests go through in this bug; CSS only? I do use uMatrix (and uBO) and expect blocked domains not to fetch any data, especially since that might be because the domain is listed in a Malware list. But if CSS Exfil goes on to check CSS files on those domains, I'm not sure I'm very worried about that; it's just CSS and will be sanitized. It does defeat privacy, but not protection (i.e. more important is not running scripts from those domains). However, the planned privacy mode would be fine, if I understand correctly - if CSS Exfil does not scan/sanitize CSS that will not be loaded in any case, because it will be blocked by uMatrix (not sure about uBO) then there is no real danger in enabling the new privacy mode, it won't load so why sanitize it? EDIT: Ahhh, forget that last part, ALL 3rd party CSS would be exempt from sanitation, even the ones that do load because you've enabled them. Hmmm, there is indeed some danger there, but since you trust those domains, I guess you have to trust their CSS too...

[mlgualtieri]

The core issue here is that my plugin can't see the settings of other extensions, including uBlock, so if an extension blocks a domain from loading, mine will happily load it (as would any other extension). I verified with tcpdump that this is indeed happening, but there's no good solution. Due to how browsers handle cross-domain CSS, it's impossible to retrieve the CSSRules variable to analyse/sanitize these. The way my extension handles this is that an XHR request is made to pull in the sheet which can be temporarily loaded and analysed and then removed. Users concerned about privacy though, might not wish to have these requests to be made to pull in this CSS. So, the only option I can think of is to include a "privacy mode" that prevents scanning of cross-domain CSS... of course then you would be at risk to cross-domain CSS, which IMHO is the most likely way a CSS Exfil attack would occur. So... again no great options here.

[B00ze64]

You say "temporarily loaded and analysed and then removed" - Are they loaded into the document, or removed? If you load them for yourself but they are never added to the page then I see no issue except someone knows we pulled the CSS file...

[mlgualtieri]

The cross-domain CSS must be loaded into the document to access the CSSRules variable for the sheet... although now that I think about it, I wonder if we could create a temporary document for this purpose. I didn't think this was a major issue, because the sheet is loaded on the page anyway. That in itself I don't think is the main issue though, rather I think people are worried that the network connection itself to pull down the sheet can be used for tracking.

@mlgualtieri Information umatrix isn't developed anymore, so if the bug don't show itself with ublock by default i suggest to close this issue.

Source : https://www.ghacks.net/2020/09/20/umatrix-development-has-ended/

[nobody43]

I think this is premature. The extension is still used and will be used for a long time.

I think this is premature. The extension is still used and will be used for a long time.

In security an unmaintained extension or software must be replaced of uninstalled as soon as possible, so i maintain my suggestion, but it's up to @mlgualtieri to decide.

[mlgualtieri]

The issue occurs with all ad blocking / privacy plugins. I haven't had a chance to work on the plugin since the last release, and won't be able to for the next several weeks. But, a fix for this is coming.