7 ms·

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiri

by hueving 10y ago

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.

tptacek 10y ago
Severe performance impact. Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread: Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. In a serious VPN deployment, if you lose code execution on the VPN server, whether the attacker took the kernel or just a userland process is somewhat far down the list of concerns you have to deal with. A better first concern is "how many machines inside the VPN did the attacker just get code execution on because they can now make direct TCP connections to all our internal services". From that vantage point, I'm a little less concerned about whether my VPN server is at CPL0, and a lot more concerned with things like "how complex is this code and how straightforward is it to audit".
- derefr 10y ago
  I'm guessing the parent wasn't really considering the kernel/userland distinction in terms of security (for, after all, a daemon running as root in userland isn't all that different from running in the kernel in terms of attack surface; the real security boundary lies between privileged/unprivileged in userland, not between kernel and userland.) Rather, I expect what the parent wanted to assert was that a novel malformed packet to a badly written VPN shouldn't bring down the entire VPN gateway machine, but rather just the VPN daemon itself, which can then be brought back up by init(8). Or, to put it another way—even though the Linux kernel is monolithic, it can still pay to treat it as a microkernel and isolate fault-prone code outside of it. This was one of the original big benefits of running e.g. the NTFS-3G in FUSE, when that support was experimental: the NTFS-3G driver did crash—often!—and your OS stayed up. The—usually external—drive would just get unmounted, and have to be fsck(8)ed. Now, the argument you used also kind of answers this: in full deployments, we've got dedicated VPN gateways on either side of the connection, so if the VPN process crashes, the whole machine may as well have crashed, since it's not doing much of anything else anyway. That's probably true for most networks, but I could think of one exception: a VPN gateway serving multiple customer sites. You'd really rather that one VPN "receiver" process crash on that host (like one webserver instance serving one request) than that the whole machine crash.
  - tptacek 10y ago
    NTFS is way, way, way, way, way more complicated than any VPN, and this particular VPN was designed to avoid complexity.
- dmix 10y ago
  And getting from userspace -> kernel doesn't pose much of a challenge for attackers. Especially on stock Ubuntu machines that are so popular. You could probably even find priv esc exploits on github/blogs for a good chunk of VPS servers. I did that when I forgot a root password on a yr old machine recently.
  - code_research 10y ago
    Interesting! Would you please like to post some links to actual privilege escalation code for a stock Ubuntu 16.04 - thank you very much for your attention!
- comex 10y ago
  Who said anything about VPN server? The client is running the same code; what if it's popped? > But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. You're missing the other big use case: VPNs used to get one's internet access through a different network, in order to evade the Great Firewall, limit NSA surveillance, increase security on public Wi-Fi networks, or just watch Netflix in the 'wrong' country. These are often commercial (not that commercial VPNs are going to use WireGuard as long as it's Linux only, but hopefully it'll be ported to other OSes before long). In this case there are two ways the client could be attacked: the network itself could be modifying packets or doing a MitM attack, or the server could be hostile (either after being hacked itself [maybe with the same exploit] or, mostly applicable to government attacks, because it was set up as a honeypot). With a network attack, the VPN code is one of the only bits of attack surface available to the attacker, especially if they don't know your IP on the other end. A hostile VPN server you route all internet access through, in comparison, already has quite a lot of power over you (hopefully you access all important services over TLS), and at the very least makes it easy to deliver (easier-to-find) browser exploits - but in theory the VPN implementation provides some additional attack surface which bypasses all sandboxes. Also, paranoid users may have a setup where their browsing is done inside a VM, whose connection is routed through a VPN on the host end. This helps ensure that they're not accidentally passing traffic through the wrong interface or leaking their real IP, and provides some protection against attackers who get code execution with the goal of finding said IP (see FBI Tor malware). In such a setup, any networking code running outside the VM is an interesting target. Linux isn't all that secure against unsandboxed user processes, but VPN code has a simple enough interface that it could in theory be sandboxed effectively using seccomp-bpf. The Great Firewall tries to block VPNs anyway, so a Chinese attack isn't all that realistic as things stand, but who knows, it might be nice if WireGuard grew some kind of obfuscation support. And that leaves the NSA and others. Anyway, I don't actually think there's a problem with WireGuard living in the kernel! - because I don't think it presents much attack surface. It's a very small codebase, and performance is important for these applications. Actually, I wholeheartedly approve of WireGuard: it seems like a really nice design, and I've experienced the pain of just getting other VPN implementations to work, never mind securely. But if there is a vulnerability in WireGuard, then for the reasons I've stated, I think its placement in the kernel matters.
- hueving 10y ago
  I was not concerned about it from a security perspective at all. What I'm concerned about is poor software engineering. The fact that something like a particular flavor of VPN needs to be integrated directly into the kernel smells to me like a shortcut to skip improving the kernel to enable better userland networking code. Why this VPN proto and not the next hot item of the month? How about we start throwing some load balancing code directly into the kernel? How about some TLS termination?
  - tristor 10y ago
    > How about we start throwing some load balancing code directly into the kernel? You mean like lvs/ipvs? [0] > How about some TLS termination? You mean like the KTLS project from Dave Watson/Facebook Engineering? [1][2] [0] http://www.linuxvirtualserver.org/software/index.html http://www.linuxvirtualserver.org/software/index.html [1] https://github.com/ktls/af_ktls https://github.com/ktls/af_ktls [2] https://lwn.net/Articles/666509/ https://lwn.net/Articles/666509/
zx2c4 10y ago
Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows for a single individual to audit it. By focusing on simplicity and ease-of-auditability, I hope to achieve something that can be considered secure. Compare this to the massive codebase of OpenVPN/OpenSSL and the various other userspace (read: slow as mollasses) VPNs. WireGuard is considerably shorter and simpler than those too. Also, keep in mind that on Linux, jumping from userspace to ring0 execution isn't exactly difficult. So in practice I'm not sure it matters. I make a living by exploiting kernels. This makes me very aware of the questions associated with running this in the kernel. I've tried to write WireGuard using my experience breaking similar codebases; WireGuard is short enough that it should receive the thorough attention that this sort of software deserves. By focusing on simplicity, I think we can in time achieve something quite trustworthy. Finally, there will be a (necessarily lower speed) cross platform implementation released that's written in Rust. At the end of the day I suspect that all parties will find themselves pleased.
- steveklabnik 10y ago
  I am extremely excited to see the Rust version of this; how do I learn about it when it ships?
  - zx2c4 10y ago
    Join the mailing list! https://lists.zx2c4.com/mailman/listinfo/wireguard https://lists.zx2c4.com/mailman/listinfo/wireguard And if you're savvy and want to get involved with development, we need all the help we can find!
    - tinco 10y ago
      Why necessarily lower speed? Are you hinting at bounds checking? I would think that a rust implementation might have slightly more pressure on the CPU but would not effectively be slower. Am I wrong?
lobster_johnson 10y ago
Tinc [1] is a userspace VPN, and a good demonstration of how slow networking gets when done that way, compared to kernel-mode VPN routing such as IPsec and VxLAN. [1] https://www.tinc-vpn.org https://www.tinc-vpn.org
cm3 10y ago
Because of the kernel/userspace model of Linux and missing efficient microkernel structure which would lend itself more fittingly to an efficient network tunnel. We're using monolithic kernels because they've attracted the most driver support over the years, but with things like seL4 out in the open, this is bound to change because there's no argument that there's no modern microkernel available to build hardware drivers on. On top of stability, you also get a viable capability system in seL4.
- Animats 10y ago
  This is a good application for seL4. As has been pointed out, the machine running this probably does nothing else. So you don't need 99% of Linux. The less irrelevant code you have around in a security box, the better. The attack surface shrinks.

by hueving 10y ago

Why is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.

tptacek 10y ago

Severe performance impact. Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread: Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. In a serious VPN deployment, if you lose code execution on the VPN server, whether the attacker took the kernel or just a userland process is somewhat far down the list of concerns you have to deal with. A better first concern is "how many machines inside the VPN did the attacker just get code execution on because they can now make direct TCP connections to all our internal services". From that vantage point, I'm a little less concerned about whether my VPN server is at CPL0, and a lot more concerned with things like "how complex is this code and how straightforward is it to audit".

derefr 10y ago
I'm guessing the parent wasn't really considering the kernel/userland distinction in terms of security (for, after all, a daemon running as root in userland isn't all that different from running in the kernel in terms of attack surface; the real security boundary lies between privileged/unprivileged in userland, not between kernel and userland.) Rather, I expect what the parent wanted to assert was that a novel malformed packet to a badly written VPN shouldn't bring down the entire VPN gateway machine, but rather just the VPN daemon itself, which can then be brought back up by init(8). Or, to put it another way—even though the Linux kernel is monolithic, it can still pay to treat it as a microkernel and isolate fault-prone code outside of it. This was one of the original big benefits of running e.g. the NTFS-3G in FUSE, when that support was experimental: the NTFS-3G driver did crash—often!—and your OS stayed up. The—usually external—drive would just get unmounted, and have to be fsck(8)ed. Now, the argument you used also kind of answers this: in full deployments, we've got dedicated VPN gateways on either side of the connection, so if the VPN process crashes, the whole machine may as well have crashed, since it's not doing much of anything else anyway. That's probably true for most networks, but I could think of one exception: a VPN gateway serving multiple customer sites. You'd really rather that one VPN "receiver" process crash on that host (like one webserver instance serving one request) than that the whole machine crash.
- tptacek 10y ago
  NTFS is way, way, way, way, way more complicated than any VPN, and this particular VPN was designed to avoid complexity.
dmix 10y ago
And getting from userspace -> kernel doesn't pose much of a challenge for attackers. Especially on stock Ubuntu machines that are so popular. You could probably even find priv esc exploits on github/blogs for a good chunk of VPS servers. I did that when I forgot a root password on a yr old machine recently.
- code_research 10y ago
  Interesting! Would you please like to post some links to actual privilege escalation code for a stock Ubuntu 16.04 - thank you very much for your attention!
comex 10y ago
Who said anything about VPN server? The client is running the same code; what if it's popped? > But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. You're missing the other big use case: VPNs used to get one's internet access through a different network, in order to evade the Great Firewall, limit NSA surveillance, increase security on public Wi-Fi networks, or just watch Netflix in the 'wrong' country. These are often commercial (not that commercial VPNs are going to use WireGuard as long as it's Linux only, but hopefully it'll be ported to other OSes before long). In this case there are two ways the client could be attacked: the network itself could be modifying packets or doing a MitM attack, or the server could be hostile (either after being hacked itself [maybe with the same exploit] or, mostly applicable to government attacks, because it was set up as a honeypot). With a network attack, the VPN code is one of the only bits of attack surface available to the attacker, especially if they don't know your IP on the other end. A hostile VPN server you route all internet access through, in comparison, already has quite a lot of power over you (hopefully you access all important services over TLS), and at the very least makes it easy to deliver (easier-to-find) browser exploits - but in theory the VPN implementation provides some additional attack surface which bypasses all sandboxes. Also, paranoid users may have a setup where their browsing is done inside a VM, whose connection is routed through a VPN on the host end. This helps ensure that they're not accidentally passing traffic through the wrong interface or leaking their real IP, and provides some protection against attackers who get code execution with the goal of finding said IP (see FBI Tor malware). In such a setup, any networking code running outside the VM is an interesting target. Linux isn't all that secure against unsandboxed user processes, but VPN code has a simple enough interface that it could in theory be sandboxed effectively using seccomp-bpf. The Great Firewall tries to block VPNs anyway, so a Chinese attack isn't all that realistic as things stand, but who knows, it might be nice if WireGuard grew some kind of obfuscation support. And that leaves the NSA and others. Anyway, I don't actually think there's a problem with WireGuard living in the kernel! - because I don't think it presents much attack surface. It's a very small codebase, and performance is important for these applications. Actually, I wholeheartedly approve of WireGuard: it seems like a really nice design, and I've experienced the pain of just getting other VPN implementations to work, never mind securely. But if there is a vulnerability in WireGuard, then for the reasons I've stated, I think its placement in the kernel matters.
hueving 10y ago
I was not concerned about it from a security perspective at all. What I'm concerned about is poor software engineering. The fact that something like a particular flavor of VPN needs to be integrated directly into the kernel smells to me like a shortcut to skip improving the kernel to enable better userland networking code. Why this VPN proto and not the next hot item of the month? How about we start throwing some load balancing code directly into the kernel? How about some TLS termination?
- tristor 10y ago
  > How about we start throwing some load balancing code directly into the kernel? You mean like lvs/ipvs? [0] > How about some TLS termination? You mean like the KTLS project from Dave Watson/Facebook Engineering? [1][2] [0] http://www.linuxvirtualserver.org/software/index.html http://www.linuxvirtualserver.org/software/index.html [1] https://github.com/ktls/af_ktls https://github.com/ktls/af_ktls [2] https://lwn.net/Articles/666509/ https://lwn.net/Articles/666509/

zx2c4 10y ago

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase. WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows for a single individual to audit it. By focusing on simplicity and ease-of-auditability, I hope to achieve something that can be considered secure. Compare this to the massive codebase of OpenVPN/OpenSSL and the various other userspace (read: slow as mollasses) VPNs. WireGuard is considerably shorter and simpler than those too. Also, keep in mind that on Linux, jumping from userspace to ring0 execution isn't exactly difficult. So in practice I'm not sure it matters. I make a living by exploiting kernels. This makes me very aware of the questions associated with running this in the kernel. I've tried to write WireGuard using my experience breaking similar codebases; WireGuard is short enough that it should receive the thorough attention that this sort of software deserves. By focusing on simplicity, I think we can in time achieve something quite trustworthy. Finally, there will be a (necessarily lower speed) cross platform implementation released that's written in Rust. At the end of the day I suspect that all parties will find themselves pleased.

steveklabnik 10y ago
I am extremely excited to see the Rust version of this; how do I learn about it when it ships?
- zx2c4 10y ago
  Join the mailing list! https://lists.zx2c4.com/mailman/listinfo/wireguard https://lists.zx2c4.com/mailman/listinfo/wireguard And if you're savvy and want to get involved with development, we need all the help we can find!
  - tinco 10y ago
    Why necessarily lower speed? Are you hinting at bounds checking? I would think that a rust implementation might have slightly more pressure on the CPU but would not effectively be slower. Am I wrong?

lobster_johnson 10y ago

Tinc [1] is a userspace VPN, and a good demonstration of how slow networking gets when done that way, compared to kernel-mode VPN routing such as IPsec and VxLAN. [1] https://www.tinc-vpn.org https://www.tinc-vpn.org

cm3 10y ago

Because of the kernel/userspace model of Linux and missing efficient microkernel structure which would lend itself more fittingly to an efficient network tunnel. We're using monolithic kernels because they've attracted the most driver support over the years, but with things like seL4 out in the open, this is bound to change because there's no argument that there's no modern microkernel available to build hardware drivers on. On top of stability, you also get a viable capability system in seL4.

Animats 10y ago
This is a good application for seL4. As has been pointed out, the machine running this probably does nothing else. So you don't need 99% of Linux. The less irrelevant code you have around in a security box, the better. The attack surface shrinks.