Bug 399449

Summary:	[PRIVACY VIOLATION] plasma-browser-integration-host creates network connections
Product:	[Plasma] plasma-browser-integration	Reporter:	Stefan Becker <chemobejk>
Component:	Firefox	Assignee:	Kai Uwe Broulik <kde>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	fabian, rdieter, sowieso
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
URL:	https://bugzilla.mozilla.org/show_bug.cgi?id=1452461
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Patch with improved workaround

Description Stefan Becker 2018-10-06 16:05:20 UTC

After upgrading to F29 beta with Plasme 5.13.5 I got the reminder about the Browser integration. I installed the Firefox extension and started to test it. No problems there....

firefox-62.0-3.fc29.x86_64
plasma-browser-integration-5.13.5-1.fc29.x86_64
[this might also apply to Chromium, but I didn't activate the integration for it]

...but afterwards I had a look at "netstat -tp" and was surprised to see that the browser integration seems to create *outgoing* network connections on its own. Which is rather surprising when you read the statement from the Wiki https://community.kde.org/Plasma/Browser_Integration#Privacy:

Everything is handled on your PC between the browser and your desktop, no additional data is sent via the web.

Snapshot from my test system:

$ netstat -tnp | fgrep -e plasma- -e firefox
tcp 0 0 192.168.3.6:39846 xxxx:443 ESTABLISHED 1753/firefox
tcp 0 0 192.168.3.6:33556 xxxx:443 ESTABLISHED 1753/firefox
... many more open connections from firefox ....
tcp 2194537 0 192.168.3.6:49664 xxxx:443 ESTABLISHED 1753/firefox

tcp 1 0 192.168.3.6:35696 104.16.111.25:443 CLOSE_WAIT 2686/plasma-browser
tcp 32 0 192.168.3.6:57386 151.101.193.69:443 CLOSE_WAIT 2686/plasma-browser
...
tcp 8692 0 192.168.3.6:50810 104.20.117.11:443 CLOSE_WAIT 2686/plasma-browser
[NOTE: at other times I also saw ESTABLISHED connections. I tried to reverse look up the IPs but didn't get any usable information from them]

$ ps -efw | fgrep 2686
stefanb 2686 1753 0 09:38 ? 00:00:00 /usr/bin/plasma-browser-integration-host /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json plasma-browser-integration@kde.org

The above connections are not created by firefox, because firefox connections are associated with the firefox process.

I haven't yet studied the source code for the messaging host binary to check for network connection creation, but I'll try to do so when I get the time.

Comment 1 Fabian Vogt 2018-10-06 16:45:55 UTC

It's a bug in firefox, it doesn't use O_CLOEXEC so the FDs get inherited by the host process. Nothing we can fix ourselves and all other native extensions are affected as well.

Workaround: https://phabricator.kde.org/D15984

Comment 2 Stefan Becker 2018-10-06 16:50:33 UTC

As recommended I filed a bug upstream https://bugzilla.mozilla.org/show_bug.cgi?id=1496991

Comment 3 Stefan Becker 2018-10-06 17:20:55 UTC

After applying the workaround and restarting Firefox I do not see any "outgoing network connections" by plasma-browser-integration-host anymore. Thanks

Comment 4 Stefan Becker 2018-10-06 17:43:43 UTC

Unfortunately the workaround has a nasty side-effect: firefox starts to busy-loop :-(

I guess there are some FDs that firefox is using to communicate with the host binary and those should not be closed.

Comment 5 Stefan Becker 2018-10-06 20:46:39 UTC

Created attachment 115453 [details]
Patch with improved workaround

I poked around in the workaround code and figured out that the only way to avoid Firefox to busy loop is to *only* close() sockets and leave the rest alone. Thus we still have leaked file descriptors lying around, but at least we're getting rid of all leaked network connections at start.

Comment 6 Fabian Vogt 2018-10-06 21:53:49 UTC

Hm, that might be because the leaked FD has some weird behaviour. Flags (like O_NONBLOCK) are shared with the parent, so it's not too unlikely that closing a pipe can cause some unexpected behaviour.

The only correct behaviour here is not to close anything, really.

I would prefer to not have any kind of workaround for this broken browser behaviour in our code, especially if that workaround has to contain hacks.
It doesn't even change any kind of behaviour, it just makes the netstat output cleaner.

Let's see what kbroulik thinks about this.

Comment 7 Stefan Becker 2018-10-06 22:38:43 UTC

My Mozilla bug got marked as duplicate

Comment 8 Kai Uwe Broulik 2020-03-16 08:55:17 UTC

*** Bug 418907 has been marked as a duplicate of this bug. ***