Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[zrm]

On 12/5/19 14:13, Jason A. Donenfeld wrote:
> 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
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
> 

One possibility that comes to mind is to add a new rpfilter mode between 
loose and strict that accepts packets from any interface with a route to 
that destination (like "loose"), but only if the route prefix is the 
same as the route that would be used for outgoing packets. That captures 
nearly the entire use case for "loose" (specifically the major case of 
multiple default routes) but then if you have a more specific route to a 
destination via a VPN interface, packets from that subnet are not 
accepted via a different interface just because that interface has a 
default route.

That leaves the case where the route through the VPN interface *is* a 
default route, but that could be solved by making it the *only* default 
route, which is desirable in general so that if the VPN interface is 
temporarily offline packets meant to be sent via the VPN don't use some 
other interface.

What's left of the attack after that is being able to determine the IP 
address assigned to another interface like the VPN interface. That one's 
hard because it's often legitimate -- if you have a multi-homed router 
and an internal host tries to connect to the public address of the 
external interface, you generally want it to actually work. It's also 
not clear if it's a huge problem on its own, particularly since you can 
still solve it with a firewall rule in cases where it's considered 
problematic.

Although we do have this text from the announcement: "Also,
even with reverse path filtering on strict mode, the first two parts of
the attack can be completed, allowing the AP to make inferences about
active connections, and we believe it may be possible to carry out the
entire attack, but haven’t accomplished this yet." Does anybody see how 
that would work? In rpfilter strict mode a spoofed packet for a 
connection routed via the VPN interface which is received via some other 
interface should be dropped before giving any indication whether it's 
for an active connection, shouldn't it?