diff options
Diffstat (limited to '')
| -rw-r--r-- | docs/adminregistry.md | 16 | ||||
| -rw-r--r-- | docs/attacksurface.md | 15 | ||||
| -rw-r--r-- | docs/netquirk.md | 2 |
3 files changed, 12 insertions, 21 deletions
diff --git a/docs/adminregistry.md b/docs/adminregistry.md index 245c49a9..bd13fee9 100644 --- a/docs/adminregistry.md +++ b/docs/adminregistry.md @@ -38,14 +38,16 @@ executing these scripts. > reg add HKLM\Software\WireGuard /v DangerousScriptExecution /t REG_DWORD /d 1 /f ``` -#### `HKLM\Software\WireGuard\ExperimentalKernelDriver` +#### `HKLM\Software\WireGuard\UseUserspaceImplementation` -When this key is set to `DWORD(1)`, an experimental kernel driver from the -[WireGuardNT](https://git.zx2c4.com/wireguard-nt/about/) project is used instead -of the much slower wireguard-go/Wintun implementation. There are significant -performance gains, but do note that this is _currently_ considered experimental, -and hence is not recommended. +When this key is set to `DWORD(1)`, the legacy wireguard-go/Wintun implementation +is used instead of the newer, faster [WireGuardNT](https://git.zx2c4.com/wireguard-nt/about/) +implementation. This is an intended stop-gap solution in case there are early bugs +with WireGuardNT, and this option will be removed after a short period. If you use +this option, please send an email to team@wireguard.com explaining the issues you +had with WireGuardNT, so that they can be fixed before this option goes away. If +you are not having issues, do not use this option. ``` -> reg add HKLM\Software\WireGuard /v ExperimentalKernelDriver /t REG_DWORD /d 1 /f +> reg add HKLM\Software\WireGuard /v UseUserspaceImplementation /t REG_DWORD /d 1 /f ``` diff --git a/docs/attacksurface.md b/docs/attacksurface.md index 53bcd7c6..a495ba41 100644 --- a/docs/attacksurface.md +++ b/docs/attacksurface.md @@ -4,14 +4,6 @@ _This is an evolving document, describing currently known attack surface, a few WireGuard for Windows consists of four components: a kernel driver, and three separate interacting userspace parts. -### Wintun - -Wintun is a kernel driver. It exposes: - - - A miniport driver to the ndis stack, meaning any process on the system that can access the network stack in a reasonable way can send and receive packets, hitting those related ndis handlers. - - There are also various ndis OID calls, accessible to certain users, which hit further code. - - IOCTLs are added to the NDIS device file, and those IOCTLs are restricted to `O:SYD:P(A;;FA;;;SY)(A;;FA;;;BA)S:(ML;;NWNRNX;;;HI)`. The IOCTL allows userspace to register a pair of rings and event objects, which Wintun then locks the pages of with a double mapping and takes a reference to the event object. It parses the contents of the ring to send and receive layer 3 packets, each of which it minimally parses to determine IP family. - ### WireGuardNT WireGuardNT is a kernel driver. It exposes: @@ -24,12 +16,9 @@ WireGuardNT is a kernel driver. It exposes: ### Tunnel Service -The tunnel service is a userspace service running as Local System, responsible for either A) creating UDP sockets, creating Wintun adapters, and speaking the WireGuard protocol between the two, or B) creating WireGuardNT adapters and configuring them. It exposes: +The tunnel service is a userspace service running as Local System, responsible for creating WireGuardNT adapters and configuring them. It exposes: - - In case A) a listening pipe in `\\.\pipe\ProtectedPrefix\Administrators\WireGuard\%s`, where `%s` is some basename of an already valid filename. Its DACL is set to `O:SYD:P(A;;GA;;;SY)(A;;GA;;;BA)S:(ML;;NWNRNX;;;HI)`. If the config file used by the tunnel service is not DPAPI-encrypted and it is owned by a SID other than "Local System" then an additional ACE is added giving that file owner SID access to the named pipe. This pipe gives access to private keys and allows for reconfiguration of the interface, as well as rebinding to different ports (below 1024, even). Clients who connect to the pipe run `GetSecurityInfo` to verify that it is owned by "Local System". - - A global mutex is used for Wintun/WireGuardNT interface creation, with the same DACL as the pipe, but first CreatePrivateNamespace is called with a "Local System" SID. - - In case A) it handles data from its two UDP sockets, accessible to the public Internet. - - In case A) it handles data from Wintun, accessible to all users who can do anything with the network stack. + - A global mutex is used for WireGuardNT interface creation, with the same DACL as the pipe, but first CreatePrivateNamespace is called with a "Local System" SID. - After some initial setup, it uses `AdjustTokenPrivileges` to remove all privileges, except for `SeLoadDriverPrivilege`, so that it can remove the interface when shutting down. This latter point is rather unfortunate, as `SeLoadDriverPrivilege` can be used for all sorts of interesting escalation. Future work includes forking an additional process or the like so that we can drop this from the main tunnel process. ### Manager Service diff --git a/docs/netquirk.md b/docs/netquirk.md index c0aa7bf3..5c676f6f 100644 --- a/docs/netquirk.md +++ b/docs/netquirk.md @@ -4,7 +4,7 @@ As part of setting up a WireGuard tunnel, the tunnel service also sets up variou ### Routing -The tunnel service takes all the allowed IPs from each peer, deduplicates them, and adds them to the routes for the WireGuard interface. The service then monitors which interface on the system has a default route (a route with a `/0` CIDR) that is not the WireGuard interface itself, and it uses the [`IP_UNICAST_IF` socket option](https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options) to bind WireGuard's UDP packets to that default route interface. If no MTU has been specified in the configuration, it also sets the MTU of the WireGuard interface to be 80 less than the MTU of that default route interface. If no default route interface can be found, then those outgoing packets are blackholed. If WireGuard packets would ordinarily be routed over a non-default route interface, the use of `IP_UNICAST_IF` forces the packets to, in fact, go over the default route interface. This is problematic, but at this moment, Microsoft has not provided a viable workaround. If any allowed IPs are a `/0`, then the interface is given a `0` metric and Windows' [automatic metric logic](https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes) is disabled. +The tunnel service takes all the allowed IPs from each peer, deduplicates them, and adds them to the routes for the WireGuard interface. The service then monitors which interface on the system has a default route (a route with a `/0` CIDR) that is not the WireGuard interface itself, and, if no MTU has been specified in the configuration, it sets the MTU of the WireGuard interface to be 80 less than the MTU of that default route interface. WireGuardNT also monitors the routing table and determines the outgoing route that does not loopback to itself, and then sends each packet using `IP_PKTINFO`/`IPV6_PKTINFO`. It keeps track of the incoming interface and source address for received packets, and always replies to the sender in that way. ### Firewall Considerations for `/0` Allowed IPs |