Hey folks, William unembargoed his nice vuln this week: https://seclists.org/oss-sec/2019/q4/122
It appears to affect basically most common unix network stacks. This isn't a WireGuard vulnerability, but rather something in the routing table code and/or TCP code on affected operating systems. However, it does affect us, since WireGuard exists on those affected OSes. Some might chalk it up to just a configuration error, dismissing it as, "well, if you configure your networking stack poorly, bad things will happen," but I don't really buy that: the network setups affected by this vulnerability are pretty much the norm everywhere. And it turns out that we actually are in the business of properly configuring people's networking stacks. Specifically, the tools we ship come with the little bash script, wg-quick(8), which is a popular way of automating some common tasks. We've started looking at kernel-level mitigations within the Linux networking stack, but before those are ready, I thought it would be prudent to put some first-level defenses into wg-quick(8) itself. For that reason, since November, wg-quick(8) has added a few iptables(8) rules. I really dislike having wg-quick(8) grow any sort of dependency on iptables(8) (and eventually on nftables(8)), but at the moment, I don't see a viable alternative. Suggestions are welcome. In particular, we're adding a rule that is something like: iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP where wg0 is the WireGuard interface and 10.182.12.8 is the local IP of the interface. This says to drop all packets that are sent to that IP address that aren't coming from the WireGuard interface. And it's done very early in Netfilter, in the "raw" table. The researchers have confirmed that this mitigates the issue. Adding iptables(8) into wg-quick(8) has been predictably problematic, and it'll probably be at least another snapshot until we get things bug-free on all the different variations of the utility that distros ship, but we'll get there. In the meantime, I'd certainly appreciate patches to do the same with nftables(8), as well as some fresh thoughts on how to accomplish this same thing _without_ the firewall. (In the process of writing this email, for example, I had an idea regarding ip-rule(8) that might work out, but I haven't tried yet.) We also have some non-Linux operating systems to consider. Feedback welcome. Regards, Jason _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
