Important security vulnerabilities in OpenVPN

Post by westbywest » Wed, Jun 21, 2017, 2:58 PM UTC

rsync wrote: post #59

OpenVPN is very complicated and for that reason I use sshuttle[1] which is very simple. It does require that you own an sshd running on an endpoint somewhere (like a VPS or an EC2 instance or your own server somewhere) - but if you can clear that hurdle, you end up with a very elegant and simple solution. [1] https://github.com/sshuttle/sshuttle

Post by chrisper » Wed, Jun 21, 2017, 3:09 PM UTC

Post by mikeash » Wed, Jun 21, 2017, 3:16 PM UTC

simias wrote: post #18

Vulnerability #2 is a good example of why OpenSSL is a minefield even for a competent coder. For such a security-critical library it's pretty insane that the API is so unfriendly, bordering on hostile. > The correct way to do this is to call GENERAL_NAMES_free. This is because sk_GENERAL_NAME_free frees only the containing structure, whereas GENERAL_NAMES_free frees the structure AND its items. And later: > Here, the…

Post by sigjuice » Wed, Jun 21, 2017, 3:25 PM UTC

rsync wrote: post #59

OpenVPN is very complicated and for that reason I use sshuttle[1] which is very simple. It does require that you own an sshd running on an endpoint somewhere (like a VPS or an EC2 instance or your own server somewhere) - but if you can clear that hurdle, you end up with a very elegant and simple solution. [1] https://github.com/sshuttle/sshuttle

Post by eeZah7Ux » Wed, Jun 21, 2017, 3:30 PM UTC

willvarfar wrote: post #7

yuchi wrote: post #2

I’m gonna take the burden (someone would do that eventually anyway) and ask: how many of those issues would have been completely prevented by using a safer language such as Rust? How many would have been mitigated? I’m not a system programmer and the article, while indeed interesting, can be a little obscure.

Many of these bugs are specific to memory-unsafe languages. Writing in a memory-safe language would prevent many of these vulnerabilities. It would not stop all vulnerabilities.