Keepassxc-browser: external connections from keepassxc-proxy

[a-v-popov]

Expected Behavior

If my understanding is correct keepassxc should not have any external communication.

Current Behavior

$ netstat -atpn | grep keepass
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:6080 0.0.0.0:* LISTEN 8307/keepassxc-prox
tcp 0 0 127.0.0.1:6080 127.0.0.1:55164 CLOSE_WAIT 8307/keepassxc-prox
tcp 1 0 192.168.1.4:55578 173.194.222.190:443 CLOSE_WAIT 8307/keepassxc-prox
tcp 1 0 192.168.1.4:48552 173.194.221.139:443 CLOSE_WAIT 8307/keepassxc-prox

Debug info

KeePassXC - 2.3.1
keepassxc-browser - 1.0.1
Operating system: Linux
Browser: Firefox/Chromium
Proxy used: YES

[varjolintu]

keepassxc-proxy is using only Unix Domain sockets for communication. So showing some TCP sockets open seems a bit strange..

[a-v-popov]

Apparently this thing is based upon high level libs and some google magic. Honestly, it is not very surprising that it can be doing a lot more than it was intended to. I suspect it might be related to extension debugging which I initiated from chromium as the extension did not work for me. Unfortunately I had to kick it out from the host and it will take me some time to repeat it in a VM.
The only thing I can say at the moment is that sha checksum on source tarball is the same as on github.

[droidmonkey]

Google owns the 173.194.0.0 ip range. https://ipinfo.io/173.194.222.190

When you enabled debugging you probably also enabled stats reporting and other things. The top two tcp lines are local connections.

[a-v-popov]

One of the components provided by keepassxc openned a connection to external IP.
Please note that it wasn't opened by Chromium or Firefox, but by you executable, which is also involved in handing sensitive data.
Can you please elaborate why it opened a remote connection?

[varjolintu]

Can you please elaborate where do you see this connection and where does it connect? Or is this still some Google magic? keepassxc-proxy doesn't open any other connections than the Unix Domain socket to localhost.

Also, please note that while keepassxc-proxy handles sensitive data, it is encrypted and the executable lacks the functionality to decrypt it.

Reopening the issue until this has been solved.

[a-v-popov]

Got the same picture with fresh ubuntu 17.10 install in VM. Steps to reproduce:

1. install ubuntu from official image
2. add keepassxc-browser plugin into Firefox
3. install keepassxc from "official PPA" as per keepassxc.org download page
4. create a new database
5. press reload button in plugin interface
   On the first connection I saw the following:

user@ubuntu-vm:~$ sudo netstat -apn | grep keepassxc-p
tcp       32      0 192.168.2.245:58570     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47546     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:58572     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:58346     54.230.14.25:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:58548     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47558     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47550     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:58574     52.89.239.72:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47552     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp        0      0 192.168.2.245:60556     93.184.220.29:80        ESTABLISHED 3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47548     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:58344     54.230.14.25:443        CLOSE_WAIT  3711/keepassxc-prox 
tcp        1      0 192.168.2.245:47554     54.230.12.110:443       CLOSE_WAIT  3711/keepassxc-prox 
tcp       32      0 192.168.2.245:46282     35.161.134.132:443      CLOSE_WAIT  3711/keepassxc-prox 
unix  3      [ ]         STREAM     CONNECTED     47161    3711/keepassxc-prox  
user@ubuntu-vm:~$

It will also open remote connections on subsequent restarts, but you might need to try a few times.

[varjolintu]

I'm seeing this too. All the ports are 80 or 443 so this is clearly web browser traffic. I'm pretty sure this has something to do with native messaging because the keepassxc-proxy process is started by the browser. The reason for this is unclear, and I don't like seeing this kind of behaviour.

Btw, the socket list disappears when you close your browser.

[remspoor]

I just want to let everyone know that i see the same behavior. Actually i found this bug while searching for answers.
Running Arch linux with firefox 59.0.2 (64-bit)

tcp 0 0 192.168.1.1:54300 151.101.37.105:http ESTAB 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54210 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:45206 31.22.22.135:https CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:52286 95.101.1.104:http ESTAB 2724/keepassxc-prox
tcp 0 0 192.168.1.1:46138 66.96.160.139:http CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:35874 139.15.248.182:https CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54206 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54208 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54314 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 1 0 192.168.1.1:54212 172.217.19.206:http CLOSE-WAIT 2724/keepassxc-prox
tcp 0 0 192.168.1.1:49150 23.62.98.18:http ESTAB 2724/keepassxc-prox
tcp 0 0 192.168.1.1:54270 151.101.37.105:http ESTAB 2724/keepassxc-prox

[varjolintu]

Seems these connections happen only with Firefox. I opened a bug. Let's see what they respond.

[droidmonkey]

After I tested this, I personally found that turning off the telemetry and usage data in Firefox prevented the sockets from being opened. @varjolintu could not replicate that fix though. Chromium does not exhibit this behavior at all.

[varjolintu]

For me the opened connection was a HTTP GET request to http://detectportal.firefox.com/success.txt which had a X-Amz-Cf-Id reply with encrypted data (a token perhaps).

Also, see this. This still doesn't explain why native messaging opens those TCP sockets.

[varjolintu]

According to this page the bug is fixed with Firefox 61.

[droidmonkey]

I'm closing this issue since it is clearly not a KeePassXC issue.

[brzd]

Could you please, reopen and investigate further. KeepassXC-Browser opens ports to several awkward addresses, non-Google, such as 104.31.74.222 (Cloudflare), 193.229.109.157, etc.

