enrico204

Actually, that is not a bad idea. @xena maybe Anubis v2 could make the client participate in some sort of SETI@HOME project, creating the biggest distributed cluster ever created :-D

Isn't that the MCAS warning? /s

Yes, because there are specific exceptions in the GDPR that allow data processing and storage in many of these cases. However, managers are pissed off by the law, or just ignorant, and they make you sign a document that has no legal value.

Heck, many documents that I saw while interacting with P.A. in my country are lacking the basics, such as "what are you doing with the data".

One clinic once made me sign a document where they said that I received a copy of the privacy policy (which was not given to me). I politely asked for the privacy policy, and they sent me the entire GDPR regulation PDF. I spent one hour explaining to them that they need to fix it.

Actually, my idea was to delay e-mails because I don't want to read them during weekends, while I still want to read other e-mails (e.g., newsletters, login alerts). I still open my inbox once per day :-)

Yes, it works on forwarded packets. In the example ruleset in the blog post, `em1` and `em2` are two network interfaces (victim and attacker, think them as LAN and WAN respectively), and the FreeBSD machine is configured as router/firewall.

Fragmentation is a nightmare in a nightmare: we also discovered that IPv6 fragments reassembly (as implemented by major operating systems) is still plagued by the problem of overlapping fragments. Potentially, you can still bypass IDS/IPS using the same techniques from IPv4...

Shameless plug: we will present these results at ESORICS 2023 :-)

Actually, if the router supports RDNSS (DNS info in RA), SLAAC is sufficient for household users -- no need for DHCPv6.

Author here. The ruleset in the blog post is correct. The rationale of the example ruleset is the following: we want to block TCP, UDP and ICMPv6 traffic from the attacker, while allowing other protocols.

Note that IPv6 packets are matched against all rules, while IPv6 fragments are matched against rules that contain network-level information only (as fragments don't have upper layer headers, except for the first fragment).

If the scrubbing is enabled, then `pf` is supposed to reassemble all fragments, so that there is no more fragmented traffic (= all rules are applied to all IPv6 packets). Normally, it works.

In this case, we tricked the firewall by sending an "atomic fragment" that is composed by multiple fragmented headers (this is forbidden by various RFCs). These headers trigger the reassembly mechanism of `pf`, but the packet is "re-assembled" only once: when it enters the rule matcher (after the reassembly), it is still considered a fragment, and all rules with transport-level (and higher) protocol information are skipped.

So, the "block-pass" pair at the end is used to exploit this behavior (in other words, we can decide which rule we match by playing with IPv6 fragment header).

PS: an "atomic fragment" is a IPv6 packet that is fragmented using only one fragment. Surprisingly, it is supported by RFCs.

Author here. I confirm that OPNSense was vulnerable. It has been fixed in v23.7.1 (August 8, 2023): https://forum.opnsense.org/index.php?topic=35298.0

We haven't tested pfSense, but I suppose that they are vulnerable too as they use `pf` and they are FreeBSD-based.

Ooops! Clearly a typo :-)

I've fixed it, the cached version should expire shortly.

Author here. No, OpenBSD's `pf` is not affected.