Re: [ANNOUNCE] WireGuard Snapshot `0.0.20191205` Available
On Friday, December 6, 2019 5:35 PM, Jason A. Donenfeld wrote: > Looks like an arch problem or a libnftnl problem. I've made a minimal > reproducer: > > printf 'filter\nCOMMIT\nraw\nCOMMIT\n*mangle\nCOMMIT\n' | sudo > iptables-nft-restore -n > > I filed a bug report on Arch: https://bugs.archlinux.org/task/64755 > You can follow up with them. I tried to compile myself iptables 1.8.4 which is latest upstream version and have good and bad news: The good one is your minimal reproducer no longer causes segfault. The bad one is wg-quick still does: wg-quick[2325]: [#] iptables-restore -n audit[2326]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj==unconfined pid=2326 comm="iptables-restor" exe="/usr/bin/xtables-nft-multi" sig=11 res=1 wg-quick[2325]: /usr/bin/wg-quick: line 29: 2326 Segmentation fault (core dumped) "$@" kernel: show_signal_msg: 40 callbacks suppressed kernel: iptables-restor[2326]: segfault at 0 ip 69bb4df13cc9 sp 716fcc5b9b30 error 4 in libnftnl.so.11.2.0[69bb4df11000+18000] kernel: Code: 15 5c 20 02 00 48 85 c0 74 07 48 89 00 48 89 40 08 48 83 c4 08 c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 48 83 ec 08 <48> 8b 3f 48 8b 1f 48 39 fd 74 2f 0f 1f 40 00 48 8b 47 08 48 89 43 Maybe upstream found and fixed some regression but still missed the other one. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On Tuesday, December 10, 2019 7:15 PM, Jason A. Donenfeld wrote: > On Tue, Dec 10, 2019 at 7:58 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld ja...@zx2c4.com > > wrote: > > > > > On the other hand, if what you say is actually true in our case, and > > > nftables is utter crap, then perhaps we should scrap this nft(8) patch > > > all together and just keep pure iptables(8). DKG - you seemed to want > > > nft(8) support, though. How would you feel about that sort of > > > conclusion? > > > Jason > > > > The only scenario where you really want to use nft is where iptables command > > doesn't exist. I don't know how realistic scenario it is but I assume it can > > happen in the wild. Otherwise calling iptables will take care of both > > iptables > > and nftables automatically if those are supported on system. That's why I > > proposed to invert current patch logic. > > I reason about things a bit differently. For me, the decision is > between these two categories: > > A) iptables-nft points to iptables and is available for people who > want a nft-only system. So, code against the iptables API, and mandate > that users either have iptables or iptables-nft installed, which isn't > unreasonable, considering the easy availability of each. > > B) nft is the future and should be used whenever available. Support > iptables as a fallback though for old systems, and remove it as soon > as we can. > > Attitudes that fall somewhere between (A) and (B) are much less > interesting to me. Isn't future goal to drop those firewall hacks altogether? The future of nft may be irrelevant then and effort should go for iptables which works on more systems Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On Tuesday, December 10, 2019 5:36 PM, Jason A. Donenfeld wrote: > > On the other hand, if what you say is actually true in our case, and > nftables is utter crap, then perhaps we should scrap this nft(8) patch > all together and just keep pure iptables(8). DKG - you seemed to want > nft(8) support, though. How would you feel about that sort of > conclusion? > > Jason The only scenario where you really want to use nft is where iptables command doesn't exist. I don't know how realistic scenario it is but I assume it can happen in the wild. Otherwise calling iptables will take care of both iptables and nftables automatically if those are supported on system. That's why I proposed to invert current patch logic. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On Tuesday, December 10, 2019 4:54 PM, Jason A. Donenfeld wrote: > On Tue, Dec 10, 2019 at 5:52 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > On Tuesday, December 10, 2019 3:48 PM, Jason A. Donenfeld ja...@zx2c4.com > > wrote: > > > > > If nft(8) is installed, use it. These rules should be identical to the > > > iptables-restore(8) ones, with the advantage that cleanup is easy > > > because we use custom table names. > > > > I wonder if nft should be used only if iptables isn't installed instead. > > Nowadays iptables has nft backend which I believe is default and will > > translate iptables rules to nft automatically. On my system iptables rules > > from wg-quck are already shown in "nft list ruleset". > > I'm not sure if this work in reverse - are nft rules automatically > > translated > > to iptables and shown in iptables-save? If not then using iptables of > > available > > seems more versatile for the job. > > iptables rules and nftables rules can co-exist just fine, without any > translation needed. Indeed if your iptables is symlinked to > iptables-nft, then you'll insert nftables rules when you try to insert > iptables rules, but it really doesn't matter much either way (AFAIK). > I figured I'd prefer nftables over iptables if available because I > presume, without any metrics, that nftables is probably faster and > slicker or something. As I said before, my concern is more about people being fully aware of state of their firewall rather than if it technically works. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] wg-quick: linux: add support for nft and prefer it
On Tuesday, December 10, 2019 3:48 PM, Jason A. Donenfeld wrote: > If nft(8) is installed, use it. These rules should be identical to the > iptables-restore(8) ones, with the advantage that cleanup is easy > because we use custom table names. > I wonder if nft should be used only if iptables isn't installed instead. Nowadays iptables has nft backend which I believe is default and will translate iptables rules to nft automatically. On my system iptables rules from wg-quck are already shown in "nft list ruleset". I'm not sure if this work in reverse - are nft rules automatically translated to iptables and shown in iptables-save? If not then using iptables of available seems more versatile for the job. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20191205` Available
On Friday, December 6, 2019 3:52 PM, Jason A. Donenfeld wrote: > On Fri, Dec 6, 2019 at 4:36 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > iptables is from Arch Linux iptables-nft package: > > $ iptables --version > > iptables v1.8.3 (nf_tables) > > Does the segfault happen with the latest version in the git repo? > > https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick/linux.bash Yes, it still segfaults in the same way as before: systemd[1]: Stopping WireGuard via wg-quick(8) for wg0... wg-quick[6528]: [#] iptables -D OUTPUT -o wg0 -j ACCEPT wg-quick[6528]: [#] ip -4 rule delete table 51820 wg-quick[6528]: [#] ip -4 rule delete table main suppress_prefixlength 0 wg-quick[6528]: [#] ip link delete dev wg0 wg-quick[6528]: [#] resolvconf -d wg0 -f wg-quick[6620]: [#] iptables-restore -n audit[6621]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj==unconfined pid=6621 comm="iptables-restor" exe="/usr/bin/xtables-nft-multi" sig=11 res=1 wg-quick[6620]: /usr/bin/wg-quick: line 29: 6621 Segmentation fault (core dumped) "$@" kernel: iptables-restor[6621]: segfault at 0 ip 6e4350496cc9 sp 7bfae0479dd0 error 4 in libnftnl.so.11.2.0[6e4350494000+18000] kernel: Code: 15 5c 20 02 00 48 85 c0 74 07 48 89 00 48 89 40 08 48 83 c4 08 c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 48 83 ec 08 <48> 8b 3f 48 8b 1f 48 39 fd 74 2f 0f 1f 40 00 48 8b 47 08 48 89 43 systemd[1]: wg-quick@wg0.service: Succeeded. systemd[1]: Stopped WireGuard via wg-quick(8) for wg0. The "RTNETLINK answers: Address family not supported by protocol" messages which were caused by lack of ipv6 support in kernel (AKA weird kernels) was silenced but I think they weren't related to this problem. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
On Friday, December 6, 2019 4:03 PM, Vasili Pupkin wrote: > On 06.12.2019 18:08, Jason A. Donenfeld wrote: > > > On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover > > golden_mille...@protonmail.ch wrote: > > > > > On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld ja...@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
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20191205` Available
On Friday, December 6, 2019 3:20 PM, Jason A. Donenfeld wrote: > On Fri, Dec 6, 2019 at 4:11 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > Hi, this release cause coredump on wg-quick down action: > > systemd[1]: Stopping WireGuard via wg-quick(8) for wg0... > > wg-quick[2241]: [#] iptables -D OUTPUT -o wg0 -j ACCEPT > > wg-quick[2241]: [#] ip -4 rule delete table 51820 > > wg-quick[2241]: [#] ip -4 rule delete table main suppress_prefixlength 0 > > wg-quick[2257]: RTNETLINK answers: Address family not supported by protocol > > wg-quick[2257]: Dump terminated > > wg-quick[2258]: RTNETLINK answers: Address family not supported by protocol > > wg-quick[2258]: Dump terminated > > wg-quick[2241]: [#] ip link delete dev wg0 > > wg-quick[2241]: [#] resolvconf -d wg0 -f > > wg-quick[2315]: [#] iptables-restore -n > > audit[2316]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 > > subj==unconfined pid=2316 comm="iptables-restor" > > exe="/usr/bin/xtables-nft-multi" sig=11 res=1 > > wg-quick[2315]: /usr/bin/wg-quick: line 29: 2316 Segmentation fault (core > > dumped) "$@" > > kernel: show_signal_msg: 40 callbacks suppressed > > kernel: iptables-restor[2316]: segfault at 0 ip 64515b66fcc9 sp > > 7e6bbcbfb720 error 4 in libnftnl.so.11.2.0[64515b66d000+18000] > > kernel: Code: 15 5c 20 02 00 48 85 c0 74 07 48 89 00 48 89 40 08 48 83 c4 > > 08 c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 48 83 ec 08 <48> 8b > > 3f 48 8b 1f 48 39 fd 74 2f 0f 1f 40 00 48 8b 47 08 48 89 43 > > systemd[1]: wg-quick@wg0.service: Succeeded. > > systemd[1]: Stopped WireGuard via wg-quick(8) for wg0. > > What distro's iptables? iptables is from Arch Linux iptables-nft package: $ iptables --version iptables v1.8.3 (nf_tables) Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20191205` Available
On Thursday, December 5, 2019 10:55 AM, Jason A. Donenfeld
wrote:
> Hello,
>
> A new snapshot, `0.0.20191205`, has been tagged in the git repository.
>
> Please note that this snapshot is a snapshot rather than a final
> release that is considered secure and bug-free. WireGuard is generally
> thought to be fairly stable, and most likely will not crash your
> computer (though it may). However, as this is a snapshot, it comes
> with no guarantees; it is not applicable for CVEs.
>
> With all that said, if you'd like to test this snapshot out, there are a
> few relevant changes.
>
> == Changes ==
>
> - wg-quick: linux: suppress error when finding unused table
>
> This fixes a spurious warning messages seen with recent versions of
> iproute2
> and kernels.
>
> - wg-quick: linux: ensure postdown hooks execute
> - wg-quick: linux: have remove_iptables return true
> - wg-quick: linux: iptables-* -w is not widely supported
>
> Adding in iptables had some hiccups. For the record, I'm very unhappy
> about
> having to put any firewalling code into wg-quick(8). We'll of course need
> to
> support nftables too at some point if this continues. I'm investigating
> with
> upstream the possibility of adding a sysctl to patch the issue that
> iptables
> is handling now, so hopefully at somepoint down the line we'll be able to
> shed
> this dependency once again.
>
> - send: use kfree_skb_list
> - device: prepare skb_list_walk_safe for upstreaming
> - send: avoid touching skb->{next,prev} directly
>
> Suggestions from LKML.
>
> - ipc: make sure userspace communication frees wgdevice
>
> Free things properly on error paths.
>
> This snapshot contains commits from: Jason A. Donenfeld.
>
> As always, the source is available at https://git.zx2c4.com/WireGuard/ and
> information about the project is available at https://www.wireguard.com/ .
>
> This snapshot is available in compressed tarball form here:
> https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20191205.tar.xz
> SHA2-256:
> BLAKE2b-256:
>
> A PGP signature of that file decompressed is available here:
> https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20191205.tar.asc
> Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
>
> If you're a snapshot package maintainer, please bump your package
> version. If
> you're a user, the WireGuard team welcomes any and all feedback on this
> latest
> snapshot.
>
> Finally, WireGuard development thrives on donations. By popular demand, we
> have a webpage for this: https://www.wireguard.com/donations/
>
> Thank you,
> Jason Donenfeld
>
Hi, this release cause coredump on wg-quick down action:
systemd[1]: Stopping WireGuard via wg-quick(8) for wg0...
wg-quick[2241]: [#] iptables -D OUTPUT -o wg0 -j ACCEPT
wg-quick[2241]: [#] ip -4 rule delete table 51820
wg-quick[2241]: [#] ip -4 rule delete table main suppress_prefixlength 0
wg-quick[2257]: RTNETLINK answers: Address family not supported by protocol
wg-quick[2257]: Dump terminated
wg-quick[2258]: RTNETLINK answers: Address family not supported by protocol
wg-quick[2258]: Dump terminated
wg-quick[2241]: [#] ip link delete dev wg0
wg-quick[2241]: [#] resolvconf -d wg0 -f
wg-quick[2315]: [#] iptables-restore -n
audit[2316]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295
subj==unconfined pid=2316 comm="iptables-restor"
exe="/usr/bin/xtables-nft-multi" sig=11 res=1
wg-quick[2315]: /usr/bin/wg-quick: line 29: 2316 Segmentation fault (core
dumped) "$@"
kernel: show_signal_msg: 40 callbacks suppressed
kernel: iptables-restor[2316]: segfault at 0 ip 64515b66fcc9 sp
7e6bbcbfb720 error 4 in libnftnl.so.11.2.0[64515b66d000+18000]
kernel: Code: 15 5c 20 02 00 48 85 c0 74 07 48 89 00 48 89 40 08 48 83 c4 08 c3
66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 fd 53 48 83 ec 08 <48> 8b 3f 48 8b 1f
48 39 fd 74 2f 0f 1f 40 00 48 8b 47 08 48 89 43
systemd[1]: wg-quick@wg0.service: Succeeded.
systemd[1]: Stopped WireGuard via wg-quick(8) for wg0.
I saw some iptables related fix in git[1] but I don't know if
it's related to similar issue.
[1]
https://git.zx2c4.com/WireGuard/commit/?id=884b6e36e6af0c6fa5b9467ccc8c2e2e4477bc95
Jordan
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld 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
Re: [PATCH] treewide: more portable bash shebangs
On Wednesday, July 17, 2019 6:39 PM, Jörg Thalheim wrote: > > It does not make anything worse. Your threat model is unreasonable and out of > scope > of what the scripts are intended to guarantee. > There are tones of other environment variables like LD_PRELOAD or > LD_LIBRARY_PATH And how exactly you get into position to decide what scope is reasonable for wireguard scripts? Same as you I can clam that your use-case is out of scope and instead of forcing everyone else to patch-out your changes you can go back to patching the code by yourself in a way you wish and with accordance to threat model you may or not have. Good luck. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] treewide: more portable bash shebangs
On Tuesday, July 16, 2019 10:08 PM, Jörg Thalheim wrote: > On 16/07/2019 18.32, Jordan Glover wrote: > > > On Tuesday, July 16, 2019 12:21 PM, Jörg Thalheim jo...@higgsboson.tk wrote: > > > > > While /usr/bin/env is more or less available on all POSIX systems > > > /bin/bash might not be. This is particular the case on NixOS and the BSD > > > family (/usr/local/bin/bash). Downstream packagers would often rewrite > > > those shebangs back automatically as they can rely on absolute paths > > > but having portable shebangs in the repository helps to run the code > > > without any further modification. > > > > The reason almost everyone hardcodes bash to /bin/bash is the potential > > environment attack where someone create malicious "bash" and export it in > > PATH: > > https://developer.apple.com/library/archive/documentation/OpenSource/Conceptual/ShellScripting/ShellScriptSecurity/ShellScriptSecurity.html > > Obviously wg scripts are handling quite sensitive data like private keys... > > Seriously if you except that downstream packagers would rewrite it back to > > /bin/bash then why the others can't rewrite it to /usr/bin/env bash right > > now if this is something they want? > > Jordan > > This argument does not apply here since all commands internally could > be redirected by a PATH change as well since the PATH is not set in the > scripts. Yep, that's something to actually fix as you won't fix things by making it worse. > I am also not quite sure what threat model here is? > The scripts changed here are not designed to run from a CGI context > and are not hardened for that purpose. > The idea is that you can run the scripts unmodified from the repository > without having to alter the files, which is convenient for development w.r.t > to git. Then simply run "bash " and call it a day. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] treewide: more portable bash shebangs
On Tuesday, July 16, 2019 12:21 PM, Jörg Thalheim wrote: > While /usr/bin/env is more or less available on all POSIX systems > /bin/bash might not be. This is particular the case on NixOS and the BSD > family (/usr/local/bin/bash). Downstream packagers would often rewrite > those shebangs back automatically as they can rely on absolute paths > but having portable shebangs in the repository helps to run the code > without any further modification. > The reason almost everyone hardcodes bash to /bin/bash is the potential environment attack where someone create malicious "bash" and export it in PATH: https://developer.apple.com/library/archive/documentation/OpenSource/Conceptual/ShellScripting/ShellScriptSecurity/ShellScriptSecurity.html Obviously wg scripts are handling quite sensitive data like private keys... Seriously if you except that downstream packagers would rewrite it back to /bin/bash then why the others can't rewrite it to /usr/bin/env bash right now if this is something they want? Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: bypassing wireguard using firejail
On Friday, May 10, 2019 11:54 AM, Sitaram Chamarty wrote: > I am able to bypass the VPN by using firejail (which is a > sandbox program to run untrusted applications). > > Below, the IP addresses and domain names are fake but that > should not matter: > > # wg > interface: wg0 > public key: > private key: (hidden) > listening port: 59457 > fwmark: 0xca6c > > peer: > endpoint: 11.22.33.44:51820 > allowed ips: 0.0.0.0/0 > latest handshake: 41 seconds ago > transfer: 35.42 MiB received, 2.74 MiB sent > > $ curl zx2c4.com/ip > 11.22.33.44 <--- my wg VPN end point IP > static.44.33.22.11.elided.tld > curl/7.64.0 > > $ firejail --net=wlp2s0 --dns=8.8.8.8 curl zx2c4.com/ip > 55.66.77.88 <--- my actual external IP > elided.hostname.myisp.in > curl/7.64.0 > > My questions: > > 1. I know firejail is suid root, but still... is there any way > to prevent this from happening, or at least make it less > trivial? > > I'm OK with a "this is the way it is, if your untrusted app > is running as root you're already toast" response; just want > to make sure I'm not missing a bet here. > > 2. I guess I don't know as much about Linux networking as I > thought I knew, especially about policy routing, so I am > feeling a bit lost here. > > I would prefer not to have to learn lots of things about > policy routing and so on, so I wonder if there is a simple, > (wireguard-specific, if possible) explanation of how linux > policy routing and iptables work behind the scenes to direct > packets when wireguard is in play? > > regards > sitaram > > This is known firejail feature[1]. If you want to prevent yourself from this footgun you may add "restricted-network yes" in /etc/firejail/firejail.config I don't see anything from wireguard to do here. If system admin want to bypass the routes, they will. [1] https://github.com/netblue30/firejail/issues/2665 Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Cannot compile Noise.c on Kernel 5.0?
On Wednesday, January 16, 2019 5:37 PM, Sam Cater wrote: > Hi Wireguard Mailing List, > > Probably going to be showing a lot of ignorance here! > > Wireguard has run fine on this system in the past, but today I tried to > build 20181218 on self-built 5.0 kernel (which in and of itself seems > stable and working fine). The compile fails on src/noise.o with the > issue linked below on line 453. > > If I switch back to the stock 4.19 kernel provided by Fedora then > everything compiles fine. It's also worth mentioning that the same issue > appears to happen when I install the COPR packages for Fedora. > > Appreciate I'm a non-standard kernel but just in case it is a Linux 5 > incompatibility rather than "I can't build software", I thought I'd post > here in case it was helpful. > > Mini paste at: https://pastebin.com/raw/W4LRT5bx For Linux 5.0 you need to use wireguard snapshot from git: https://git.zx2c4.com/WireGuard/log/ The error you posted was fixed by: https://git.zx2c4.com/WireGuard/commit/?id=a56a0fee861d104b9bdb22847656fc40a9b13079 Later in build there will be another error fixed by: https://git.zx2c4.com/WireGuard/commit/?id=eb8316abc24da2e38de65d88c519aa8dfd6227f4 Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: binary module for arch?
On Monday, December 31, 2018 5:11 PM, John wrote: > My recommendation is to change the wording under the command on your > install page to something like: "Users of the distro provided kernels > (linux and linux-lts) may download the requisite corresponding > precompiled wireguard module. Users of custom kernels will require the > wireguard-dkms package and corresponding kernel headers to compile the > module." > This isn't strictly true as there are distro provided kernels (linux-hardened and linux-zen) which don't have wireguard binary modules available. Below would be more appropriate: "Users of linux and linux-lts kernels may download the requisite corresponding precompiled wireguard module. Users of other kernels will require the wireguard-dkms package and corresponding kernel headers to compile the module." Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Build fails on Debian, kernel 4.20.0-rc4
On Sunday, December 2, 2018 12:38 AM, Laszlo KERTESZ wrote: > On Sun, Dec 2, 2018 at 1:26 AM Tushar Pankaj > wrote: > >> Does it have to do with macros.S having a capital S extension? >> >> Thanks, >> Tushar Pankaj > > Probably not. I don't have any "arch/x86/kernel/macros.s" file (actually > "/usr/src/linux-headers-4.20.0-rc4/arch/x86/kernel/macros.s") at all. In fact > neither do i have macros.s or macros.S in previous kernels directories. And that's why it fails[1]. You have to add "arch/x86/kernel/macros.s" to list of files to be copied as fedora did. Their first patch contained a typo (capital 'S' instead of 's'[2]. I don' know where debian does handle this though. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1643599 [2] https://src.fedoraproject.org/cgit/rpms/kernel.git/commit/kernel.spec?id=e7c396bbf3cd1563d445275f92b63f8e9da3f13e___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181119` Available
On Monday, November 19, 2018 8:02 PM, Jason A. Donenfeld wrote: > Hi Jordan, > On Mon, Nov 19, 2018 at 7:04 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > It fails to build for me (doing in-kernel build with Linux 4.20rc3 and > > WireGuard/contrib/kernel-tree/create-patch.sh) with below message: > > make[2]: *** No rule to make target > > 'net/wireguard/crypto/zinc/chacha20/chacha20-x86_64.o', needed by > > 'net/wireguard/built-in.a'. Stop. > > There is also following warn when applying wireguard patch: > > diff: /WireGuard/src/**/*.S_shipped: No such file or directory > > Ugh, sorry. This keeps happening: neglecting the jerry rig scripts, > because they're not in src/. I need to either move those into src/ or > add them to the CI so that this doesn't happen again. > > https://git.zx2c4.com/WireGuard/patch/?id=37466fb996ea174cddd3d836c2f49c53b10648ad > should fix it. > > Jason I can confirm that above fix works. Thank you. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181119` Available
On Monday, November 19, 2018 6:27 PM, Jason A. Donenfeld wrote: > Hello, > > A new snapshot, `0.0.20181119`, has been tagged in the git repository. > > Please note that this snapshot is, like the rest of the project at this point > in time, experimental, and does not consitute a real release that would be > considered secure and bug-free. WireGuard is generally thought to be fairly > stable, and most likely will not crash your computer (though it may). > However, as this is a pre-release snapshot, it comes with no guarantees, and > its security is not yet to be depended on; it is not applicable for CVEs. > > With all that said, if you'd like to test this snapshot out, there are a > few relevant changes. > > == Changes == > > - chacha20,poly1305: fix up for win64 > - poly1305: only export neon symbols when in use > - poly1305: cleanup leftover debugging changes > - crypto: resolve target prefix on buggy kernels > - chacha20,poly1305: don't do compiler testing in generator and remove xor > helper > - crypto: better path resolution and more specific generated .S > - poly1305: make frame pointers for auxiliary calls > - chacha20,poly1305: do not use xlate > > This should fix up the various build errors, warnings, and insertion > errors > introduced by the previous snapshot, where we added some significant > refactoring. In short, we're trying to port to using Andy Polyakov's > original > perlasm files, and this means quite a lot of work to re-do that had > stableized > in our old .S. > > This snapshot contains commits from: Jason A. Donenfeld and Samuel Neves. > > As always, the source is available at https://git.zx2c4.com/WireGuard/ and > information about the project is available at https://www.wireguard.com/ . > > This snapshot is available in compressed tarball form here: > https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20181119.tar.xz > SHA2-256: 7d47f7996dd291069de4efb3097c42f769f60dc3ac6f850a4d5705f321e4406b > BLAKE2b-256: > 7691db05dbdc6619700f8334ebf258c6160ae2d6f481ef98475f0c5c2627b3a6 > > A PGP signature of that file decompressed is available here: > https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20181119.tar.asc > Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE > > If you're a snapshot package maintainer, please bump your package > version. If > you're a user, the WireGuard team welcomes any and all feedback on this > latest > snapshot. > > Finally, WireGuard development thrives on donations. By popular demand, we > have a webpage for this: https://www.wireguard.com/donations/ > > Thank you, > Jason Donenfeld > It fails to build for me (doing in-kernel build with Linux 4.20rc3 and WireGuard/contrib/kernel-tree/create-patch.sh) with below message: make[2]: *** No rule to make target 'net/wireguard/crypto/zinc/chacha20/chacha20-x86_64.o', needed by 'net/wireguard/built-in.a'. Stop. There is also following warn when applying wireguard patch: diff: /WireGuard/src/**/*.S_shipped: No such file or directory Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wireguard dkms systemd
‐‐‐ Original Message ‐‐‐ On Saturday, October 20, 2018 10:59 PM, Lucian Cristian wrote: > updating the wireguard module on systemd based linux gives > > Warning: The unit file, source configuration file or drop-ins of > wg-quick@wg0.service changed on disk. Run 'systemctl daemon-reload' to > reload units. > Sleeping 3 seconds... > This has nothing to do with dkms. Systemd units are part of wireguard-tools package. > can this be fixed int the restart script ? > There isn't a "restart script" in any wireguard package. > the tunnel won't come up if the unit is not reloaded > Then reload it. You have exact command printed. > Thank you ! Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181007` Available
‐‐‐ Original Message ‐‐‐ On Monday, October 8, 2018 12:37 AM, Jason A. Donenfeld wrote: > On Sun, Oct 7, 2018 at 10:49 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > I got an error when doing in-tree build using > > WireGuard/contrib/kernel-tree/create-patch.sh > > net/wireguard/receive.c:338:10: fatal error: selftest/counter.c: No such > > file or directory > > #include "selftest/counter.c" > > ^~~~ > > compilation terminated. > > Youch. I'm rewriting those scripts so that it picks up file name > changes like this automatically, so it's not such a whack-a-mole > situation. > > Let me know if this fixes it: > https://git.zx2c4.com/WireGuard/commit/?id=28366408148d0f230daebd9a61c5f7bf0c3e0390 > > Jason Yes, this fixes this issue. Thank you. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181007` Available
‐‐‐ Original Message ‐‐‐ On Sunday, October 7, 2018 5:20 PM, Jason A. Donenfeld wrote: > Hello, > > A new snapshot, `0.0.20181007`, has been tagged in the git repository. > > Please note that this snapshot is, like the rest of the project at this point > in time, experimental, and does not consitute a real release that would be > considered secure and bug-free. WireGuard is generally thought to be fairly > stable, and most likely will not crash your computer (though it may). > However, as this is a pre-release snapshot, it comes with no guarantees, and > its security is not yet to be depended on; it is not applicable for CVEs. > > With all that said, if you'd like to test this snapshot out, there are a > few relevant changes. > > == Changes == > > - makefile: do more generic wildcard so as to avoid rename issues > > Yesterday's snapshot broke DKMS installation, which is the majority of > distros > using WireGuard, so we're rushing out a fix the day after so that people > can > actually run it. > > - compat: account for ancient ARM assembler > > - compat: make asm/simd.h conditional on its existence > > - compat: clang cannot handle __builtin_constant_p > > Yesterday's snapshot broke old ARM kernels and Android kernels using > Clang. > > - crypto: disable broken implementations in selftests > > If the selftests determine a particular crypto implementation doesn't > work, it > prints a warning -- since that would be a pretty grave bug -- but it also > just > disables that implementation so that we don't compute anything > incorrectly. > > - crypto: use BIT(i) & bitmap instead of (bitmap >> i) & 1 > > - allowedips: document additional nobs > > - crypto: clean up remaining .h->.c > > - global: style nits > > Various cleanups and style nits. > > This snapshot contains commits from: Jason A. Donenfeld. > > As always, the source is available at https://git.zx2c4.com/WireGuard/ and > information about the project is available at https://www.wireguard.com/ . > > This snapshot is available in compressed tarball form here: > https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20181007.tar.xz > SHA2-256: d26e0d1216594871b5947e76d64c2fa50e9b34b68cdcfa3fdad588cbb314af89 > BLAKE2b-256: > 50dc7e09513cac1bd9de1bf136bae4d595bb0d27afebc33dab6c33bca175 > > A PGP signature of that file decompressed is available here: > https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20181007.tar.asc > Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE > > If you're a snapshot package maintainer, please bump your package > version. If > you're a user, the WireGuard team welcomes any and all feedback on this > latest > snapshot. > > Finally, WireGuard development thrives on donations. By popular demand, we > have a webpage for this: https://www.wireguard.com/donations/ > > Thank you, > Jason Donenfeld > I got an error when doing in-tree build using WireGuard/contrib/kernel-tree/create-patch.sh net/wireguard/receive.c:338:10: fatal error: selftest/counter.c: No such file or directory #include "selftest/counter.c" ^~~~ compilation terminated. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH 1012/1012] Support for unicode interface names: only '%', ':' and '/' must be avoided
‐‐‐ Original Message ‐‐‐ On August 25, 2018 5:50 PM, Jorge AC wrote: > Thank you for checking my regex with the kernel code lines :-) > > Definetly is insanity what drives me, I enjoy naming interfaces with > unicodes like ☢. > > Nevertheless, thinking about a legit use, it could be a nice gesture > for those non-latin1 people who wants to use their language. > Wireguard aims to be simple and secure. The name of device is used to identify it, not to make a gestures to anyone. All wg/wg-quick commands are in latin (english). I don't see much benefit of executing commands like 'wg showconf ☢' instead of 'wg showconf abc123' other than someone's egoistic pleasure. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Wireguard doesn't work with Linux 4.18-rc1
On June 23, 2018 6:01 PM, Jason A. Donenfeld wrote: > Working on it: > > https://marc.info/?l=linux-netdev&m=152976958325076&w=2 I can confirm that your patch fixes this issue. Thank you for help. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Wireguard doesn't work with Linux 4.18-rc1
On June 23, 2018 3:35 PM, Bruno Wolff III wrote: > On Sat, Jun 23, 2018 at 08:23:08 -0400, > > Jordan Glover golden_mille...@protonmail.ch wrote: > > > Hi, > > > > I can't make wireguard work with linux 4.18-rc1 and mainline from > > > > 06.22.2018. > > It has been working for me. I use Fedora rawhide nodebug kernels and > > haven't noticed any problems with WireGuard. I build WireGuard from > > source (HEAD) when I switch kernels. > > So you are probably going to need to provide more details to narrow > > things down. Thx for the reply. I tested it with my custom kernel and with Manjaro kernel on Archlinux. Can you check if it works for you with 'ipv6.disable=1' boot param? https://mirror.netzspielplatz.de/manjaro/packages/unstable/core/x86_64/linux418-4.18rc1.0617.gce397d2-1-x86_64.pkg.tar.xz https://mirror.netzspielplatz.de/manjaro/packages/unstable/core/x86_64/linux418-headers-4.18rc1.0617.gce397d2-1-x86_64.pkg.tar.xz ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Wireguard doesn't work with Linux 4.18-rc1
Hi, I can't make wireguard work with linux 4.18-rc1 and mainline from 06.22.2018. sudo wg-quick up abc [#] ip link add abc type wireguard [#] wg setconf abc /dev/fd/xx [#] ip address add xx.xx.xx.xxx/xx dev abc [#] ip link set mtu 1420 dev abc [#] ip link set abc up [#] resolvconf -a abc -m 0 -x [#] wg set abc fwmark x [#] ip -4 route add 0.0.0.0/0 dev abc table x [#] ip -4 rule add not fwmark x table x [#] ip -4 rule add table main suppress_prefixlength 0 RTNETLINK answers: File exists [#] resolvconf -d abc [#] ip -4 rule delete table x RTNETLINK answers: Address family not supported by protocol Dump terminated RTNETLINK answers: Address family not supported by protocol Dump terminated [#] ip link delete dev abc It works with Linux 4.17 and earlier. I tested two latest wireguard snapshots (0.0.20180620, 0.0.20180613). I'm disabling ipv6 at boot with ipv6.disable=1 Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: PostUp/PreUp/PostDown/PreDown Dangerous?
On June 22, 2018 9:26 PM, Lonnie Abelbeck wrote: > How about not supporting direct execution of commands in the config > [Interface] section but rather support an optional path to where a fixed > command (ex. wireguard.script) is found... > > > --- > > ActionScriptDir = /usr/local/bin > > > Then instead of executing the PostUp/PostDown/PreUp/PreDown data, the > wg-quick script would call: > > > - > > /usr/local/bin/wireguard.script PRE_UP|PRE_DOWN|POST_UP|POST_DOWN "$INTERFACE" > -- > > 1. When called, the first argument would be one of: > PRE_UP|PRE_DOWN|POST_UP|POST_DOWN > 2. When called, the second argument would be the wireguard interface. > 3. If ActionScriptDir is not defined, then wireguard.script is not called. > > This requires an extra step to be taken to create a wireguard.script file > with execute permissions and possibly require specific ownership. > > Lonnie > But attacker will helpfully provide you customized 'wireguard.script' as well and even tell you how to use it by setting 'chmod 4777 wireguard.script'. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: PostUp/PreUp/PostDown/PreDown Dangerous?
On June 22, 2018 3:56 AM, Antonio Quartulli wrote: > > In case this might be useful: in OpenVPN there is an additional > > parameter called "--script-security" that requires to be set to a > > certain level before allowing configured scripts to be executed. > > Unfortunately there is no real protection against the clueless user, who > > can and will blindly enable that setting if asked by a $random VPN provider. > > However, I still believe (and hope) that forcing the user to enable a > > specific knob may raise the level of attention. > > Maybe something similar could be added as a command line parameter to > > wg/wg-quick so that it will execute the various > > PostUp/PreUp/PostDown/PreDown only if allowed to? > > Just as a side note: this is not a VPN specific problem, this is > > something users can end up with everytime they execute some binary with > > a configuration they have not inspected. So, be careful out there ;-) > > Cheers, > Attacker can pass appropriate "--script-security" level with the very same config containing malicious commands so this isn't solving problem of not looking at the content of config files. I think blindly using untrusted files from the web is indefensible. Sure, we could throw away this functionality completely but then we will punish people who bother to look at the configs before using them and make their life little harder while the others will still find their footgun somewhere else as this is rather generic issue not limited to wireguard or even networking. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WG interface to ipv4
On May 7, 2018 11:37 AM, Matthias Urlichs wrote: > On 07.05.2018 10:41, Jordan Glover wrote: > > > Pointing to go and rust implementations which are being > > > > worked on will be much better. > > They still run in userspace. And pointing to them will be better example for argumentation. Pointing to the closed source one isn't something that will win an argument in this list. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WG interface to ipv4
On May 7, 2018 10:24 AM, ѽ҉ᶬḳ℠ wrote: > > SSH is different for two reasons: It runs over TCP, and it runs in > > > > userspace. > > > > Secondly, because SSH runs in userspace, a lot of the processing (such > > > > as the TCP handshake) is done by the kernel on the application's behalf. > > > > So the only way the application has of telling the kernel not to do > > > > this, is by setting the listen address. Wireguard lives directly in the > > > > kernel and so can perform the authentication directly after receiving > > > > the packet, without suffering a context switch to userspace. > > > > -Toke > > Perhaps worth noting this WG app (TunSafe) for WIN "runs as a user-mode > > application and does not run inside of the kernel" > > https://tunsafe.com/user-guide That's unfortunate example :) It's closed source, unaffiliated and was recommended against several times here and on IRC. Pointing to go and rust implementations which are being worked on will be much better. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WG interface to ipv4
On May 6, 2018 6:33 PM, ѽ҉ᶬḳ℠ wrote: > Depends perhaps a bit of what the (long term) aim/goal of the WG is - > > whether to be a niche product for enthusiasts (only guessing here that > > this is the current state) or to make it into the > > mainstream/corporate/commercial arena. I doubt that server > > administrators will take to it with no control over WG's socket/iface > > exposure. Probably time will tell and/or I am wrong with that > > perspective already. Several people described to you that there is no exposure as every invalid packet will be silently dropped and you still insist there is a flaw in WG which will hurt it's adoption. For constructive discussion I propose this: present us PoC which will show that listening on 0.0.0.0 and ::1 can be exploited with WG and binding it exclusively to x.x.x.x will help to mitigate it. At least try to describe such scenario. That would move this discussion forward and may even lead to WG code improvements. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WG interface to ipv4
On May 6, 2018 10:58 AM, ѽ҉ᶬḳ℠ wrote: > > Why? Can you outline the threat model? > > > > As I mentioned earlier, to disable v6 socket creation, pass > > > > ipv6.disable=1 on the kernel command line, or just unload the v6 > > > > module. If you're worried about the Linux v6 stack being a pile of > > > > scary bugs, then you certainly want to be doing this already, and not > > > > relying on simply disabling v6 routing within that network namespace, > > > > which you're doing with the conf.default.disable_ipv6=1. In other > > > > words, if you don't want v6 for reasons of attack surface, then you > > > > should actually be disabling v6 properly. > > Any piece of software is flawed (threat model), proven by the various > > CVE and others yet to be discovered, that including Linux kernel and its > > userland. > > ipv6 deployment/utilization is hardly a matter of black and white, i.e. > > turning it off/on during boot time. Some scenarios call for ipv6 to be > > available whilst others not and thus ipv6 routing is disabled whenever > > not needed in order to tailor mitigation of potential attack surfaces. > > Like ssh can be constrained to a particular ipv socket and so it can be > > set for ntp, dnsmasq, bind, unbound, just to name a few. > > Why would WG take the high route and curtail user control of whether to > > open an ipv4 or ipv6 (someone else may not be keen on ipv4) socket, or both? > > > Why is this a matter of network security? WireGuard will ignore > > > > packets that don't have the correct authentication tag. If you're > > > > receiving authentic packets, you're receiving authentic packets, and > > > > the origin shouldn't matter, in terms of the packets' authenticity. In > > > > other words, if an attacker has stolen a private key, this is the > > > > problem to address. > > Why to offer a the broadest surface (0.0.0.0 - all IPv4 addresses on the > > local machine and with the ipv6 socket open also those) for a potential > > attack in the first place and deprive the user of tailoring/binding WG > > deployment to the respective network layout? > > > Anyway, regardless of this, if you want to filter > > > > out packets coming from a certain interface, a certain subnet, or any > > > > other characteristics, use netfilter and make these preferences > > > > explicit in your rules, rather than the implicit details of listening > > > > sockets. > > I would not consider binding WG to a particular iface/subnet an implicit > > choice but rather being explicit, but that is perhaps a matter of > > perspective then. Netfilter rules can easily get convoluted in complex > > scenarios. Jason already explained it but maybe it needs to be repeated several more times. WG security model doesn't rely on which interface, port or subnet it's listening on. You can screw your network configuration in myriad ways and WG will still save you due to it's design. Private keys are all that matters. Keep them secure and forget about the rest of things you know about unbound, dnsmasq, bind, ssh, openvpn and ipsec. Use route tables and netfilter rules to choose where the network traffic should go. That's all. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
