some strange connections (seems like eBPF don't return the original PID of the connection)

[NRGLine4Sec]

There are some strange connections that seem not to be initiated by the processes that make the connection.

These strange connections force me to add new rules that allow the connection so that the package update can be done without problems.

Useful debug logs :

[2022-09-07 16:05:23]  IMP  Added new rule: allow if list is '[{"type": "simple", "operand": "dest.host", "data": "_http._tcp.ppa.launchpad.net"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/egrep"}]'
[2022-09-07 16:05:23]  DBG  ✔ /usr/bin/egrep -> _http._tcp.ppa.launchpad.net:53 (allow-until-restart-list-usr-bin-egrep-http-tcp-ppa-launchpad-net)
[2022-09-07 16:05:24]  DBG  [ebpf] tcp map: 13 active items
[2022-09-07 16:05:24]  DBG  [ebpf] tcp6 map: 38 active items
[2022-09-07 16:05:24]  DBG  [ebpf] udp map: 339 active items
[2022-09-07 16:05:24]  DBG  [ebpf] udp6 map: 4 active items
[2022-09-07 16:05:26]  DBG  [eBPF exec event] ppid: 0, pid: 2399228, /usr/local/bin/grep -> [grep -E -i available dedicated]
[2022-09-07 16:05:26]  DBG  [eBPF exec event] ppid: 0, pid: 2399228, /usr/bin/grep -> [grep -E -i available dedicated]
[2022-09-07 16:05:26]  DBG  [eBPF exec event] ppid: 0, pid: 2399228, /usr/bin/egrep -> [egrep -i available dedicated]
[2022-09-07 16:05:26]  DBG  [eBPF exec event] ppid: 0, pid: 2399232, /usr/bin/zsh -> [zsh]
[2022-09-07 16:05:26]  DBG  [eBPF exec event] ppid: 0, pid: 2399235, /usr/bin/grep -> [grep -q ^ID.*=.*ubuntu /etc/os-release]
[2022-09-07 16:05:26]  DBG  [eBPF exec event] ppid: 0, pid: 2399237, /usr/bin/tput -> [tput setaf 1]
[2022-09-07 16:05:27]  DBG  new connection udp => 51078:172.18.108.243 -> 172.18.0.141:53 uid: 100
[2022-09-07 16:05:27]  DBG  new connection udp => 51078:172.18.108.243 -> 172.18.0.141:53 uid: 100
[2022-09-07 16:05:27]  DBG  UI is not running or busy, connected: true, running: true
[2022-09-07 16:05:28]  DBG  Operator compiled: list is '[{"type": "simple", "operand": "dest.host", "data": "ppa.launchpad.net"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/egrep"}]'
[2022-09-07 16:05:28]  DBG  Operator compiled: dest.host is 'ppa.launchpad.net'
[2022-09-07 16:05:28]  DBG  Operator compiled: process.path is '/usr/bin/egrep'
[2022-09-07 16:05:28]  IMP  Added new rule: allow if list is '[{"type": "simple", "operand": "dest.host", "data": "ppa.launchpad.net"}, {"type": "simple", "operand": "process.path", "data": "/usr/bin/egrep"}]'
[2022-09-07 16:05:28]  DBG  ✔ /usr/bin/egrep -> ppa.launchpad.net:53 (allow-until-restart-list-usr-bin-egrep-ppa-launchpad-net)

In this case it appears after an update of my packages (apt-get upgrade -y). Therefore the binary that makes the connection is certainly : /usr/lib/apt/methods/https

This issue is maybe related to #735.

My configuration :
Distrib : Debian 11
Kernel : 5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.2-1~bpo11+1 (2022-06-14) x86_64 GNU/Linux
Opensnitch version : 1.6.0rc2
Process Monitor Method : eBPF

[gustavo-iniguez-goya]

thank you @NRGLine4Sec . We need at least another log line to log the PID of the connection (tcp.* and udp.* hooks) as seen via ebpf, because right now it's not logged. It should appear after/before "new connection udp".

Did you compile the daemon or are you using it from the packages? I can add a couple of new log lines to further debug this problem, but you would have to compile the daemon.

[NRGLine4Sec]

I installed OpenSnitch from deb packages.

I don't know if this is important, but this is the third time this has happened with the package update.

[gustavo-iniguez-goya]

do you mean that this is the third time that this problem occurs only after update the package? or does it occur on a regular basis/from time to time?

I'll compile the daemon with new debug logs.

[NRGLine4Sec]

What I mean is that so far I've seen it most often while I'm updating packages, but it occur ramdomly.

[gustavo-iniguez-goya]

ok. Could you test this daemon (v1.6.0 master branch)? opensnitchd.gz
Delete the rules for egrep and similar binaries and see if you can reproduce it. Then copy the log file and post it here.

These are the added DEBUG log lines:

[eBPF exit event]
[eBPF exit event inCache]
[connection] ebpf.GetPid:
[ebpf CONN] not in cache, but in execEvents:
[ebpf CONN] in cache:
[ebpf CONN] not in cache, NOR in execEvents:
[ebpf CONN] adding item to cache:

[NRGLine4Sec]

Thanks @gustavo-iniguez-goya
I can see the new lines in the log file now.
I will post the logs if the problem occurs again.

[gustavo-iniguez-goya]

The oddities I mentioned are caused by not intercepting fork/clone syscalls.

On my system after download updates, apt executes apt-listbugs using sh -c:

[eBPF exec event] ppid: 0, pid: 967912, /bin/sh -> [/bin/sh -c /usr/bin/apt-listbugs apt]
[eBPF exec event] ppid: 0, pid: 967914, /bin/dash -> [  dpkg-query -W -f='${Version}' apt-listbugs]

then apt-litsbugs opens a new connection, we intercept it, we get the pid of the connection (967913) but we don't have the process path in cache (because we haven't received it via events, 967913 see above ^):

