Whonix-Gateway Firewall `/usr/libexec/whonix-firewall/enable-firewall` `firewall_lockdown` function nftables non-atomicity security report [AI assisted]

Development
1

Understand. Agree with low impact. Think maybe reporting docs can be updated, to describe what not to send. Will not send any low impact or bugs requiring Gateway malware in future.

For external readers, will describe reported bug, so they know to avoid reporting similar low impacts:

https://github.com/Whonix/whonix-firewall/blob/master/usr/libexec/whonix-firewall/enable-firewall#L53-L69

whonix-firewall lockdown is not atomic. Small window where clearnet traffic can pass. Workstation not affected. Gateway malware can constantly ping its own server and detect clearnet IP of the user. Gateway malware unlikely, lockdown function being called unlikely, low impact.

Worth fixing, I believe. For same reason you added user-sysmaint-split to Gateway, when before it was not split. Even though Gateway malware unlikely, defense in depth.

Whonix AI security usage?
2

Sending low-impact stuff is fine. Worst-case scenario, we disagree that something is a vulnerability and explain why.

The lockdown only gets called if something goes wrong while trying to apply the firewall. Up until the firewall is applied, everything is (kind of, but not really) wide-open already. The lockdown function’s goal is to fix this as quickly and thoroughly as possible. Changing it to be atomic would a) slow it down, increasing the amount of time the system is (kind of, but not really) wide open, and b) refuse to partially apply the lockdown if anything goes wrong during the lockdown process, introducing the potential for the lockdown to fail catastrophically. Non-atomic application is safer than atomic here and is done by design.

The usual firewall application is done atomically, since that firewall configuration needs to be entirely applied to be safe. If it can’t be entirely applied, the lockdown has to be applied as much as possible.

Both the normal firewall application and the lockdown application are done before network-pre.target comes up (see whonix-firewall/usr/lib/systemd/system/whonix-firewall.service at master · Whonix/whonix-firewall · GitHub), so the period of time the system is wide-open isn’t really a problem since the network won’t be up yet. The exception would be if malware was in the gateway and managed to set up a network connection before network-pre.target and whonix-firewall.service did their work, in which case malware could circumvent an atomic firewall application too. Root-level infection of the gateway = anonymity compromise, there is no reasonable way around this. Even non-root infection of the gateway = likely anonymity compromise. That’s why the gateway and workstation are separated.

1 Like
3

It can run with network up normally. Firewall-restarter. whonix-firewall/usr/lib/systemd/system/whonix-firewall-restarter.service at master · Whonix/whonix-firewall · GitHub Waits for sdwdate and restarts firewall. whonix-firewall/usr/libexec/whonix-firewall/firewall-restarter at master · Whonix/whonix-firewall · GitHub. But would need pre-network success, then config change to invalidate reload between that time, then restart failure.

Other scenario: user can edit config to invalid state on accident, then call systemctl restart whonix-firewall, while network up. Then lockdown called and leak occurs with network. Requires sysmaint mode. Leak being exploited might require a daemon compromise. Almost impossible. But not zero.

b) make sense to me. Think you are right. GLM-5.3 suggested add only. Said keeping old rules was acceptable, would not bypass block rules at -300 priority, and add-only fixes leak problem. I do not want to know. Think it is not productive to verify. You are likely right, it is likely wrong.

    ${nftables_cmd} add table inet filter 2>/dev/null || true
  
    ${nftables_cmd} "add chain inet filter lockdown_input   { type filter hook input   priority -300; policy drop; }" 2>/dev/null || true
    ${nftables_cmd} "add chain inet filter lockdown_forward { type filter hook forward priority -300; policy drop; }" 2>/dev/null || true
    ${nftables_cmd} "add chain inet filter lockdown_output  { type filter hook output  priority -300; policy drop; }" 2>/dev/null || true

Will not look any further. Likely this issue is waste of time. Accepting your decision.

1 Like
4

Hmm, that’s a good point. If there’s a working firewall in place, the lockdown mechanism will strip that away momentarily before applying lockdown in the event of a firewall restart failure. In that instance applying atomically would be the better option. There wouldn’t be a risk of catastrophic failure because a working firewall would already be loaded.

That raises the question of whether it even makes sense to call firewall_lockdown if firewall application fails during a firewall restart. It makes sense during initial bootup, but during a restart, it will take a working network connection with a working firewall and turn it into a broken network connection. Arguably it would be better to just keep the existing firewall if the new one can’t be loaded.

1 Like