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

51–60 of 97 posts

Re: Important security vulnerabilities in OpenVPN

#51

Post by steveklabnik »

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…

> It'd certainly be an interesting challenge.

See https://crates.io/crates/ring, which is a port of BoringSSL -> Rust + asm. It still has a lot of C in it, but it's slowly melting away.

Re: Important security vulnerabilities in OpenVPN

#52

Post by throwanem »

mkj wrote: post #42
throwanem wrote: post #39

Earlier quoted context omitted.

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 mitigation​s will protect you, maybe not.

Fair point. But it looks like the scope on that one is pretty limited:

> There are several issues in the extract_x509_extension() function in ssl_verify_openssl.c. This function is called if the user has used the ‘x509-username-field’ directive in their configuration.

That option, per [1], appears to exist in order to support odd TLS certificates that don't use the CN field as an identifier, and is also behind a configure #define that appears not to be enabled by default. So that, if I'm reading this right, is a pretty narrow attack surface in general - not inconsiderable, to be sure, but something of a corner case.

[1] https://community.openvpn.net/openvpn/attachment/ticket/124/...

Re: Important security vulnerabilities in OpenVPN

#53

Post by tinco »

alltakendamned wrote: post #22
tinco wrote: post #9

Earlier quoted context omitted.

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.

Over the past years Apache httpd has had 187 vulnerabilities, 24 of which had potential remote code execution consequences.

I'm not saying anyone is ever going to find another RCE in Apache. I'll even go as far as to say it's not very likely.

But I don't think develop a server and then put it in the world's most hostile environments for 20 years until we're certain it's safe is a particularily efficient development strategy.

People should stop building stuff in C, it's that simple.

Re: Important security vulnerabilities in OpenVPN

#54

Post by ianai »

simias wrote: post #46
andy_ppp wrote: post #35

Earlier quoted context omitted.

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

Maybe a wrapper API for OpenVPN/SSL that attempts to Do It Rightunder the hood would be worthwhile?

Re: Important security vulnerabilities in OpenVPN

#55

Post by hannob »

alltakendamned wrote: post #22
tinco wrote: post #9

Earlier quoted context omitted.

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.

This was pretty bad for openssh: https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...

Re: Important security vulnerabilities in OpenVPN

#56

Post by omginternets »

tinco wrote: post #53
alltakendamned wrote: post #22

Earlier quoted context omitted.

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.

Over the past years Apache httpd has had 187 vulnerabilities, 24 of which had potential remote code execution consequences. I'm not saying anyone is ever going to find another RCE in Apache. I'll even go as far as to say it's not very likely. But I don't think develop a server and then put it in the world's most hostile environments for 20 years until we're certain it's safe is a particularily efficient development s…

>People should stop building stuff in C, it's that simple.

I would attenuate this in one sense and amplify it in another: it's (almost always) irresponsible to write network-facing code in C.

Re: Important security vulnerabilities in OpenVPN

#57

Post by omginternets »

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…

> And now those bugs are fixed

"Those bugs" are bad enough that they should have never been there. Moreover they exist only because the codebase was for all intents and purposes unmaintainable.

Given the above, I wouldn't be so sure there are no more bugs.

Re: Important security vulnerabilities in OpenVPN

#58

Post by duneroadrunner »

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

It's not ready for use in the wild, but I'll just mention that some good progress is being made on a "C to SaferCPlusPlus[1]" auto-translation assistant. (SaferCPlusPlus is essentially a memory-safe subset of C++.) At this point it can recognize arrays and "pointers used as array iterators" in C code and replace them with memory-safe substitutes. Hopefully an (incomplete but) usable version will be available before long and we can gauge the interest of developers/maintainers.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Re: Important security vulnerabilities in OpenVPN

#59

Post by rsync »

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

Re: Important security vulnerabilities in OpenVPN

#60

Post by alltakendamned »

tinco wrote: post #53
alltakendamned wrote: post #22

Earlier quoted context omitted.

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.

Over the past years Apache httpd has had 187 vulnerabilities, 24 of which had potential remote code execution consequences. I'm not saying anyone is ever going to find another RCE in Apache. I'll even go as far as to say it's not very likely. But I don't think develop a server and then put it in the world's most hostile environments for 20 years until we're certain it's safe is a particularily efficient development s…

OK, you're not wrong here, but let's qualify your answer a little bit for the people that are less "into this" and to introduce some intellectual honesty in the discussion.

Apache has had 187 known vulnerabilities _since 1999_. The full list can be found at http://www.cvedetails.com/product/66/Apache-Http-Server.html...

Of the 24 remote code execution bugs you mention, only 4 of them were found in the last 8 years. The one before dates from 2007. Of those 4, only 1 of them was considered critical, and even that one is Windows only. The others don't even breach a CVSS score of 7.

So yeah, I stand by my comment that they have a pretty good track records over the past years.

And as to stop building stuff in C, I agree that if you start a new project today that depends heavily on network facing code, parsing of untrusted input and does not have massive speed requirements, there are other language choices one could make. But rebuilding Apache in a memory safe language? Oh well, the beauty of open source is that anyone can take a stab at it.

Post reply on HN