[ebpf CONN] not in cache, NOR in execEvents: udp59295192.168.1.2341.1.1.153, 967913 ->
[ebpf CONN] adding item to cache: {967913 0 apt-listbugs /usr/bin/ruby3.0 [/usr/bin/ruby /usr/bin/apt-listbugs apt]

After the log "not in cache nor in execevents", we extract the information from /proc/967913/, which is slightly different from the one reported via ebpf (in some cases only).

sh -c foks the process to execute a new process:

969953 vfork( <unfinished ...>
969954 execve("/usr/bin/apt-listbugs", ["/usr/bin/apt-listbugs", "list", "apt-listbugs"]

I added a hook to intercept fork syscalls, but I removed it, don't remember why. Now that I know how to reproduce this case I can reenable it again and see what happens.

[NRGLine4Sec]

Nice finding @gustavo-iniguez-goya !
I don't know if it's the same problem but in any case it's very similar to the one described in #735
Sometimes the process.path is not correct, it is reported as https instead of /usr/lib/apt/methods/https
See these debug lines :

[2022-09-09 06:54:42]  DBG  Operator compiled: list is '[{"type": "simple", "operand": "dest.host", "data": "_https._tcp.download.virtualbox.org"}, {"type": "simple", "operand": "process.path", "data": "https"}]'
[2022-09-09 06:54:42]  DBG  Operator compiled: dest.host is '_https._tcp.download.virtualbox.org'
[2022-09-09 06:54:42]  DBG  Operator compiled: process.path is 'https'
[2022-09-09 06:54:42]  IMP  Added new rule: allow if list is '[{"type": "simple", "operand": "dest.host", "data": "_https._tcp.download.virtualbox.org"}, {"type": "simple", "operand": "process.path", "data": "https"}]'
[2022-09-09 06:54:42]  DBG  ✔ https -> _https._tcp.download.virtualbox.org:53 (allow-until-restart-list-https-https-tcp-download-virtualbox-org)

So we only see in the name of the rule https.

[gustavo-iniguez-goya]

This is a different problem. In this case we're not getting the path of the process, so instead of the path we're using the comm name (/proc/$pid/comm).
Before v1.6.0 these connections were silently discarded applying the DefaultAction configured. I changed the behaviour mainly to catch short-lived processes (fwknop for example), but I'm still not sure if it's a good idea, because sometimes you see these popups.

[NRGLine4Sec]

OK, thank you for the clarification 👍

[gustavo-iniguez-goya]

hey @NRGLine4Sec , any news about this problem? did you see again connections from wrong processes?

I've released a version: https://github.com/evilsocket/opensnitch/releases/tag/v1.6.0-rc.3

I think that it should fix this problem.

[NRGLine4Sec]

Hi @gustavo-iniguez-goya
Sorry for the late reply.
I haven't really paid attention to this bug since and I have done some kernel updates (currently 5.19.0). I will close this issue for now and install the new rc.
I will open a new issue if the problem occurs again.