Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard: next generation in-kernel modern VPN

wireguard.io

Post reply on HN
Print view View original

51–60 of 157 posts

Re: WireGuard: next generation in-kernel modern VPN

#51

Post by wepple »

tptacek wrote: post #44
artie_effim wrote: post #42

Earlier quoted context omitted.

So, everyone needs to take a deep breath here. In kernel VPN is giving me a bit of a security heart attack. As a security professional I would recommend not running this on anything but a sandbox that isn't connected to your environment. A single misstep in the code, a bad implementation of a crypto library or a bad hook could easily lead to ring 0 compromise. Not trying to discount the author's work, and I haven't r…

As a "security professional", I kind of don't care whether this is in-kernel or not. First, this is Linux, and if someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low. Second, and more importantly, this is VPN software . If your VPN gets popped, you probably have bigger problems than whether the attacker got the kernel on t…

I'm curious, you don't agree that the complexity of an access vuln + privesc vuln is a better defender position than a single vuln to ring-0?

It kind of seems to fly in the face of the multiple layers of userland and kernel separation engineering we've seen go into other attack surfaces like browsers?

Re: WireGuard: next generation in-kernel modern VPN

#52

Post by tptacek »

wepple wrote: post #51
tptacek wrote: post #44

Earlier quoted context omitted.

As a "security professional", I kind of don't care whether this is in-kernel or not. First, this is Linux, and if someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low. Second, and more importantly, this is VPN software . If your VPN gets popped, you probably have bigger problems than whether the attacker got the kernel on t…

I'm curious, you don't agree that the complexity of an access vuln + privesc vuln is a better defender position than a single vuln to ring-0? It kind of seems to fly in the face of the multiple layers of userland and kernel separation engineering we've seen go into other attack surfaces like browsers?

All things being equal I do think it's better to be in the former position than the latter.

But all things are not equal. Any code execution on the VPN server practically implies that the attacker controls the VPN, which is game-over for most VPNs I've ever worked with. So my priority would be "not having those kinds of vulnerabilities at all". I'd rather have simpler, easier-to-audit code than userland, if I have to choose one.

Re: WireGuard: next generation in-kernel modern VPN

#53

Post by tptacek »

teacup50 wrote: post #50
tptacek wrote: post #44

Earlier quoted context omitted.

As a "security professional", I kind of don't care whether this is in-kernel or not. First, this is Linux, and if someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low. Second, and more importantly, this is VPN software . If your VPN gets popped, you probably have bigger problems than whether the attacker got the kernel on t…

> As a "security professional", I kind of don't care whether this is in-kernel or not. As a "kernel professional", I'm laughing incredulously at this. A lot.

Do go on.

Re: WireGuard: next generation in-kernel modern VPN

#54

Post by zx2c4 »

hueving wrote: post #41

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.

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.

Re: WireGuard: next generation in-kernel modern VPN

#55

Post by nickpsecurity »

Retr0spectrum wrote: post #45
tptacek wrote: post #44

Earlier quoted context omitted.

As a "security professional", I kind of don't care whether this is in-kernel or not. First, this is Linux, and if someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low. Second, and more importantly, this is VPN software . If your VPN gets popped, you probably have bigger problems than whether the attacker got the kernel on t…

"If someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low." Could you provide some sources/examples for this?

For an alternative view, having the apps in user-mode with mandatory controls and such has isolated many real-world vulnerabilities. Even in the shoddy, inadequate implementation that is SELinux. Further, as attackers are battling constraints, they increase odds of generating logs that detect their presence via the unauthorized behaviors. There's also products and prototypes that constantly read memory to find anomolous patterns that depend on kernel or hypervisor layer integrity. The protections get even stronger if using microkernel, capability, pointer, or tainting protection.

So, despite severity of VPN-level compromise, there's advantages mainly in detection and damage limitations if it's a strongly-constrained process. Hell, I've done prototypes that used fixed memory with only networking privileges needed that logged their own behavior to immutable storage. You could compare the execution and logging to a profile. Outside that range, it was a crash or attack. Clive Robinson taught me that last part. Others were Orange and Red Book 101.

Re: WireGuard: next generation in-kernel modern VPN

#56

Post by zx2c4 »

artie_effim wrote: post #42
Retr0spectrum wrote: post #5

Can someone explain why being in-kernel is considered a feature?

So, everyone needs to take a deep breath here. In kernel VPN is giving me a bit of a security heart attack. As a security professional I would recommend not running this on anything but a sandbox that isn't connected to your environment. A single misstep in the code, a bad implementation of a crypto library or a bad hook could easily lead to ring 0 compromise. Not trying to discount the author's work, and I haven't r…

Answered in this thread here: https://news.ycombinator.com/item?id=11995389

Re: WireGuard: next generation in-kernel modern VPN

#58

Post by derefr »

tptacek wrote: post #43
hueving wrote: post #41

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.

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.…

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.

Re: WireGuard: next generation in-kernel modern VPN

#59

Post by dmix »

tptacek wrote: post #43
hueving wrote: post #41

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.

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.…

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.

Re: WireGuard: next generation in-kernel modern VPN

#60

Post by tptacek »

derefr wrote: post #58
tptacek wrote: post #43

Earlier quoted context omitted.

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.…

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 malfo…

NTFS is way, way, way, way, way more complicated than any VPN, and this particular VPN was designed to avoid complexity.
Post reply on HN