Ungoogled-chromium: Restrict access to localhost

[illiliti]

A lot of websites abuses websockets to scan ports on localhost. I think we should restrict access to localhost to prevent port scanning

More information -> https://blog.nem.ec/2020/05/24/ebay-port-scanning/

[wchen342]

Is the attack mentioned in bromite/bromite/issues/590 the same one?

[illiliti]

Looks like it is.

[Eloston]

Might be best to wait a bit to see if Google will address this issue (https://bugs.chromium.org/p/chromium/issues/detail?id=378566). Otherwise, I'm open to patches

[flatsiedatsie]

I run the Mozilla WebThings Gateway on a Raspberry PI, with unGoogled Chromium in kiosk mode accessing the local webserver. I believe it uses websockets to communicate - but I'm really no expert. I just hope it won't harm that use case :-)

I clicked on this issue because I hoped it would be about only allowing http://localhost to be approached, with a whitelist on which domains could be accessed. That would actually be great for this kiosk mode use case.

[csagan5]

I have released the patch to close this hole in Bromite: https://github.com/bromite/bromite/blob/f513eb76ecb9c5ae62e065608596ccb13643b1c6/build/patches/Block-gateway-attacks-via-websockets.patch

[Eloston]

@csagan5 I noticed this comment in the patch you linked:

// TODO(mkwst): This only checks explicit IP addresses. We'll have to move
// all this up to //net and //content in order to have any real impact on
// gateway attacks. That turns out to be a TON of work (crbug.com/378566).

Do you have context on what this comment means? What does he mean by "real impact"?

[csagan5]

@Eloston you can read more on the linked issue in that comment: https://bugs.chromium.org/p/chromium/issues/detail?id=378566

My understanding is that if you have an address resolving to a private address (like localhost or any other host resolving to a private one) then this patch would not help.

Also: the only error I could trigger is Access to this address is not allowed., I did not know how to test for the other security hardening changes I added.

The latest version of this patch is here and does not enable CORS RFC1918 because it breaks some sites (Twitter, Reddit etc); they will probably update their CORS as Chromium rolls out the change.

[Eloston]

Hmm at this point I'm not comfortable adding the patch in its current state, since I don't see its benefits outweighing the code changes.

The latest version of this patch is here and does not enable CORS RFC1918 because it breaks some sites (Twitter, Reddit etc); they will probably update their CORS as Chromium rolls out the change.

Could you clarify what you mean here? From a cursory inspection, it actually looks like they enabled CORS RFC1918-specific behavior:

• https://github.com/bromite/bromite/blob/84.0.4147.119/build/patches/Block-gateway-attacks-via-websockets.patch#L27
• https://github.com/bromite/bromite/blob/84.0.4147.119/build/patches/Block-gateway-attacks-via-websockets.patch#L135-L168

[csagan5]

Could you clarify what you mean here? From a cursory inspection, it actually looks like they enabled CORS RFC1918-specific behavior:

CORS RFC1918 does much more than what you can see in that patch; you need to search for references in the Chromium codebase. I only enabled functionality specific to prevent gateway attacks, which is a subset of CORS RFC1918.

If you enable CORS RFC1918 in vanilla Chromium it will also break major websites because they are not all compliant with it.

[travankor]

Seems like this feature lands in upstream v87, which presents a user-toggleable flag for CORS RFC1918.

So, this issue can be closed unless the UC developers want to enable this by default.

[Eloston]

Closing since a flag landed in v87.