[varjolintu]

@brzd KeePassXC-Browser? Do you mean keepassxc-proxy? Looking at the Firefox issue few messages earlier they have fixed the bug. What browser are you using? Any details are welcome.

Just to make clear: keepassxc-proxy (or the extension, with the exception of GitHub when checking the latest KeePassXC version available) DOES NOT open any connections to anywhere. The only thing keepassxc-proxy uses is a local Unix domain socket that communicates directly with KeePassXC.

[brzd]

Firefox 66.0.1

So it would still be the same issue with firefox?

[varjolintu]

@brzd Mozilla reports it has been fixed in Firefox 61. I'll try to reproduce this myself and make another bug report if necessary. This is related to native messaging itself, not KeePassXC or the proxy.

[Cherkah]

i've the same issue with keepassxc-proxy & i'm running the flatpak one .
keepassxc-browser get external connections!!!! Does my passwords are send on the web???
why can't i untick the proxy option in the keepassxc?
as you can see, the sh process are related to the keepassxc-proxy'process

$ sockstat -4 -l
MEE sh 27179 tcp4 192.168.43.205:53534 23.62.98.16:80 ESTABLISHED
MEE sh 27179 tcp4 192.168.43.205:46734 138.201.81.199:443 ESTABLISHED
MEE sh 27179 tcp4 192.168.43.205:48708 93.184.220.29:80 ESTABLISHED
MEE sh 27179 tcp4 192.168.43.205:43592 143.204.192.7:443 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:53534 23.62.98.16:80 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:46734 138.201.81.199:443 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:48708 93.184.220.29:80 ESTABLISHED
MEE keepassxc-proxy 27181 tcp4 192.168.43.205:43592 143.204.192.7:443 ESTABLISHED

Debug info

KeePassXC - 2.4.1
keepassxc-browser - 1.4.3
Operating system: Linux
Browser: Firefox quantum 66.0.1
Proxy used: YES

[varjolintu]

@Cherkah This is a Firefox bug. Your passwords are not sent anywhere. Even if that bug would leak any data (for some reason), it would be encrypted.

[Cherkah]

ok but why can't we untick the option keepassx-proxy (keepassxc flatpak/snap) whereas the distro app (debian) we can? the option is greyed

Even if that bug would leak any data (for some reason), it would be encrypted.

maybe, but i'm the kind of people which do not have any confidence about amazon (143.204.192.7:443 ESTABLISHED).

please make the option un-greyed.
thx

[droidmonkey]

@Cherkah you can just not use the browser extension. Even if there is no proxy, launching the KeePassXC application itself would cause those phantom connections to occur. We have zero control over that because, as repeatedly stated, this is a bug/feature in Firefox itself.

[Cherkah]

after let a ticket to mozilla foundation about this probleme ( base on your statement and my connection report) it seem that is your softwar which make bull**.

i do not understand why varjolintu tells & droidmonkey tells are so divergent?! for one it is not normal and for the other one " those phantom connections" are secure....

just to test your soft i reinstall all my system, change my browser, block ip via iptable: the issue remains.

so sorry but i' do not trust your app. results: uninstall it and change all my password.
most of people consume freely softwar in trust but few of them keep a regards on what it did.

thanks

[varjolintu]

@Cherkah It's a known problem in Firefox that causes this issue. Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1463873. There's still no fix available.

These phantom connections mean that KeePassXC or the proxy doesn't directly open a socket to anywhere, but when Firefox forks a process via Native Messaging, those sockets are copied to the other process. And also, KeePassXC or the proxy doesn't use those sockets for anything.

If you want to get rid of the bug or you are concerned (assuming you don't trust our application), all you can do is to switch to another browser. You are also always welcome to inspect our source code if you think our applications are making some phantom connections.

[jurisbu]

Any updates on this? This is suspicious.

[phoerious]

We cannot do anything about that. It's a Firefox bug. We neither open nor use these connections.

[j1warren]

but when Firefox forks a process via Native Messaging, those sockets are copied to the other process.

@varjolintu, ok, then why don't make keepassxc-proxy explicitly close any leftover fd's on start?

[varjolintu]

@j1warren That could be possible yes, but I wonder if there's a solid cross-platform way to do that.

[droidmonkey]

Can we close a socket owned by a parent process?

[varjolintu]

We should investigate if the socket is indeed a copy. In that closing them would probably cause more bad than good.

[aadrian]

Would you please reopen this issue?

This issue still exists: the keepassxc-proxy processes still have connections outside the local machine in the latest versions of Firefox + Keepassxc + keepassxc plugin :( .

This alone put KeepassXC in a few companies on the ban list :( .

Thank you.

[varjolintu]

@aadrian Again: this is not a KeePassXC issue. It's a Firefox bug.

[aadrian]

@varjolintu This issue affects KeePassXC however, even if (technically) the source of the Bug is Firefox.

Also because of this: not Firefox landed on the ban list, but KeePassXC :( .

IMO until the problem is fixed, the issue should not be "closed" but kept open with a tag/label of "waiting for 3rd party".

If there's a simple temporary workaround until FF is fixed (e.g. a simple iptables rule), it might also greatly help.

[varjolintu]

@aadrian I'll open this with the label added.

[0xpr03]

Same here on firefox, browser plugin creates open sockets

172.65.251.78:https (CLOSE_WAIT)
ec2-52-26-249-11.us-west-2.compute.amazonaws.com:https (ESTABLISHED)

Just for documentation