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

Important security vulnerabilities in OpenVPN

guidovranken.wordpress.com

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Important security vulnerabilities in OpenVPN

#31

Post by [deleted] »

lmm wrote: post #25
laumars wrote: post #15

Earlier quoted context omitted.

> Citation needed. I would expect a rewrite guided by an existing implementation (not the same thing as a rewrite aimed at achieving a from-scratch redesign) to result in fewer bugs as it would effectively be equivalent to a full code review, and that's before we take into account the difference-of-language effects. Humans are fallible. Rewriting the code introduces the possibility that the human coding it might make…

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.

[deleted]

Re: Important security vulnerabilities in OpenVPN

#32

Post by amelius »

pjmlp wrote: post #27
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.

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?

Re: Important security vulnerabilities in OpenVPN

#34

Post by dcousens »

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…

This mirrored my confusion when `AES_cbc_encrypt` modified my IV data when _decrypting_.

Re: Important security vulnerabilities in OpenVPN

#35

Post by andy_ppp »

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?

Re: Important security vulnerabilities in OpenVPN

#36

Post by dom0 »

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 ¯\_(ツ)_/¯

Re: Important security vulnerabilities in OpenVPN

#37

Post by verytrivial »

lmm wrote: post #25
laumars wrote: post #15

Earlier quoted context omitted.

> Citation needed. I would expect a rewrite guided by an existing implementation (not the same thing as a rewrite aimed at achieving a from-scratch redesign) to result in fewer bugs as it would effectively be equivalent to a full code review, and that's before we take into account the difference-of-language effects. Humans are fallible. Rewriting the code introduces the possibility that the human coding it might make…

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.

Re: Important security vulnerabilities in OpenVPN

#38

Post by dom0 »

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?

Proper API design and documentation would be quite sufficient, breaking and expensive.

Re: Important security vulnerabilities in OpenVPN

#39

Post by throwanem »

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's still preferable to sending unprotected traffic over an untrusted network. If my VPN clients die, at least I know something's up!

Re: Important security vulnerabilities in OpenVPN

#40

Post by vog »

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/

Post reply on HN