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

21–30 of 97 posts

Re: Important security vulnerabilities in OpenVPN

#21

Post by simias »

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.

All of them. But the remaining question is: how many more would've been introduced by rewriting OpenSSL and OpenVPN in a safe language?

I think in the long run it's probably a good idea to do it, once things have settled a bit and there's a clear "winner" in the safe language front. In the meantime it'll be hard to beat the ubiquity and compatibility of a C library like OpenSSL. OpenVPN on the other hand, as a standalone application, could probably be rewritten right now in Rust, Go or Malbolge if somebody cared enough to do it.

Re: Important security vulnerabilities in OpenVPN

#22

Post by alltakendamned »

tinco wrote: post #9
alltakendamned wrote: post #4

Earlier quoted context omitted.

I really think this is the wrong way to look at issues like this. Software has bugs, some of which are security bugs. Whenever someone goes through the effort of looking at software from a security perspective, issues might get identified and resolved and as such there is an incremental increase in security. Switching languages requires a full rewrite, which is often not only impractical, it will introduce new bugs a…

How do Apache and OpenSSH demonstrate that C code can be done right from a security perspective?

By the lack of any serious vulnerabilities over the past years.

If you're willing to give it a go, an Apache bug would've fetched you 200K$ at the latest Pwn2Own.

Re: Important security vulnerabilities in OpenVPN

#23

Post by yuchi »

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.

I expected to be downvoted («the burden») but before you do please keep in mind I’m honestly trying to understand if those issues were preventable by using a different language. Just a honest curious question.

Re: Important security vulnerabilities in OpenVPN

#24

Post by lmm »

tinco wrote: post #16
lmm wrote: post #11

Earlier quoted context omitted.

> Switching languages requires a full rewrite Not true when those languages are ABI-compatible. E.g. I believe librsvg is introducing small amounts of Rust that can eventually become a gradual migration. > it will introduce new bugs as the maturity of the software will plummet because of the rewrite. Citation needed. I would expect a rewrite guided by an existing implementation ( not the same thing as a rewrite aimed…

I fully agree with you. Just a small correction on the rust bugs article that was linked: They're Rust bugs because they violate safety of code the compiler thinks is safe, so they could bite normal users. The effect of such bugs is that the programmer operates under a false feeling of security, which is arguably worse than knowing you have to be mindful of security. Which is also why the Rust developers take these b…

Sorry yes, what I meant was: they happen only in the presence of unsafe code. Of course the symptom can show up outside and that's one reason they're taken very seriously.

Re: Important security vulnerabilities in OpenVPN

#25

Post by lmm »

laumars wrote: post #15
lmm wrote: post #11

Earlier quoted context omitted.

> Switching languages requires a full rewrite Not true when those languages are ABI-compatible. E.g. I believe librsvg is introducing small amounts of Rust that can eventually become a gradual migration. > it will introduce new bugs as the maturity of the software will plummet because of the rewrite. Citation needed. I would expect a rewrite guided by an existing implementation ( not the same thing as a rewrite aimed…

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

Re: Important security vulnerabilities in OpenVPN

#26

Post by Franciscouzo »

yaantc wrote: post #10
akavel wrote: post #5

I don't understand why comment out ASSERTs; wouldn't they actually potentially protect against some of the listed issues? The article mentions they interfere with libFuzzer; but isn't a fuzzer expected to detect and handle crashes as part of its core functionality?

You have two kinds of fuzzers: 1) out of process, like AFL: The application is launched for each test, and there's no problem handling a crash, whatever the cause (asserts are ok). But for each test there's the application start-up (process creation, etc.) overhead. 2) in process, like libFuzzer: The application is launched once only. Then inside the application context the library iterates over the tests. So no appl…

> But for each test there's the application start-up (process creation, etc.) overhead.

That's not completely true, for AFL you have __AFL_INIT(), which defers the initialization of AFL until after an expensive initialization of the program to be fuzzed, which greatly improves performance.

Re: Important security vulnerabilities in OpenVPN

#27

Post by pjmlp »

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 level tricks requires the explicit use of the pseudo-module SYSTEM.

But I can go further to 1961 and ESPOOL and NEWP, Algol dialects for Burroughs B5500 systems programming, which already supported the use of then known as UNSAFE attributes for such low level coding outside Algol strong typing.

Although they would still allow for memory leaks or the error of freeing unallocated memory, but they would panic for the later, instead of the UB in C.

Re: Important security vulnerabilities in OpenVPN

#28

Post by Kurtz79 »

jagermo wrote: post #14
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.

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.

Re: Important security vulnerabilities in OpenVPN

#29

Post by [deleted] »

sillysaurus3 wrote: post #20
willvarfar wrote: post #13

Earlier quoted context omitted.

Eh hmm OpenSSL is infamously bad at security? There have been numerous critical bugs, and numerous criticism of its codebase, and numerous rewrites and migrations away from it! This is why the wikipedia page for OpenSSL https://en.wikipedia.org/wiki/OpenSSL lists notable vulnerabilities and even a list of forks away from it!

Well, yes. And now those bugs are fixed. Meanwhile, it's one of the most popular security libraries on the planet. The fact that everybody uses it means you're unlikely to be burned by any given vulnerability since every vulnerability impacts a huge number of people. From a security perspective, the worst situation to be in is where you're using some obscure library that has a critical flaw that nobody notices becaus…

[deleted]

Re: Important security vulnerabilities in OpenVPN

#30

Post by yaantc »

Ded7xSEoPKYNsDd wrote: post #17
yaantc wrote: post #10

Earlier quoted context omitted.

You have two kinds of fuzzers: 1) out of process, like AFL: The application is launched for each test, and there's no problem handling a crash, whatever the cause (asserts are ok). But for each test there's the application start-up (process creation, etc.) overhead. 2) in process, like libFuzzer: The application is launched once only. Then inside the application context the library iterates over the tests. So no appl…

Why not change asserts (they are macros after all) to tell the fuzzing library that it found an error? Finding bugs is the whole point of the exercise, isn't it?

From a quick look at the doc (http://llvm.org/docs/LibFuzzer.html) this doesn't seem to be supported.

Aborting from an assert deep in the code has some challenges: unwinding the stack is ok, but how one would avoid memory leaks for heap data? It would require trapping all mallocs to track all allocated data and free it. Not impossible but it adds very significant complexity, and that doesn't seem the philosophy of libFuzzer. It seems to me that the goal of libFuzzer is to be very easy to use (just define one function for test harness, compile with CLANG and fuzzying flag, done) and efficient on an already reasonably well behaved library.

It makes sense to me: just start with AFL, which has no problems with crashes. When you reach AFL limits and need more efficiency, only then move to libFuzzer (both can shared state / test framework). Then the assumption that the app. is reasonably well behaved makes sense.

Caveat: I haven't used libFuzzer yet. For the reason above, I'm just using AFL for now. Maybe one day but I'm not there yet ;)

Post reply on HN