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

11–20 of 97 posts

Re: Important security vulnerabilities in OpenVPN

#11

Post by lmm »

alltakendamned wrote: post #4
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 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…

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

> As such, new languages are unproven in the security area and there will be security bugs found there as well.

No. There are specific reasons C is so awful; it's not a question of maturity.

> Java and .NET don't have the same issues either but somehow nobody will ask about those :)

People are dumb. There's a popular myth that these languages are inherently slow, which combined with some genuine licensing issues means the OSS community doesn't use them, even though they'd be a perfect fit for OpenVPN-like processes.

> But then again, Rust introduces other bug types for which the future will tell whether they have a security impact or not: https://gankro.github.io/blah/only-in-rust/

No, read your link. Those issues happen only in unsafe code, and at absolute worst mean you're as badly off as you would be in C.

> software like Apache httpd and OpenSSH demonstrates clearly it can be done

Because those programs can go years at a time without a major security vulnerability? Oh wait, no they can't.

Switching languages is absolutely the answer, and the sooner we get over ourselves and get on with it the better.

Re: Important security vulnerabilities in OpenVPN

#12

Post by insanebits »

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?

As I understand it he disabled asserts in places which would certainly fail, like doing system stuff, modifying system state and such, but not actual relevant parts.

Re: Important security vulnerabilities in OpenVPN

#13

Post by willvarfar »

sillysaurus3 wrote: post #8
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.

OpenSSL's security is hard to beat. Constant code audits plus massive usage equals pretty secure software. The vulns in the blog post are denial of service bugs: memory exhaustion and an assertion crash. While these good to fix, they have little impact on security. You're much more likely to introduce hundreds of bugs attempting to port it to Rust than just maintaining OpenSSL's C code. Of course, you could try porti…

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!

Re: Important security vulnerabilities in OpenVPN

#15

Post by laumars »

lmm wrote: post #11
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…

> 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 a mistake. This is true even when using existing code as a guide.

Re: Important security vulnerabilities in OpenVPN

#16

Post by tinco »

lmm wrote: post #11
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…

> 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 bugs very seriously.

Re: Important security vulnerabilities in OpenVPN

#17

Post by Ded7xSEoPKYNsDd »

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…

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?

Re: Important security vulnerabilities in OpenVPN

#18

Post by simias »

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 code assumes that a return value that is negative or zero indicates failure, and ‘buf’ is not initialized, and needs not to be freed. But in fact, this is ONLY the case if ASN1_STRING_to_UTF8 returns a negative value. A return value 0 simply means a string of length 0, but memory is nonetheless allocated, so there are memory leaks here as well.

It mirrors my experience working with OpenSSL: you have to quadruple check each function invocation with the docs to make sure you got it right. 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. What's the return value in case of error? 0? -1? Let me be clear: I don't blame the OpenSSL devs in any way. It's free, it's open source, they don't get a ton of money for that. Instead I blame all the big corporations who use OpenSSL "as-is", directly or indirectly, and don't invest some money to improve that mess. Maybe after a couple more Heartbleed-like vulnerabilities they'll take it a little more seriously.

Re: Important security vulnerabilities in OpenVPN

#19

Post by rainforest »

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 might want to preserve the test case as it's found an interesting code path. You could keep it around so tests generated from it cover similar paths, possibly without reaching the assertion.

Re: Important security vulnerabilities in OpenVPN

#20

Post by sillysaurus3 »

willvarfar wrote: post #13
sillysaurus3 wrote: post #8

Earlier quoted context omitted.

OpenSSL's security is hard to beat. Constant code audits plus massive usage equals pretty secure software. The vulns in the blog post are denial of service bugs: memory exhaustion and an assertion crash. While these good to fix, they have little impact on security. You're much more likely to introduce hundreds of bugs attempting to port it to Rust than just maintaining OpenSSL's C code. Of course, you could try porti…

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 because it's obscure. At that point, a reasonably competent pentester will make your app sing and dance, and you won't know until too late.

If you stick with OpenSSL, you leverage the massive investment of resources being poured into it.

Post reply on HN