3 ms·
The problem is that it's proof that PF firewall can't block all traffic. This essentially means one cannot trust PF to protect themselves from leaking traffic.
by eptcyka 5y ago
The problem is that it's proof that PF firewall can't block all traffic. This essentially means one cannot trust PF to protect themselves from leaking traffic.
- olliej 5y agoIt seems entirely plausible that this is a simple implementation bug. PF is not the thing that does actual networking, on any OS. As far as I understand networking and firewalls like PF, you essentially have the lowest level, where the kernel/driver puts bytes onto the channel. Then you have the various userspace networking interfaces for various transport mechanisms, TCP, UDP, QUIC, etc Each one of those is doing <transport protocol specific thing> <send the bytes> The <send the bytes> part is below where your firewall stuff is going to happen, so I'm going to guess (I have never written kernel level networking because that stuff seems like relentless misery) that it means that every transport implementation has to independently have some code that looks like packet_data = <build the packet> if (auto firewall = current_firewall()) { if (firewall->should_block(packet_data)) return E_BLOCKED; // or whatever } kernel_send_the_bytes_yo(packet_data); Or something like that, all super super pseudo code of course. Anyway, if that general concept is vaguely accurate then that means every time someone brings up a new transport protocol that another opportunity for this to get missed. Not saying its good that such a thing is possible, or that not catching it is ideal, just saying it seems like a plausible path to this kind of bug happening - Hell, I'm not even sure it would be the first case of an OS missing PF, I have some vague recollection from the distant past?