Connections associated with the wrong application

[raboof]

Hi! Loving opensnitch, looks like the state-of-the-art in Linux Desktop Firewalling!

Describe the bug

I have had 2 occurrences where opensnitch appears to have associated a connection with the wrong application.

Once was yesterday, when opensnitch claimed zoom was connecting to a website that I had open in my browser. Suspicious, but I didn't have time to look into it further at that time.

Today, it claimed kbfsfuse was trying to reach upload.wikimedia.org, which also seems unlikely. I allowed the connection, and verified with netstat that indeed it looks like it was Firefox, not kbfsfuse, that was connecting to wikimedia.

To Reproduce

I haven't found a way to reproduce this yet. Any suggestions on how to narrow down this problem are appreciated!

Post error logs:

Log of the 'allow:

[2021-03-30 13:35:41]  IMP  Added new rule: allow if list is '[{"type": "simple", "operand": "dest.host", "data": "upload.wikimedia.org"}, {"type": "simple", "operand": "process.path", "data": "/nix/store/dlj3qw2bhlck25liax5c137f5v51ljl3-kbfs-5.6.1/bin/kbfsfuse"}]'

Checks after that:

$ dig upload.wikimedia.org

; <<>> DiG 9.16.12 <<>> upload.wikimedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20855
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;upload.wikimedia.org.		IN	A

;; ANSWER SECTION:
upload.wikimedia.org.	436	IN	A	91.198.174.208

;; Query time: 16 msec
;; SERVER: 192.168.188.1#53(192.168.188.1)
;; WHEN: Tue Mar 30 15:35:49 CEST 2021
;; MSG SIZE  rcvd: 65
$ netstat -pan | grep 91.198.174.208
(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 192.168.188.21:54662    91.198.174.208:443      ESTABLISHED 24079/.firefox-wrap

OS (please complete the following information):

• OS: NixOS Linux
• Window Manager: Notion
• Kernel version: Linux rigter 5.10.25 TypeError: pkt_callback() takes exactly 2 arguments (3 given) #1-NixOS SMP Sat Mar 20 09:43:44 UTC 2021 x86_64 GNU/Linux
• Version: unstable

[gustavo-iniguez-goya]

mm, interesting @raboof , could you reproduce it again with DEBUG log level and post the logs when it occurs? thank you!

[raboof]

It looks like I'm using the (default?) 'proc' process monitor method. Perhaps that's inherently racy? would ftrace or audit be recommended?

[gustavo-iniguez-goya]

no, ftrace needs a rewrite to be more useful (already done, but not commited yet), and auditd offers reliability gathering process's name name and path (it's pretty common to hide processes from /proc to perform malicious activities). This problem should be gone once we add ebpf.

Btw, do you see this behaviour often? Sometimes I've ran into this issue but very rarely.

On the other hand what's /nix/store/? nix-store storage location, sandboxed, like snap?

[raboof]

This problem should be gone once we add ebpf.

Cool, staying tuned ;)

Btw, do you see this behaviour often?

I only saw it twice so far

what's /nix/store/? nix-store storage location, sandboxed, like snap

Indeed it's nix's storage location, but it's not sandboxed (other than being in located a somewhat hard to find path ;) )

[gustavo-iniguez-goya]

mmh... analyzing the connections of my system using ftrace I'm seeing something weird:

opensnitchd-16249   [002] ..s1 3576146.963434: inet_sock_set_state: family=AF_INET6 protocol=IPPROTO_TCP sport=36380 dport=9054 saddr=127.0.0.1 daddr=127.0.0.1 saddrv6=::ffff:127.0.0.1 daddrv6=::ffff:127.0.0.1 oldstate=TCP_SYN_SENT newstate=TCP_ESTABLISHED
opensnitchd-16249   [002] ..s1 3576146.963459: inet_sock_set_state: family=AF_INET protocol=IPPROTO_TCP sport=9054 dport=0 saddr=127.0.0.1 daddr=0.0.0.0 saddrv6=::ffff:127.0.0.1 daddrv6=::ffff:0.0.0.0 oldstate=TCP_LISTEN newstate=TCP_SYN_RECV

this is a trace reporting that opensnitchd has connected to 127.0.0.1 on port 9054, but that's no possible. What is actually establishing those connections is Tor, not opensnitchd. So maybe there's something that is not behaving correctly.

[NRGLine4Sec]

