Multiple Alerts After Blocking PID

[justinormont]

After selecting temporary, and blocking that PID, additional alerts continue for different IP addresses.

Note the same process id keeps popping up with different remote IP addresses.

Expected behavior:

Since I am blocking the PID (even temporarily), I would expect there to be no more alerts for that PID, including if the remote IP address changes.

Possible cause:

Perhaps LuLu isn't checking the newly set rules before each alert?

Config:

• LuLu 2.4.2
• macOS 13.2.1 (22D68)

[mdjunior]

I am investigating this scenario. To simulate this behavior I created a simple Swift application that has a 10 sec timeout and tries to make a connection to a domain that has multiple IP records (because news-edge.apple.com points to a CNAME with a lot of records).

What I observed:

1. LuLu receives the first connection attempt (flow), checks if there are rules and if not, displays an alert.
2. While the alert is being displayed, the application tries to make other connections as it has several records within the DNS record. These flows are placed in "related".
3. When the user makes a decision, the rule is stored with the path and PID of the process. The PID is stored as it is a temporary rule. At this point, storage is confusing as the rules appear to be stored only in memory and not on disk. In the save function we have a comment that says these rules are not saved: https://github.com/objective-see/LuLu/blob/50478cdea08e2e6c1fae935890938eb173aa146b/LuLu/Extension/Rules.m#L937
4. Now LuLu will process the related flows using the path/signing info.
5. The problem is here, because if inside related there is a process with the same path, but a different PID, the rule will not be found and another alert will be displayed. Even if the user interacts with a temporary block or allow, it will not be added/saved as a rule (and we will have new alerts).

In the scenario I simulated here, the first PID showed in alert window is from the current process, but the following are from a previous version of the process. I ask this because I suspect there is a problem with consuming flows that are related, leaving some there and these would only be processed later.

Can you check in the scenario you brought if the first PID shown is different from the others?

[objective-see]

Thank you for this bug report, and @mdjunior thanks for the detailed repo steps! 🙏🏽 ....looking into this, hope to have a fix soon(ish)!

[justinormont]

@mdjunior : Thanks for the investigation.

Can you check in the scenario you brought if the first PID shown is different from the others?

I'll try to take note of the original IP next time it occurs.

[justinormont]

Here is an example where I'm looking to allow the process. You'll note the PID doesn't change, though the remote address changes:

https://github.com/objective-see/LuLu/assets/4080826/6a305b3b-0bd2-4efc-a96d-4e42c220cc01

Repro / command being run: aria2c -s32 -x16 https://download.kiwix.org/zim/wikipedia/wikipedia_en_all_maxi_2024-01.zim.torrent

Issue: There is an endless amount of LuLu alerts.

Expected: Temporarily allowing the PID should allow that PID to make request without further alerts, even with the remote IP address changing.