Abuse of localhost ports

[SlySven]

I've just been made aware of this: https://localmess.github.io/ and, although PM doesn't attempt/use "WebRTC" as I understand it, is there anything that needs to be considered to mitigate this "backdoor" - what legitimate things would be affected if PM adopted the same "fixes" that FF does to block specific ports?

[Moonchild]

N/A because we don't publish a mobile browser with this kind of permission issue.

[Bilbo47]

Can this issue be relevant on desktop also? I have a couple legit apps that operate only as a background server, where the UI is entirely through a browser. So if no one has done malware this way already, they're gonna try.

[Moonchild]

By definition that would be cross-origin access, so that won't succeed. I don't think we even allow CORS preflights in that case (but I may be misremembering). i.e. as far as I know that would only be possible if the local web interface explicitly allows the remote domain to access it.

[suzyne]

I didn't understand most of the technical details of the exploit in the article (even so it was still a fascinating read) but I came away with the impression that the invasion of privacy and collection of data relies on an ecosystem of apps by the same company that is doing the collecting to be running on the phone. I don't see how that could happen on the desktop?

[Moonchild]

I didn't understand most of the technical details of the exploit in the article (even so it was still a fascinating read) but I came away with the impression that the invasion of privacy and collection of data relies on an ecosystem of apps by the same company that is doing the collecting to be running on the phone. I don't see how that could happen on the desktop?

Correct, hence my initial reply.

[Veit Kannegieser]

it would work if processes would listen.

I came across a site that tries to identify the PC/notebook model by communicating with a local port, without user consent:
https://www.dell.com/support/product-details/de-de/product/vostro-3700/drivers

In that case it is trying 127.0.0.1/clientservice/isalive/?expires=1750325211&.. on ports 8884, 8883, 8886, and 8885.

The communication is passed:
>python3 -m http.server 8884
127.0.0.1 - - [19/Jun/2025 00:23:25] code 400, message Bad request syntax ('\\x16\\x03\\x01\\x02\\x00\\x01\\x00\\x01ü\\x03\\x03Ò~riS\\x1bÍÇ\\x9d\\x13ie\\xadÉÝS\\x19Ó?=°í¸<\\x81yCj§¹[?\\x00\\x00*\\x13\\x01\\x13\\x03\x13\\x02À+À/̨̩À,À0À')
127.0.0.1 - - [19/Jun/2025 00:23:25] "\x16\x03\x01\x02\x00\x01\x00\x01ü\x03\x03Ò~riS\x1bÍÇ\x9d\x13ie­ÉÝS\x19Ó?=°í¸<\x81yCj§¹[?\x00\x00*\x13\x01\x13\x03\x13\x02À+À/̨̩À,À0À" 400 -

Could use uBlock to disallow communication with 127.0.0.1.

[Moonchild]

Of course. but that's the key thing: if processes would listen. Unfortunately the browser being able to connect out to arbitrary ports from scripting is also very much per spec, because someone decided at some point in time that that kind of access was desired for integration of web interfaces with local devices.

[Bilbo47]

the [problem] relies on an ecosystem of apps by the same company ... to be running on the phone. I don't see how that could happen on the desktop?

Here's how it makes sense to me.

Say you run Spotify, or other similar so-called app, maybe somehow affiliated with Ggl or FB, or with any site hosting the theif-scripts. Does not matter whether it is a native executable, or running "browser-style" inside a framework like Electron or whatever, where it replaces a general browser. Both your own browser and the hosted app act as front-ends / UIs for the Spotify's web server back-end.

Many programs install so as to launch at Windows startup and stay resident in the background until user opens them, "for convenience". Same *could be* done with framework-hosted apps, in frameworks that support it.

Native apps can access "everything" about the system, and can open ports to listen on. Same *could be* done with framework-hosted apps, in frameworks that support it.

Just like on a phone, a desktop browser visiting a related site, or any site that serves the scripts, could be induced to try trading data on the pre-determined local port. If the resident local "server" responds, then the site can suck out information that browsers are otherwise designed to not-access.

[suzyne]

I don't understand enough about the technical side of this issue to say what is and isn't possible.

But I take comfort that on the desktop, the invasion of privacy described with the local ports requires a specific set of circumstances, which don't apply to me because I never install or use Electron-based apps.

My reasoning is that it makes little sense to be running extra "browser" instances, with the added memory use, when I already have an actual browser open and ready to go.

For those who do use the Spotify (or whatever) apps, I imagine that after the exposé of the Yandex/Meta local port scheme, somebody with the necessary expertise will check apps like this for similar exploits?

[Gemmaugr]

I don't understand enough about the technical side of this issue to say what is and isn't possible.

But I take comfort that on the desktop, the invasion of privacy described with the local ports requires a specific set of circumstances, which don't apply to me because I never install or use Electron-based apps.

My reasoning is that it makes little sense to be running extra "browser" instances, with the added memory use, when I already have an actual browser open and ready to go.

For those who do use the Spotify (or whatever) apps, I imagine that after the exposé of the Yandex/Meta local port scheme, somebody with the necessary expertise will check apps like this for similar exploits?

If it concerns Electron apps, isn't it highly likely CEF programs might be affected as well: https://en.wikipedia.org/wiki/Chromium_ ... _using_CEF

[suzyne]

If it concerns Electron apps, isn't it highly likely CEF programs might be affected as well: https://en.wikipedia.org/wiki/Chromium_ ... _using_CEF

Can't answer that!

I don't know how definitive the wikipedia list is, but the Steam client is the only app from the list that I might potentially need to worry about.

[mifritscher]

localhost ports are often used for development, applications with uses browsers as frontend, ssh forwardings (which can be quite complex e.g. für IPMI/KVM consoles using e.g. different ports).

So please _not_ block them, at least without a warning and unblock them permanently. In my opinion, if a server/application is "hackable" i this way, it is not the fault of the browser, but of the application.

[q160765803]

I do wonder how/why any other internet webpages can even able to access localhost/127.0.0.1 or any other local addresses.

[Moonchild]

I do wonder how/why any other internet webpages can even able to access localhost/127.0.0.1 or any other local addresses.

localhost or its IP addresses are not any different than other networking hosts or addresses. They go through the same layer and protocol stacks. As long as web APIs allow you to connect via scripting to other hosts/addresses (which they do) you can also access "private" addresses like localhost, LAN IPs, etc. That is all by design.