Hi @gustavo-iniguez-goya,
I also have the same problem sometimes. For me the problem appears when I am connected by VPN and when I have a big increase in load of my CPU which freezes my PC. This causes a problem with the connections going through the VPN (I'm not sure why and I never took the time to investigate) with the VPN staying up and that's when I have OpenSnitch sending pop-ups with requests to authorize connections that clearly do not belong to the associated application by OpenSnitch in the pop up.
I also use the proc method.

OS :
OS: Debian
Window Manager: Gnome
Kernel version: 5.10.0-0.bpo.3-amd64 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
Version: Buster

[gustavo-iniguez-goya]

Thank you @NRGLine4Sec , this should be fixed with the new monitor method eBPF.

If you can build latest sources from master, I can post the .o eBPF object to ease that compilation step in order for you to test.

[NRGLine4Sec]

Yes, I saw you merge this new monitor method.
I don't have much time at the moment, so i think i would test it when it is in an RC.
I hope this will correct the problem.
In any case, thank you for your great work on this tool 👍

[lahdekorpi]

Should this fix be in the 1.4.0rc1? I've been having the same issue and just upgraded to the RC to test it out.

[gustavo-iniguez-goya]

not in v1.4.0rc1 @lahdekorpi , but in the next rc release (latest sources from master).

By the way, which app is being reported erronously? Would you mind to share what apps do you run as usual? (no problem if you don't want to share them, it's only to try to reproduced the issue locally).

[lahdekorpi]

not in v1.4.0rc1 @lahdekorpi , but in the next rc release (latest sources from master).

By the way, which app is being reported erronously? Would you mind to share what apps do you run as usual? (no problem if you don't want to share them, it's only to try to reproduced the issue locally).

I've gotten this very randomly on different processes, including kbfsfuse, dropbox, chrome, signal, gnome account, evolution... I haven't figured out if there are any conditions that need to be met for this to happen.
At times, I may be browsing a website with Chrome (with everything allowed) and in the middle of the page loading, get a notification that Signal is trying to access some third-party CDN that is actually loaded in the source of the website.

[NRGLine4Sec]

For me, it comes often with Signal Desktop too and Joplin.

[gustavo-iniguez-goya]

thank you! so it looks like Signal and kbfs (and chrome probbly) are in used when this occur. For me is when I proxify everything through Tor.

I don't think that this will be fixed with eBPF, as I'm using it and from time to time I see this behaviour.

[gustavo-iniguez-goya]

hey, could you comment out this line, recompile the daemon and see what happens?
https://github.com/evilsocket/opensnitch/blob/master/daemon/netlink/socket.go#L75

[gustavo-iniguez-goya]

I've found a way of reproducing this problem and I think I've got a fix finally.

So the problem is that sometimes the details of an outgoing connection (src port:src IP -> dest IP:dest port) as seen by iptables does not match the results when query the kernel for it via netlink:

new connection udp => 123:192.168.1.78 -> 5.196.160.139:123 uid: 118

kernel entries:

[0/3] outgoing connection: 123:192.168.1.78 -> 5.196.160.139:123 || netlink response: 123:0.0.0.0 -> 0.0.0.0:0 inode: 22445
[1/3] outgoing connection: 123:192.168.1.78 -> 5.196.160.139:123 || netlink response: 123:127.0.0.1 -> 0.0.0.0:0 inode: 22449
[2/3] outgoing connection: 123:192.168.1.78 -> 5.196.160.139:123 || netlink response: 123:192.168.1.78 -> 0.0.0.0:0 inode: 129484620 

We can't validate that the results from the kernel match 1:1 the outgoing connection. However, filtering by the source port we can get the inode and be somewhat confident that the PID corresponds to the connection.

There're 4 scenarios where this can occur:

• dhcp or ntpd queries (as shown above), transmission downloads...

ntpd: 123:192.168.1.78 -> 5.196.160.139:123 || netlink response: 123:0.0.0.0 -> 0.0.0.0:0
transmission: 63704:192.168.1.78 -> 90.190.237.215:63842 || netlink response: 63704:0.0.0.0 -> 0.0.0.0:0 inode: 131651945
NetworkManager: 587:fe90::a1af:ee7c:3856:9gf1 -> ff02::1:2:547 || netlink response: 587:fe90::a1af:ee7c:3856:9gf1 -> :::0 inode: 128500914

• broadcasts:

chromium: 5353:192.168.1.78 -> 224.0.0.251:5353 || netlink response: 5353:224.0.0.251 -> 0.0.0.0:0 inode: 131272159
spotify: 56083:172.17.0.1 -> 239.255.255.250:1900 || netlink response: 56083:172.17.0.1 -> 0.0.0.0:0 inode: 131644563

• source port collisions:

33860:127.0.0.1 -> 127.0.0.1:9057 || netlink response: 33860:192.168.1.78 -> 31.13.83.23:443
                      ^                                             ^
                 app A                                            app B

• other cases described in this issue that may or may not be the same case than the source port collision case.

The 3rd case can be reproduced by exhausting source ports of the local system, for example by opening (and not closing) 4k connections to port 9999 (or any other port different from 80/443/etc). After a while, a new pop-up will appear asking to allow a connection to that port from a wrong application.

Apparently (just guessing) the connection entries remain longer in the SOCK_DIAG subsystem than the actual life of the connection, so when a source port is reused by the system, it may still exist in the SOCK_DIAG subsystem.

That said, using eBPF procs monitor method minimized/solves this problem, so I encourange you to use it if you're having this issue.

[gustavo-iniguez-goya]

This issue should be fixed in latest version v1.4.0, with ebpf as process monitor method.