AVM Fritz!Box Router backup-file upload fails reproducibly with wrong decrypt password with uBlock Origin active

[hondogitsune]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

AVM Fritz!Box Router backup-file upload fails reproducibly with wrong decrypt password with uBlock Origin active

A specific URL where the issue occurs.

The URI for the router's IP on LAN:

http://10.0.0.1/

Workaround:
/10\.0\.0\.\d{1,3}/
Or whatever regex matches your LAN IP range.

Default is 192.168.178.1, but this would fail too.

The uBO badge pre-fix displays a match count of none/zero. So I don't know the exact cause why the POST of the binary file upload of the forms field with the associated decrypt password garbles the POST data.

/userblahblah=off

Steps to Reproduce

1. AVM Fritz!Box Router backup-file upload
2. fails reproducibly with wrong decrypt password with uBlock Origin active
3. badge shows no/zero filters interfering
4. still fails

Expected behavio(u)r

Binary and decrypt PW upload without error.

Troubleshooting information

Workaround:
/10\.0\.0\.\d{1,3}/
Exclude/whitelist this or whatever regex matches your LAN IP range.

Remarks

As the filter count is none/zero this should be really a uBO issue itself as the POST request is garbled.
Feel free to close or ignore, this is for people with the same issue searching/looking for a solution.
It doesn't matter, everyone with the issue now can self-help.
Thanks for developing uBO, you are all heroes.

[gorhill]

Troubleshooting information

Please provide troubleshooting information as requested in the template.

[uBlock-user]

/10.0.0.\d{1,3}/
Exclude/whitelist this or whatever regex matches your LAN IP range.

Sounds like an issue with Block Outsider Intrusion into LAN

[hondogitsune]

I would, but every test requires me to flash a file to my router, wait minutes for it to reboot, wait minutes until the VDSL2 vectoring training is finished and i can logon to my ISP via PPPoE.

I honour your interest in resolving the issue, but I am unable to test this right now without forcing myself offline. Naturally I will close this issue. If another person with more time finds it and is affected, they may re-open or comment on it.

After all AVM (now FRITZ only) is a brand in Germany supplying the 2 largest nation wide telcos 1&1 and Telekom at the same time.
I cannot be the only one affected, or it is my non-default Class-C net.

Either way, my heartfelt thanks. I posted it as documentation only if other people experience the issue. For search engines.

Edit:
@uBlock-user

Sounds like an issue with Block Outsider Intrusion into LAN

Yes indeed, it sounds like a meaningful protection that external scripts cannot attack the LAN.

Edit 2:

uBlock Origin: 1.69.0
Firefox: 147
filterset (summary):
 network: 171908
 cosmetic: 87584
 scriptlet: 35803
 html: 3050
listset (total-discarded, last-updated):
 added:
  fanboy-cookiemonster: 56271-10967, 2m
  ublock-cookies-easylist: 5491-40, 2m
 default:
  user-filters: 514-1, never
  ublock-filters: 44440-73, now
  ublock-badware: 10857-31, now
  ublock-privacy: 3617-2, 1m
  ublock-unbreak: 2789-1, 1m
  ublock-quick-fixes: 451-13, 1m
  easylist: 93476-156, 1m
  easyprivacy: 55392-29, 2m
  urlhaus-1: 25870-5, 2m
  plowe-0: 3504-1007, 2m
  DEU-0: 8167-33, 2m
filterset (user): [array of 513 redacted]
trustedset:
 added: [array of 2 redacted]
userSettings:
 userFiltersTrusted: true
hiddenSettings:
 trustedListPrefixes: ublock- user-
supportStats:
 allReadyAfter: 624 ms
 maxAssetCacheWait: 348 ms
 cacheBackend: indexedDB

Do note that this is my current setup again and all non-vanilla. The one where I work with the regex exception.

My personal filters do not include any LAN related entries. I am still unsure how exactly the POST request in the all vanilla test failed with the badge counter remaining at none/zero hits. This last info was ultimately my surprise when I found out uBO can block without notifying of a block happening.

But it really is not a big deal. Most users access these routers over the URI called fritz.box as the Router redirects this DNS to it's current IP in LAN.

Since I operate 1 main router and several other AVM routers in slave mode as APs for mere wifi, I need to directly access them with their actual IP to change settings. Since the fritz.box DNS redirection only covers the main/master router.

However the takeaway here is that a POST initiated from http://10.0.0.1/ to http://10.0.0.1/ was blocked without the badge updating there was a block happening.

This is really not that important, unless some other lost soul should find this issue and can help themselves.

[gorhill]

I would, but every test requires

I don't understand, there is nothing to test, troubleshooting information is available in uBO's About pane in its dashboard. The information would have shown whether Block LAN list was enabled or not.

[uBlock-user]

Yes indeed, it sounds like a meaningful protection that external scripts cannot attack the LAN.

No, your configuration of uBO doesn't show you activated that list.

[gorhill]

filterset (user): [array of 513 redacted]

However the takeaway here is that a POST initiated from http://10.0.0.1/ to http://10.0.0.1/ was blocked without the badge updating there was a block happening.

Use the logger to diagnose filter issues when using heavily customized settings.

[hondogitsune]

Since it is the right thing to live up to your mistakes and admit them, I disclose this was indeed and of course my fault:
!*##+js(aeld, /blur|visibilitychange/)

Foolish me did not expect my router would use these, which usually track users on websites if the tab is active. If by anything for the history books and other people: Do not set a filter to apply to all sites ever. Yes the badge count did not change, yes the logger could have warned me.

But I feel shame and promise to become more vanilla again. I forgot to untick my own filters during the re-test and probably failed to do so as well in the past. Apart from the cookies lists it is close to vanilla but not truly. Sorry.