5 ms·

Donenfeld has been great and makes a wonderful product. We've been using WireGuard as our primary VPN solution for a long time now and don't anticipate a change

Donenfeld has been great and makes a wonderful product. We've been using WireGuard as our primary VPN solution for a long time now and don't anticipate a change anytime soon. I think this class of attack can best be mitigated at the kernel level, but unfortunately, side-channels exist anywhere that maintains state, and this might be a more general routing problem.

zx2c4 7y ago
We're working around this CVE in WireGuard's wg-quick(8) with a rule 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. I don't like having to use iptables in wg-quick(8), and so Willy Tarreau and I have been discussing a deeper kernel-level fix, which should be posted to netdev@ sometime soon.
- Hello71 7y ago
  I was wondering why wireguard suddenly gained a mandatory iptables dependency...
  - zx2c4 7y ago
    Yea... not nice at all. And now we'll probably have to simultaneously support nftables. This isn't a route I really want to go down. Suggestions on alternatives are welcome.
    - flapadar 7y ago
      Could changing route scope from link to host work?
    - tialaramex 7y ago
      How plausible is it to sidestep iptables and inject the rules yourself directly to the kernel's interface? That gets rid of the dependency on a tool which adds friendliness you don't need plus a lot of baggage. It seems as though (correct me if I'm wrong) the CVE requires an attacker to know or guess the target's IP on the VPN, they'll find out if they're right but they don't get a hotter/colder type feedback. So that opens the possibility to play a randomisation game. On IPv4 this is a very marginal benefit. But if a WireGuard client has been given a random 64-bit suffix for some particular IPv6 subnet then unless I misunderstand the attacker needs to probe all such suffixes until they find the correct one, and they can't realistically do that even on a fast network. If I'm right that's a pretty good mitigation (on IPv6).
      - loeg 7y ago
        Yeah, a random v6 address is not guessable, really. But for v4? Start your search with private networks (10./8, 192.168./16, etc) and just enumerate /24s from .1, .2, .3 and I expect more often than not you'll do much better than chance.
    - throwawaynoob 7y ago
      sounds like a perfect candidate for eBPF?
    - vetrom 7y ago
      Two Ideas: 1. Does encouraging ORCHID addresses reduce the impact of enumeration attacks? 2. Linux at least has controllable behavior for cross-interface IP reachability, in arp_filter/arp_announce/arp_ignore per interface sysctls, and ip address scope, as exposed by iproute / netlink. Perhaps its more proper for VPN addresses to be a scope 'link' address, instead of a scope 'host' address. Maybe a 'vpn' scope of some sort could be defined in future kernels, but I'm uncertain what that would do that a scope link address does not?
- zx2c4 7y ago
  I wrote to wgml about it: https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html https://lists.zx2c4.com/pipermail/wireguard/2019-December/00...
- hamandcheese 7y ago
  Won't this break the use case of using Wireguard as a gateway to a private subnet, in the typical many-clients-one-server VPN setup? For example, suppose I have a private physical subnet 10.12.0.0/24 (perhaps in an AWS VPC). I want to allow clients to access to these private hosts using a Wireguard VPN, so I set up a VPN with all clients having IPs from the 10.34.0.0/24. Because I want these clients to have access to the private physical subnet, so each client's config has AllowedIPs = 10.34.0.0/24, 10.12.0.0/24 Which adds both subnets to each client's routing table. I add a new route for the VPC to send all packets destined for 10.34.0.0/24 to the central Wireguard "server", thus the Wireguard server acts as a gateway between the virtual 10.34.0.0 subnet and the physical 10.12.0.0 network. The packets originating from the 10.12.0.0/24 hosts are not local, but I definitely want to route them onto the virtual 10.34.0.0/24 network.
  - tomatocracy 7y ago
    I don't think the filter quoted in parent would stop this. In your example what it would stop is clients in 10.12.0.0/24 from connecting to the IP of the wireguard server itself (but not clients it routes to) on the 10.34.0.0/24 network (but not its IP on the 10.12.0.0/24 subnet).
- kijiki 7y ago
  This might be fixable with the kernel's VRF functionality: https://www.kernel.org/doc/Documentation/networking/vrf.txt https://www.kernel.org/doc/Documentation/networking/vrf.txt

zx2c4 7y ago

We're working around this CVE in WireGuard's wg-quick(8) with a rule 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. I don't like having to use iptables in wg-quick(8), and so Willy Tarreau and I have been discussing a deeper kernel-level fix, which should be posted to netdev@ sometime soon.

Hello71 7y ago
I was wondering why wireguard suddenly gained a mandatory iptables dependency...
- zx2c4 7y ago
  Yea... not nice at all. And now we'll probably have to simultaneously support nftables. This isn't a route I really want to go down. Suggestions on alternatives are welcome.
  - flapadar 7y ago
    Could changing route scope from link to host work?
  - tialaramex 7y ago
    How plausible is it to sidestep iptables and inject the rules yourself directly to the kernel's interface? That gets rid of the dependency on a tool which adds friendliness you don't need plus a lot of baggage. It seems as though (correct me if I'm wrong) the CVE requires an attacker to know or guess the target's IP on the VPN, they'll find out if they're right but they don't get a hotter/colder type feedback. So that opens the possibility to play a randomisation game. On IPv4 this is a very marginal benefit. But if a WireGuard client has been given a random 64-bit suffix for some particular IPv6 subnet then unless I misunderstand the attacker needs to probe all such suffixes until they find the correct one, and they can't realistically do that even on a fast network. If I'm right that's a pretty good mitigation (on IPv6).
    - loeg 7y ago
      Yeah, a random v6 address is not guessable, really. But for v4? Start your search with private networks (10./8, 192.168./16, etc) and just enumerate /24s from .1, .2, .3 and I expect more often than not you'll do much better than chance.
  - throwawaynoob 7y ago
    sounds like a perfect candidate for eBPF?
  - vetrom 7y ago
    Two Ideas: 1. Does encouraging ORCHID addresses reduce the impact of enumeration attacks? 2. Linux at least has controllable behavior for cross-interface IP reachability, in arp_filter/arp_announce/arp_ignore per interface sysctls, and ip address scope, as exposed by iproute / netlink. Perhaps its more proper for VPN addresses to be a scope 'link' address, instead of a scope 'host' address. Maybe a 'vpn' scope of some sort could be defined in future kernels, but I'm uncertain what that would do that a scope link address does not?
zx2c4 7y ago
I wrote to wgml about it: https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html https://lists.zx2c4.com/pipermail/wireguard/2019-December/00...
hamandcheese 7y ago
Won't this break the use case of using Wireguard as a gateway to a private subnet, in the typical many-clients-one-server VPN setup? For example, suppose I have a private physical subnet 10.12.0.0/24 (perhaps in an AWS VPC). I want to allow clients to access to these private hosts using a Wireguard VPN, so I set up a VPN with all clients having IPs from the 10.34.0.0/24. Because I want these clients to have access to the private physical subnet, so each client's config has AllowedIPs = 10.34.0.0/24, 10.12.0.0/24 Which adds both subnets to each client's routing table. I add a new route for the VPC to send all packets destined for 10.34.0.0/24 to the central Wireguard "server", thus the Wireguard server acts as a gateway between the virtual 10.34.0.0 subnet and the physical 10.12.0.0 network. The packets originating from the 10.12.0.0/24 hosts are not local, but I definitely want to route them onto the virtual 10.34.0.0/24 network.
- tomatocracy 7y ago
  I don't think the filter quoted in parent would stop this. In your example what it would stop is clients in 10.12.0.0/24 from connecting to the IP of the wireguard server itself (but not clients it routes to) on the 10.34.0.0/24 network (but not its IP on the 10.12.0.0/24 subnet).
kijiki 7y ago
This might be fixable with the kernel's VRF functionality: https://www.kernel.org/doc/Documentation/networking/vrf.txt https://www.kernel.org/doc/Documentation/networking/vrf.txt