Important security vulnerabilities in OpenVPN • Hacker News Board

Re: Important security vulnerabilities in OpenVPN

#41

Post by pjmlp » Wed, Jun 21, 2017, 1:32 PM UTC

amelius wrote: post #32

pjmlp wrote: post #27

Earlier quoted context omitted.

Using a more safer systems programming language like Modula-2 (1978), would prevent in regards to C: - Out-of-bonds array and string access - Implicit type conversions - Accessing null pointers - Using pointers for output parameters - Casting integers to invalid enumeration values - Incompatible casts between data types - Allocating less memory than actually required In Modula-2 anything that requires C like low leve…

What would the performance penalty be?

Depends on the compiler.

What many younger generation seem to miss is that in the 80's C compilers were pretty lame, most junior Assembly programmers could easily out perform them.

The current state of C compiler performance is the outcome of almost 40 years of research in compiler optimizations for C, not anything of the language itself.

Also for those that prefer "Performance trumps correctness" way of thinking, some compilers offered ways to disable those checks.

But for anyone that thinks "Performance trumps correctness" is worthwhile, I advise to read C.A.R Hoare Turing award speech about the responsibility of software engineers, Algol use by the industry and law, done in 1981.

Re: Important security vulnerabilities in OpenVPN

#42

Post by mkj » Wed, Jun 21, 2017, 1:33 PM UTC

throwanem wrote: post #39

ProxCoques wrote: post #3

So I just installed ovpn on my phone just now. First place I go to test it is HN. And this story is literally top of the list. Sigh.

I'm not sure these are so dangerous as all that. I see some server and client crashes, but nothing that'd allow transparent MITM, RCE, or the like. Perhaps there's something I have missed, and if so I hope someone more knowledgeable here will point it out - but right now I don't intend to stop using OpenVPN, because even if it's possible that a malicious network might crash the VPN stack on my phone or similar, that'…

A double-free can traditionally allow remote code execution. Maybe modern libc mitigations will protect you, maybe not.

Re: Important security vulnerabilities in OpenVPN

#43

Post by ccrush » Wed, Jun 21, 2017, 1:41 PM UTC

Kurtz79 wrote: post #28

jagermo wrote: post #14

Earlier quoted context omitted.

Someone else trying out Protonvpn, I see :)

You don't need necessarily to be using a specific service. You can configure your own OpenVPN server quite easily, and use the available vanilla client applications to connect to it.

The fun part is that a somewhat premium (read: more bandwidth) VPN option will cost around the same as a lower tier VPS. So, if you're willing to put up with the 10-15 commands, editing a couple configuration files, and copying config and cert files over, you can get your own VPN and a Linux server to use.

Re: Important security vulnerabilities in OpenVPN

#44

Post by verytrivial » Wed, Jun 21, 2017, 1:47 PM UTC

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.

.. Or in a language designed for proof of correctness? See e.g. https://mitls.org/ -- I think this is very important work. Imagine only dealing with bugs in the spec?

Maybe one day, when all the hearts are finally bled, something like this will become the default unless and until you have a proven^1 unmet performance requirement, and only then after you've spoken to your lawyers.

1. Pun intended.

Re: Important security vulnerabilities in OpenVPN

#45

Post by Spivak » Wed, Jun 21, 2017, 1:50 PM UTC

ccrush wrote: post #43

Kurtz79 wrote: post #28

Earlier quoted context omitted.

You don't need necessarily to be using a specific service. You can configure your own OpenVPN server quite easily, and use the available vanilla client applications to connect to it.

The fun part is that a somewhat premium (read: more bandwidth) VPN option will cost around the same as a lower tier VPS. So, if you're willing to put up with the 10-15 commands, editing a couple configuration files, and copying config and cert files over, you can get your own VPN and a Linux server to use.

Right, but for certain classes of users, VPN as a service offers anonymity and endpoints around the world.

Re: Important security vulnerabilities in OpenVPN

#46

Post by simias » Wed, Jun 21, 2017, 1:51 PM UTC

andy_ppp wrote: post #35

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…

> You're never sure at a glance what's an input or an output parameter, what needs to be freed and how you're supposed to free it. Terrifying; would a more functional style of programming help here?

Using "const" consistently would be a good start. Better and more thorough docs would be nice as well.

If you're willing to break everything a more consistent API in general, especially when it comes to error handling, would make it less easy to shoot yourself in the foot.

It's the overall inconsistency of the OpenSSL API that's the main issue IMO. If the coder or code reviewer don't know all the function signatures and return values by heart it's very easy to write code that looks absolutely fine, might seem to run fine but is thoroughly broken. TFA is a good example of that.

That's why nowadays I much prefer using the Rust bindings over the raw C library. The error handling and ownership rules are checked by the compiler, it's like putting blanks in your footgun. It's liberating really.

Re: Important security vulnerabilities in OpenVPN

#47

Post by lmm » Wed, Jun 21, 2017, 2:05 PM UTC

verytrivial wrote: post #37

lmm wrote: post #25

Earlier quoted context omitted.

True as far as it goes, but I would still expect the bugs caught by the rewrite to outweigh the newly-introduced ones most of the time.

This has not been my experience in the last couple of decades.

How many rewrites-that-involved-no-redesign have you done?

Re: Important security vulnerabilities in OpenVPN

#48

Post by baby » Wed, Jun 21, 2017, 2:07 PM UTC

vog wrote: post #40

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…

The LibreSSL fork tries to do exactly that: Although they still provide the original OpenSSL API for existing applications, they add a much simpler and hassle-free API on top of it ("libtls" [1]), with the goal that all applications will be switched part-by-part to the new interface. [1] https://www.openbsd.org/papers/libtls-fsec-2015/

Does it make sense to stop recommending OpenSSL and start recommending LibreSSL now?

Re: Important security vulnerabilities in OpenVPN

#49

Post by shmerl » Wed, Jun 21, 2017, 2:13 PM UTC

A lot of such stuff can be avoided by simply using Rust.

Re: Important security vulnerabilities in OpenVPN

#50

Post by kbenson » Wed, Jun 21, 2017, 2:16 PM UTC

dom0 wrote: post #36

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…

> you have to quadruple check each function invocation with the docs to make sure you got it right. If the docs contain that information ¯\_(ツ)_/¯

There's always a trade-off between how complicated the docs and usage are and how many people will use it. OpenSSL is problematic because it has very complicated docs and usage, but people still used it anyway. This leads to a situation where people use it incorrectly, and for a crypto library, that's a very bad thing.

If OpenSSL wasn't the de facto king of OSS crypto libraries for so long (partly because it was the only one for so long), then people might have been able to make more informed choices about what library was better.