Hacker News Reader

Comment by prodigal_erik | Hacker News Reader

I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished, and by now yet another attempt shows such poor judgment that funding ought not be provided. Certainly Linux has had remote root exploits, and so many local exploits that its multi-user model is no longer taken very seriously, and the other kernels have fared no better.

View on HN

> I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished

https://sel4.systems

Possibly one of the most trustworthy pieces of software there is.

Man, I'd forgotten about that project. I wonder how much of the code could have been written differently and how much was effectively dictated by the theorem prover. Those are probably the very first people in the industry who deserve to be called engineers.

The sneaky thing they did is write seL4 in Literate Haskell, and then translate it to C. That involves some serious understanding of both languages!

http://ssrg.nicta.com.au/projects/seL4/tech.pml

So what did they do? Write the code in C and then proved it with Isabelle/HOL? Extracted C code from Isabelle/HOL?

d.j.b software (qmail, nacl, dnscurve, others). It is rare, but it has been done.

Oh the irony. Those that you mention are also safe until proven otherwise.

I remember before Heartbleed was discovered everyone was raving about how secure OpenSSL is because it has been around for so long yadda yadda ... Heartbleed was discovered and everyone's suddenly acting "haha I knew it all along .. it was shit".

Everything is safe only until proven otherwise. Java will save you from (say) buffer overflows, but not SQL injections or permission errors (the most probable successful attack against Apache servers had always been writable executable directories, even though it is written in C and had its share of buffer overflows)

And if your circle thought OpenSSL was tight, you are hanging in the wrong circles for security. Heart less was exceptionally bad, but OpenSSL for a long time had a couple of security fixes a month on Ubuntu and Debian - that's enough to tell you that you need to follow advisories closely and not trust blindly. And yes, I have been saying that for at least 5 years, before heartbleed was introduced.

Even djb software has your usual C-type security issues, though in less frequency than normal. qmail had an integer overflow that was theoretically exploitable, but couldn't be practically exploited in a normal configuration (djb admitted that was "pure luck"). And djbdns had an integer overflow that was exploitable (though in fairly unusual circumstances): http://article.gmane.org/gmane.network.djbdns/13864

Conversely, the well-audited OpenBSD kernel has had next to none of these problems precisely because they pay attention to correctness, even with the "fatigued and rusty scrap iron" that is the C language.

I'm sure that OpenBSD is much more secure in general than Linux. I love it and use it as my own firewall.

But even OpenBSD has had its share of local root exploits. They've even had 2 remote root exploits, and so few only because most services are disabled by default.

True. However, they also as a group have done some pretty significant research into problems declared solved in order to make systems more secure. For example, the change a few years back to make malloc based on mmap instead of more traditional heap pools, so that if there is an overflow, the program's much more likely to segfault than to go gleefully trampling over data, etc.

Additionally, it's worth keeping in mind that the reason for the OpenBSD team forking OpenSSL wasn't Heartbleed, but rather the OpenSSL team's rather terribly coded malloc replacement that did things in there. All of the security research and practices the OpenBSD team typically insists upon couldn't do anything because OpenSSL insisted on running in its own leaky memory box.

> I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished

Kinda proves my point.

Reply on news.ycombinator.com