Popular VPNs Contained Code Execution Security Flaws, Despite Patches (zdnet.com) 47
Researchers have uncovered vulnerabilities in popular virtual private network (VPN) software, ProtonVPN and NordVPN, which can lead to the execution of arbitrary code by attackers. From a report: Last week, Cisco Talos security researchers said the security flaws, CVE-2018-3952 and CVE-2018-4010, permit code execution by attackers on Microsoft Windows machines. The vulnerabilities are similar to a Windows privilege escalation security flaw uncovered by VerSprite, which is tracked as CVE-2018-10169. Security patches were applied in April by both clients to resolve the original security hole, but according to Talos, "despite the fix, it is still possible to execute code as an administrator on the system." The initial vulnerability was caused by similar design issues in both clients. The interface for both NordVPN and ProtonVPN execute binaries with the permission of a logged-in user, and this includes the selection of a VPN configuration option, such as a desired VPN server location. This information is sent to a service when "connect" is clicked by way of an OpenVPN configuration file. However, VerSprite was able to create a crafted OpenVPN file which could be sent to the service, loaded, and executed.
Why does this keep happening? (Score:4, Insightful)
Intuitively, why can't we come up with some simple conduits that are sufficiently simple and vetted that we can be reasonably sure that ill conditioned inputs can't escape the sandbox. Then and only then build the convenience features on top of this?
Perhaps today's XKCD explains this very problem quite well. Firewalls prevent easy communications between component services.
true. But for a VPN there are a just a few enumerable things it actually needs to do correctly. It doesn't actually need admin priveledges to carry the message just admin priveledges to set up the network tunnels. So how is it possible one can't write a system where the message can execute as root?
I suspects is' because people see some speed shortcut similar ot Active-X or ssh -Y xwindows that values shorcuts.
Re: (Score:2)
In the general case, the reason we can't make "sufficiently simple and vetted that we can be reasonably sure that ill conditioned inputs can't escape the sandbox" is because no one is willing to take the hit in functionality.
As other comments have pointed out, the correct version of this is OpenVPN. But that doesn't allow all the (presumably configuration-related) things that these guys wanted, so they distributed a binary instead that can take commands remotely. Fundamentally, what they want to do could
Re: (Score:2)
Just an FYI, but the programs in question *ARE* OpenVPN based.
Re: (Score:2)
The problem is not OpenVPN. It's everything around it. Configuring a VPN can be tricky or trivial, depending on how many parameters one needs to type in exactly. Some VPN providers have step by step walkthroughs that show every dialog, and every piece of information you need to enter and where to enter it. And of course, there's the one-click installer that does it all for you so you don't have to bother. Because face it - the people who normally
Re: (Score:2)
so they distributed a binary instead that can take commands remotely.
This is a fundamental mistake most people make with cryptography... they do not
realize that the negotiation of configuration options is not a safe operation that just
points an underlying secure tool to the correct endpoints/protocols. It is part of the
security.
Heck even the IPSec standard writers screwed this up a tiny bit (you can downgrade
an IPSec session if you have MITM on the first couple packets of ISAKMP exchange
and both sides have low-grade protocols in their offers). So nobody should expect
a bunc
Re: (Score:2)
Obligatory XKCD: https://xkcd.com/2044 [xkcd.com]
Re: (Score:2)
The amount of time required to validate that a piece of networked software is secure to absolute certainty approaches infinity.
Re: (Score:2)
But for a VPN there are a just a few enumerable things it actually needs to do correctly.
In the *NIX world: Build a bunch of simple utilities that do one thing each very well. If you need complex setup/configuration abilities, wrap it all in some administrative shell scripts.
In the Windows world: It all has to be bundled into a one-size-fits-all hairball of point and click administrative functions.
Re: (Score:2)
Well reading your post only leads me back around to this question: Why are these VPN services writing their own client anyway?
I understand that a VPN client should theoretically not be doing anything terribly complicated and so shouldn't be too hard to write. At the same time, why are they writing their own clients at all? After decades of dealing with VPN, how is it that we still don't have a simple, open, trouble-free VPN system built into the OS?
As far I can can tell, the biggest problem is the same
Re: (Score:3)
Agreed; why don't they at least just say "use the OpenVPN client"?
Of course the most likely answer is "because they want to make it harder to switch VPN providers".
Re: (Score:2)
It is basically a mixture of sabotage (e.g. as IPsec was sabotaged by the NSA by making it very complicated), too cheap development, incompetent developers and management, "Not Invented Here" stupidity and KISS violations. SSH-Tunneling via OpenSSH has had no vulnerabilities for a long time now, but it also has had no new features, because it does not need them.
All this is well-known and you even find these effects in the literature on software engineering. But the people making these bad decisions and desi
Re: (Score:2)
Re: (Score:2)
All ways the security services never had to consider VPN users an issue and always had global collect it all.
Believe it (Score:1)
A few months back I was running OpenVPN in a VM on one of my main Ubuntu systems. I haven't had time to research it or figure out how but someone managed to use an exploit to install a bitcoin miner on it. I only noticed because the 2 CPUs assigned to the VM reported 100% all the time.
So it happens.
Re: (Score:1)
Probably had very little to do with OpenVPN though and more to do with you not knowing how to secure a system.
Re: (Score:1)
Re: (Score:2)
Probably had very little to do with OpenVPN though and more to do with you not knowing how to secure a system.
None of my other Ubuntu VMs with public IP addresses on that very same hypervisor were affected. Not before or since.
Your incorrect conclusions have little to do with my knowledge or lack there of and more to do with your arrogant ignorance.
Re: Believe it (Score:1)
So let's get this straight, you are BLAMING openvpn for installing a miner on your computer. Because that is the claim you are making.
I find that hard to believe that YOU were the only one this happen to.
Re: (Score:2)
Once you know what the miner is, it's trivial to figure out what the infection vector is. I ran across a server used for an insurance company a month back doing the same thing. How'd it get on there? Because someone decided to take it for a tour on the web using an unpatched version of IE.
Re: (Score:2)
That sounds like an automated attack. You probably were behind on patching or made a common configuration mistake. At least you noticed.
It's on WIndows (Score:3)
Wireguard (Score:1)
All these comments, and nobody is talking about Wireguard [wireguard.com]?
are these forks? (Score:2)
The article isn't very clear. Are these forks of openvpn?
I mostly use Cisco AnyConnect for work and ssh tunneling for personal use, but I do have openvpn installed on my laptop and use it occasionally. I was thinking about installing it on my router and using it instead of ssh tunneling but I'm not sure if it's worth it.
I've never heard of either of the vpns mentioned in the article but the way the mix in mention of openvpn config files is confusing. Are the vulnerabilities only in proprietary forks of open