* Regarding "Inferring and hijacking VPN-tunneled TCP connections" @ 2019-12-05 19:13 Jason A. Donenfeld 2019-12-05 19:50 ` Vasili Pupkin 2019-12-05 20:10 ` zrm 0 siblings, 2 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2019-12-05 19:13 UTC (permalink / raw) To: WireGuard mailing list 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@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 19:13 Regarding "Inferring and hijacking VPN-tunneled TCP connections" Jason A. Donenfeld @ 2019-12-05 19:50 ` Vasili Pupkin 2019-12-05 20:24 ` Jason A. Donenfeld 2019-12-05 20:10 ` zrm 1 sibling, 1 reply; 14+ messages in thread From: Vasili Pupkin @ 2019-12-05 19:50 UTC (permalink / raw) To: Jason A. Donenfeld, WireGuard mailing list Isn't it enough to just enforce Strong Host Model, i.e. a host won't respond from it's IP that is not facing the interface. If a host is connected to two subnets 10.1.x.x and 10.2.x.x and have two IP 10.1.0.1 and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 that came from the interface 10.2.0.1 and vice verse. This model can be emulated using the FIB lookup feature of NFT with this one liner: nft add rule inet filter input fib daddr . iif type != { local, broadcast, multicast } drop this also works for both IP4 and IP6. This mode can be safely enabled on most setups not breaking things. Enabling it is a good precaution measure anyway and it is a shame that it is not widely assumed as default and standard. Doing the same with just iptables isn't easy and can't be accomplished with one liner but nft perfectly coexist with iptables. On 05.12.2019 22: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@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 19:50 ` Vasili Pupkin @ 2019-12-05 20:24 ` Jason A. Donenfeld 2019-12-05 21:28 ` Vasili Pupkin ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2019-12-05 20:24 UTC (permalink / raw) To: Vasili Pupkin, William J. Tolley; +Cc: WireGuard mailing list Hey Vasili, On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com> wrote: > Isn't it enough to just enforce Strong Host Model, i.e. a host won't > respond from it's IP that is not facing the interface. If a host is > connected to two subnets 10.1.x.x and 10.2.x.x and have two IP 10.1.0.1 > and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 that > came from the interface 10.2.0.1 and vice verse. This model can be > emulated using the FIB lookup feature of NFT with this one liner: > > nft add rule inet filter input fib daddr . iif type != { local, > broadcast, multicast } drop > > this also works for both IP4 and IP6. This mode can be safely enabled on > most setups not breaking things. Enabling it is a good precaution > measure anyway and it is a shame that it is not widely assumed as > default and standard. > > Doing the same with just iptables isn't easy and can't be accomplished > with one liner but nft perfectly coexist with iptables. > That actually appears to work pretty well in my quick bootleg setup. Thanks. I'm adding William to the email chain -- perhaps he can try this and report back with his attack rig? If we can make nft coexistance work reliably, perhaps we can run the nft rule on systems where the nft binary simply exists. For cleanup, we'll need some way of marking that rule as belonging to wg-quick(8) for our interface. The iptables magic currently uses --comment for that. There's also the issue with nft not having default table and chain names. Perhaps it'd be cleanest to just ad a new table and chain with a given name, and set that as a high priority input hook? We'll also probably want to make this only apply to our interface, and not others, if that's possible. Any downsides I'm overlooking? William -- you might want to subscribe to follow along better: https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html https://lists.zx2c4.com/mailman/listinfo/wireguard _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 20:24 ` Jason A. Donenfeld @ 2019-12-05 21:28 ` Vasili Pupkin 2019-12-06 15:18 ` Jason A. Donenfeld 2019-12-06 12:58 ` William J. Tolley 2019-12-06 15:06 ` Jordan Glover 2 siblings, 1 reply; 14+ messages in thread From: Vasili Pupkin @ 2019-12-05 21:28 UTC (permalink / raw) To: Jason A. Donenfeld, William J. Tolley; +Cc: WireGuard mailing list On 05.12.2019 23:24, Jason A. Donenfeld wrote: > Hey Vasili, > > On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com> wrote: >> Isn't it enough to just enforce Strong Host Model, i.e. a host won't >> respond from it's IP that is not facing the interface. If a host is >> connected to two subnets 10.1.x.x and 10.2.x.x and have two IP 10.1.0.1 >> and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 that >> came from the interface 10.2.0.1 and vice verse. This model can be >> emulated using the FIB lookup feature of NFT with this one liner: >> >> nft add rule inet filter input fib daddr . iif type != { local, >> broadcast, multicast } drop >> >> this also works for both IP4 and IP6. This mode can be safely enabled on >> most setups not breaking things. Enabling it is a good precaution >> measure anyway and it is a shame that it is not widely assumed as >> default and standard. >> >> Doing the same with just iptables isn't easy and can't be accomplished >> with one liner but nft perfectly coexist with iptables. >> > That actually appears to work pretty well in my quick bootleg setup. > Thanks. I'm adding William to the email chain -- perhaps he can try > this and report back with his attack rig? > > If we can make nft coexistance work reliably, perhaps we can run the > nft rule on systems where the nft binary simply exists. > > For cleanup, we'll need some way of marking that rule as belonging to > wg-quick(8) for our interface. The iptables magic currently uses > --comment for that. > > There's also the issue with nft not having default table and chain > names. Perhaps it'd be cleanest to just ad a new table and chain with > a given name, and set that as a high priority input hook? > > We'll also probably want to make this only apply to our interface, and > not others, if that's possible. > > Any downsides I'm overlooking? > > William -- you might want to subscribe to follow along better: > https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html > https://lists.zx2c4.com/mailman/listinfo/wireguard > I've just figured out that the same effect can also be achieved with iptables: iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type LOCAL -j DROP So it is very similar to your solution. It is not exactly the same to nft oneliner, because it drops multicast and broadcast packets, this can probably be fixed though the multiple -j jumps, I am not an expert in this though: iptables -t filter -N NOTLOCAL iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type LOCAL -j NOTLOCAL iptables -t filter -I NOTLOCAL -m addrtype --limit-iface-in ! --dst-type MULTICAST -j DROP It should also be dubbed with ip6tables command to also filter IP6 packets. There can possibly be systems where only nftables is installed and there is no iptables though. In any case you can limit it to just one wireguard interface. It is a good precaution measure to enable it systemwide and rule out the CVE-2019-14899 completely and many other possible attacks. The weak host model used in linux by default is literally weak and a good system administrator should avoid it by all means. But for the sake of wg-quick the filter can be enables for wireguard interface only to be sure it wouldn't break anything else and in this case you can probably also ignore multicasts and broadcasts. One can possibly has a sophisticated firewall rule that only accept some packets and his firewall will unintentionally dodge packets around our rules and I don't see how this can be avoided. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 21:28 ` Vasili Pupkin @ 2019-12-06 15:18 ` Jason A. Donenfeld 2019-12-06 17:21 ` Vasili Pupkin 2019-12-07 20:51 ` Lonnie Abelbeck 0 siblings, 2 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2019-12-06 15:18 UTC (permalink / raw) To: Vasili Pupkin; +Cc: William J. Tolley, WireGuard mailing list Hi Vasili, On Thu, Dec 5, 2019 at 10:28 PM Vasili Pupkin <diggest@gmail.com> wrote: > I've just figured out that the same effect can also be achieved with > iptables: > iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type > LOCAL -j DROP Neat trick, but it still requires this to run on all incoming packets from all interfaces, right? In other words, it enables a strong host model for the whole system instead of just with regards to addresses "owned" by the WireGuard interface. Adding support for the latter would get us back to the original rule we're using right now, right? > But for the sake of wg-quick > the filter can be enables for wireguard interface only to be sure it > wouldn't break anything else How do you propose this works? That'd require adding -d, right? In that case we're back to more or less the original rule. If you do it with -i, then it fails to filter the bad packets that we want to be filtering. Jason _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-06 15:18 ` Jason A. Donenfeld @ 2019-12-06 17:21 ` Vasili Pupkin 2019-12-07 20:51 ` Lonnie Abelbeck 1 sibling, 0 replies; 14+ messages in thread From: Vasili Pupkin @ 2019-12-06 17:21 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: William J. Tolley, WireGuard mailing list On 06.12.2019 18:18, Jason A. Donenfeld wrote: > >> But for the sake of wg-quick >> the filter can be enables for wireguard interface only to be sure it >> wouldn't break anything else > How do you propose this works? That'd require adding -d, right? In > that case we're back to more or less the original rule. If you do it > with -i, then it fails to filter the bad packets that we want to be > filtering. Actually it appears to be harder than I first think The -d option will let broadcast addresses to pass the rule. Is it a problem here? In the original bulletin authors talk about TCP. Testing for interface name doesn't make much sense either, as you said... _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-06 15:18 ` Jason A. Donenfeld 2019-12-06 17:21 ` Vasili Pupkin @ 2019-12-07 20:51 ` Lonnie Abelbeck 1 sibling, 0 replies; 14+ messages in thread From: Lonnie Abelbeck @ 2019-12-07 20:51 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: William J. Tolley, WireGuard mailing list > On Dec 6, 2019, at 9:18 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hi Vasili, > > On Thu, Dec 5, 2019 at 10:28 PM Vasili Pupkin <diggest@gmail.com> wrote: >> I've just figured out that the same effect can also be achieved with >> iptables: >> iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type >> LOCAL -j DROP > > Neat trick, but it still requires this to run on all incoming packets > from all interfaces, right? In other words, it enables a strong host > model for the whole system instead of just with regards to addresses > "owned" by the WireGuard interface. Adding support for the latter > would get us back to the original rule we're using right now, right? For what its worth, if some sort of basic firewall with conntrack is enabled, Step 1 of the attack is blocked with a "ctstate INVALID" rule. Per testing in the lab, using attack "nping --tcp --flags SA ..." For Example, VALID_CHK in the (external facing) INPUT and FORWARD chains: -- -A VALID_CHK -m conntrack --ctstate INVALID -j DROP -- for both iptables and ip6tables filter tables. Is it common some sort of basic firewall with conntrack is not enabled ? Lonnie _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 20:24 ` Jason A. Donenfeld 2019-12-05 21:28 ` Vasili Pupkin @ 2019-12-06 12:58 ` William J. Tolley 2019-12-06 15:06 ` Jordan Glover 2 siblings, 0 replies; 14+ messages in thread From: William J. Tolley @ 2019-12-06 12:58 UTC (permalink / raw) To: Jason A. Donenfeld, Vasili Pupkin; +Cc: WireGuard mailing list Hi all, So the nft rule worked flawlessly on our Ubuntu machines, but I'm having trouble applying the rule in Manjaro (undoubtedly user error). I'll try again on some different machines in the lab. Addressing zrm's question about carrying out the first two parts of the attack with rp_filter is strict mode - it should have been clarified that, as far as we know, this only affects certain systems with sufficiently complicated and/or misconfigured routing rules using connmarks and fwmarks, such as Android. The patch was issued for Android in the September security update, however, I can still perform the attack without any modification. The difference now is that if I manually set rp_filter to strict on Android I can prevent the attack for IPv4 etc. Before this update, it would basically respond to any spoofed packets addressed to the virtual interface IP on the wireless and/or mobile interface(s). This is CVE-2019-9461. Thanks, Wm. On Thu, 2019-12-05 at 21:24 +0100, Jason A. Donenfeld wrote: > Hey Vasili, > > On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com> > wrote: > > Isn't it enough to just enforce Strong Host Model, i.e. a host > > won't > > respond from it's IP that is not facing the interface. If a host is > > connected to two subnets 10.1.x.x and 10.2.x.x and have two IP > > 10.1.0.1 > > and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 > > that > > came from the interface 10.2.0.1 and vice verse. This model can be > > emulated using the FIB lookup feature of NFT with this one liner: > > > > nft add rule inet filter input fib daddr . iif type != { local, > > broadcast, multicast } drop > > > > this also works for both IP4 and IP6. This mode can be safely > > enabled on > > most setups not breaking things. Enabling it is a good precaution > > measure anyway and it is a shame that it is not widely assumed as > > default and standard. > > > > Doing the same with just iptables isn't easy and can't be > > accomplished > > with one liner but nft perfectly coexist with iptables. > > > > That actually appears to work pretty well in my quick bootleg setup. > Thanks. I'm adding William to the email chain -- perhaps he can try > this and report back with his attack rig? > > If we can make nft coexistance work reliably, perhaps we can run the > nft rule on systems where the nft binary simply exists. > > For cleanup, we'll need some way of marking that rule as belonging to > wg-quick(8) for our interface. The iptables magic currently uses > --comment for that. > > There's also the issue with nft not having default table and chain > names. Perhaps it'd be cleanest to just ad a new table and chain with > a given name, and set that as a high priority input hook? > > We'll also probably want to make this only apply to our interface, > and > not others, if that's possible. > > Any downsides I'm overlooking? > > William -- you might want to subscribe to follow along better: > https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html > https://lists.zx2c4.com/mailman/listinfo/wireguard _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 20:24 ` Jason A. Donenfeld 2019-12-05 21:28 ` Vasili Pupkin 2019-12-06 12:58 ` William J. Tolley @ 2019-12-06 15:06 ` Jordan Glover 2019-12-06 15:08 ` Jason A. Donenfeld 2 siblings, 1 reply; 14+ messages in thread From: Jordan Glover @ 2019-12-06 15:06 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: William J. Tolley, WireGuard mailing list On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > If we can make nft coexistance work reliably, perhaps we can run the > nft rule on systems where the nft binary simply exists. > Will this work correctly on systems where nft binary exist but only iptables rules are used? Jordan _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-06 15:06 ` Jordan Glover @ 2019-12-06 15:08 ` Jason A. Donenfeld 2019-12-06 16:03 ` Vasili Pupkin 0 siblings, 1 reply; 14+ messages in thread From: Jason A. Donenfeld @ 2019-12-06 15:08 UTC (permalink / raw) To: Jordan Glover; +Cc: William J. Tolley, WireGuard mailing list On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover <Golden_Miller83@protonmail.ch> wrote: > > On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > > If we can make nft coexistance work reliably, perhaps we can run the > > nft rule on systems where the nft binary simply exists. > > > > Will this work correctly on systems where nft binary exist but only > iptables rules are used? That's what I meant by, "if we can make nft coexistance work reliably." _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-06 15:08 ` Jason A. Donenfeld @ 2019-12-06 16:03 ` Vasili Pupkin 2019-12-06 16:12 ` Jordan Glover 0 siblings, 1 reply; 14+ messages in thread From: Vasili Pupkin @ 2019-12-06 16:03 UTC (permalink / raw) To: Jason A. Donenfeld, Jordan Glover Cc: William J. Tolley, WireGuard mailing list On 06.12.2019 18:08, Jason A. Donenfeld wrote: > On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover > <Golden_Miller83@protonmail.ch> wrote: >> On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: >> >>> If we can make nft coexistance work reliably, perhaps we can run the >>> nft rule on systems where the nft binary simply exists. >>> >> Will this work correctly on systems where nft binary exist but only >> iptables rules are used? > That's what I meant by, "if we can make nft coexistance work reliably." > Take a look at the table on the bottom of this page https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F On my system their rules coexist fine. Both nftables and iptables are just high level interfaces to kernel netfilter hooks after all, if either of them drop the packet then the packet is dropped. It is also possible to write the same filter using iptables, not as easy and not as beautiful as nft though. Finally wireguard can do this directly interacting with netfilter as the last resort. I'd like if kernel developers reconsider the default system behavior on this... It is so stupid that the system expose all its IPs on all interfaces by default. But Linus don't like patches that break things and this will break some bad network setups, yes weak and insecure but still. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-06 16:03 ` Vasili Pupkin @ 2019-12-06 16:12 ` Jordan Glover 2019-12-06 17:06 ` Vasili Pupkin 0 siblings, 1 reply; 14+ messages in thread From: Jordan Glover @ 2019-12-06 16:12 UTC (permalink / raw) To: Vasili Pupkin; +Cc: William J. Tolley, WireGuard mailing list On Friday, December 6, 2019 4:03 PM, Vasili Pupkin <diggest@gmail.com> wrote: > On 06.12.2019 18:08, Jason A. Donenfeld wrote: > > > On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover > > Golden_Miller83@protonmail.ch wrote: > > > > > On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld Jason@zx2c4.com wrote: > > > > > > > If we can make nft coexistance work reliably, perhaps we can run the > > > > nft rule on systems where the nft binary simply exists. > > > > > > Will this work correctly on systems where nft binary exist but only > > > iptables rules are used? > > > That's what I meant by, "if we can make nft coexistance work reliably." > > Take a look at the table on the bottom of this page > https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F > > On my system their rules coexist fine. Both nftables and iptables are > just high level interfaces to kernel netfilter hooks after all, if > either of them drop the packet then the packet is dropped. It is also > possible to write the same filter using iptables, not as easy and not as > beautiful as nft though. Finally wireguard can do this directly > interacting with netfilter as the last resort. But nft rule won't be visible from iptables tools like iptables-save, right? This may be confusing for people who still use iptables for setting up firewall on their systems. Jordan _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-06 16:12 ` Jordan Glover @ 2019-12-06 17:06 ` Vasili Pupkin 0 siblings, 0 replies; 14+ messages in thread From: Vasili Pupkin @ 2019-12-06 17:06 UTC (permalink / raw) To: Jordan Glover; +Cc: William J. Tolley, WireGuard mailing list On 06.12.2019 19:12, Jordan Glover wrote: > But nft rule won't be visible from iptables tools like iptables-save, > right? This may be confusing for people who still use iptables for > setting up firewall on their systems. > Right. And for those using NFT, they will see a strange rule in their default inet filter table. Also nft users may delete this table or its input chain or alter the chain hook specification before calling wg-quick and in this case the magic command will crash. So it should be added to wireguard specific table instead of inet filter and this is actually the only easy way to revert the ruleset in nft, you should delete your table to revert the changes. nft add table inet $table nft add chain inet $table input {' type filter hook input priority 0; policy accept; '} nft add rule inet $table input fib daddr . iif type != { local, broadcast, multicast } drop and then: nft delete table inet $table when we are done. _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections" 2019-12-05 19:13 Regarding "Inferring and hijacking VPN-tunneled TCP connections" Jason A. Donenfeld 2019-12-05 19:50 ` Vasili Pupkin @ 2019-12-05 20:10 ` zrm 1 sibling, 0 replies; 14+ messages in thread From: zrm @ 2019-12-05 20:10 UTC (permalink / raw) To: wireguard 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@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? _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-12-07 20:52 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-05 19:13 Regarding "Inferring and hijacking VPN-tunneled TCP connections" Jason A. Donenfeld 2019-12-05 19:50 ` Vasili Pupkin 2019-12-05 20:24 ` Jason A. Donenfeld 2019-12-05 21:28 ` Vasili Pupkin 2019-12-06 15:18 ` Jason A. Donenfeld 2019-12-06 17:21 ` Vasili Pupkin 2019-12-07 20:51 ` Lonnie Abelbeck 2019-12-06 12:58 ` William J. Tolley 2019-12-06 15:06 ` Jordan Glover 2019-12-06 15:08 ` Jason A. Donenfeld 2019-12-06 16:03 ` Vasili Pupkin 2019-12-06 16:12 ` Jordan Glover 2019-12-06 17:06 ` Vasili Pupkin 2019-12-05 20:10 ` zrm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).