Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Friday 6 October 2017

Building On Rock, Not Sand

This quote is telling:

Billions of devices run dnsmasq, and it had been through multiple security audits before now. Simon had done the best job possible, I think. He got beat. No human and no amount of budget would have found these problems before now, and now we face the worldwide costs, yet again, of something ubiquitous now, vulnerable.

Some of this is quite accurate. Human beings can't write safe C code. Bug-finding tools and security audits catch some problems but miss a lot of others. But on the other hand, this message and its followup betray mistaken assumptions. There are languages running on commodity hardware that provide much better security properties than C. In particular, all three remote code execution vulnerabilities would have been prevented by Rust, Go or even Java. Those languages would have also made the other bugs much more unlikely. Contrary to the quote, given a finite "amount of budget", dnsmasq could have been Rewritten In Rust and these problems avoided.

I understand that for legacy code like dnsmasq, even that amount of budget might not be available. My sincere hope is that people will at least stop choosing C for new projects. At this point, doing so is professional negligence.

What about C++? In my circle I seldom see enthusiasm for C, yet there is still great enthusiasm for C++, which inherits C's core security weaknesses. Are the C++ projects of today going to be the vulnerability-ridden legacy codebases of tomorrow? (In some cases, e.g. browsers, they already are...) C++ proponents seem to believe that C++ libraries and analysis tools, including efforts such as C++ Core Guidelines: Lifetimes, plus mitigations such as control-flow integrity, will be "good enough". Personally, I'm pessimistic. C++ is a fantastically complex language and that complexity is growing steadily. Much more effort is going into increasing its complexity than addressing safety issues. It's now nearly two years since the Lifetimes document had any sort of update, and at CppCon 2017 just one of 99 talks focused on improving C++ safety.

Those of us building code to last owe it to the world to build on rock, not sand. C is sand. C++ is better, but it's far from a solid foundation.

Comments

ClassicHasClass
Or, portability. Half the systems here don't have a Rust compiler and probably never will. Rust has a long way to being as portable as C/C++, particularly for those kinda-legacy systems which may still be relevant to new projects. The answer may be, "well, we don't care about those systems that don't have a Rust compiler" (which is a sucky, albeit valid, answer), but that's not strictly a budgetary computation. I have a feeling what you're going to say, though. :)
Robert
> Half the systems here don't have a Rust compiler and probably never will. That's a bit ambiguous. Do you mean half of all architectures? Half of currently installed hardware units? Half of all units being sold right now? Half of all hardware units that will ever be sold? Whatever. Part of being responsible developers and vendors is ensuring our chosen hardware platforms support modern toolchains. There's certainly no technical reason why a platform that runs vanilla C code can't run Rust. (Rust's hardware support is already pretty broad: https://forge.rust-lang.org/platform-support.html)
ClassicHasClass
Sure there's technical reasons. For example, there was that issue with the standard library on Snow Leopard because there was no thread local storage support (not introduced until 10.7). That's not a trivial platform change. And for some architectures, the bring up is still incredibly onerous, especially on a new platform triple where precompiled stage 0 doesn't exist. In fairness this has gotten a bit better but I'd argue this is largely because the platform list has widened thanks to the brave souls who slogged through that work, not because the process is substantially simpler. The reply I'm expecting is "10.6 is not a modern platform." True, it's not, but I can still run C on it and there are people who still care about it. For all its advances, which I'm not arguing, I think personally the generally claimed level of Rust's ubiquity is greatly overstated.
notsgnik
I'll stick mostly to C and here is why: I personaly wanted to build a personal lib in GO then I thougth... what if it's not runing as fast as I wanted and needed to run it without OS or on a special hardware? there is no UEFI go/rust... Or what if i needed it to run on the client side using EMSCRIPEN ? ... still no GO or RUST A last one, what if i think the compiler is doing a poor job optimizing my code? looking at Go generated assembly hurt my eyes... I think i'll stick with C for now, but if i'll make a program that is sure to run only on a recent computer and don't need all the juicy stuff or even is going to run on a TPU, i'll probably use Go :)
Robert
Rust + UEFI: https://www.reddit.com/r/rust/comments/5oupdq/modern_rust_uefi_programming/ Rust + Emscripten: https://hackernoon.com/compiling-rust-to-webassembly-guide-411066a69fde Check your facts.
Jon Nordby
You can compile Rust to WebAssembly (probably also JavaScript) using Emscripten. Since a couple of months back support is in mainline versions of all relevant components. Here is a tutorial: https://medium.com/@ianjsikes/get-started-with-rust-webassembly-and-webpack-58d28e219635 Support for bare-metal in Rust is also actively worked on. Redox OS is a whole operating system, including graphics support and some applications, written in Rust: https://www.redox-os.org Their developer blog has good posts on the low-level technical bits. ARM Cortex M-x microcontrollers are pretty OK supported, see http://blog.japaric.io/quickstart/ AVR microcontroller support in LLVM was recently merged, and it is possible to use Rust there, though not production ready just yet. Don't forget that Rust has good interoperability with C, so you can mix-and-match if it suits your needs.
Anonymous
This is so wrong on many levels. I wouldn't normally reply to such non-sense, but I just want to let others know that they are not alone when they think "this is rubbish". First of all, you don't know what you want to do ("what if that", "what if another"). Do not start projects at all, if you don't know what are they for. This unnecessary generalisation of the project leads to broken design that's hard to maintain for no purpose/benefit. Regarding the speed. IT DOESN'T MATTER. If you app completes in 1us or 2us, it doesn't matter. In most cases, you are going to be I/O bound anyways. What's even more bizzare, that quite often you can find Java programs that are faster than C. C doesn't give you good performance just because you use it. How you use it, matter more. Finally, this premature optimisation is evil and I thought everyone knows it. But hey, if you want to masturbate doing C so you can boast to your pals, while trying to fix obscure memory corruption errors, be my guest.
Anonymous
I was replying to "notsgnik"
notsgnik
@tadas, if i need to disassemble somme functions, it's also because some function ( strncp for example ) are now assembly instructions and because you know what your program is doing so you know what are the assembly equivalent of what you are trying to do. Anyway, now that i think about it, it's seams that you are right and like some java programs that optimize themselves after couple of runs. it would be more likely that a machine learning algorithm compiler would do a better job than me at optimizing and securing code. @robert, i haven't checked for rust you are right, but it's because i dislike mozilla fundation as mutch as apple, the main reason would be a stupid "mere-exposure effect". @all, I belive that good program are writend when you put your heart in it ( don't be stupid i'm talking about hormones ) and your heart is in when you have been exposed a lot to a language so... @robert, if you really want people tu use more rust and go, make it more visible and learn about "mere-effect exposure" ;) for my part, i'll not follow the hype and will be using Go maybe in 10 years ;D
Rob Lang
Interesting stuff. Out of interest, how do you rate C# and .NET from a security/stability/difficulty-to-introduce-holes standpoint?
Robert
Decent --- as good as Java.
Anonymous
Sounds to me like an, i am used to this; It works better because, i am used to this...
notsgnik
"mere-exposure effect" :)