[Bug Report] proc method misattributes short-lived processes to random'ish applications

[jaggzh]

Describe the bug:

• "Random" programs are popping up being reported for hitting one of my LAN-IPs (and those programs most certainly are not).
• They are often consistent (showing the same program repeatedly, maybe even every few minutes).
• Weeks ago I swear one was not even running at the time!
• Then weeks might go by without me noticing a popup window at all.
• Debian (testing)-packaged opensnitch v1.6.9
• KDE
• 6.12.38+deb13-amd64

To reproduce

• Switch to "ProcMonitorMethod": "proc" (the issue timing likely correlates with my switch to proc (to reduce cpu load of opensnitchd))
• Use a short-lived application that handles and closes the connection immediately. *(My cron-based curl hits an IoT device once a minute to get status (the curl process itself runs for <100ms)).
• Note: I haven't been able to manually induce it, and I don't see it for many days or weeks at a time, even with my curl going every minute.

Hypothesis:

What I think is happening is that opensnitchd is receiving the NFQUEUE (or whatever) packets, and because it's a short-lived process, sometimes it might not find it in /proc when it goes to cross-reference the tuples. Then, we have some bug or a limitation where it doesn't know how to detect this, or some other bug where perhaps it has a fallback algorithm that does something wonky, and chooses some other application in the system. In any case, instead of reporting "Unknown application" / "Application not found in /proc for src.ip:src.port / dst.ip:dst.port", it is somehow choosing an application to falsely-present as the maker of the connection.

Expected behavior (optional):

Normal UI window should pop up, but there should be an indicator of the application not being found (if that's the issue).
Ideally it would also point out, "we do have a rule matching this dst.ip:dst.port".
However, regardless, we shouldn't misattribute it to some other "innocent" program. :)

Additional context:

Some weeks ago it was showing the connections made from arduino-cli (which wasn't running for quite some time (I imagine arduino IDE uses arduino-cli, but neither were running). Today it was showing it with my IRC client (which has no awareness of my IoT device).

I know I don't have to beat you over the head with this, as a really bad behavior for security software but.. man.. I thought I might have been hacked, and set about validating my packages' files' integrity and stuff. (And it wasn't only those two applications being reported as doing it.)

Also, I noticed in your FAQ that some OS's only support the proc method (eBPF unavailable). In those cases, the users are stuck not only with an untrustworthy report, but one making false claims, so I felt it worthy to analyze and bring to your attention.

[gustavo-iniguez-goya]

Hi @jaggzh ,

You're right, this can happen sometimes with v1.6.x. In v1.7.0 we added the ability to intercept new process executions when using proc and changed how we intercept outbound connections, so it should work better.

This behaviour is not gooing to be fixed for v1.6.9. Try v1.7.2 and see if you can reproduce it.