This recent mini op-ed by Matt Blaze in the New York Times is a real missed opportunity:

How can we make software better? There’s no simple answer, but we can understand the situation as a continual arms race in which software is “patched” whenever new vulnerabilities are found, hopefully before attackers are able to discover and exploit them to do damage. We fail at least as often as we succeed, but systems get a little more secure with each iteration. Unfortunately, we make only Sisyphean progress, with new features and applications bringing in new vulnerabilities as quickly as we can repair the old ones.

As a computer scientist, I’d love to find a better way, but the problem of software bugs is as old as software itself. For the foreseeable future, staying one step ahead in this arms race is the best we can hope for.

This is wrong.

As anyone reading this blog knows, I strongly disagree with the notion that “patch-and-pray” is the state of the art. There is no complete answer to making software better, but there is a simple answer: we can eliminate a large and pernicious class of software bugs by simply using memory safe programming languages in place of C/C++.

Infosec is failing by not communicating

A month ago in Philadelphia, an Amtrak train derailed shortly after leaving 30th Street Station, killing seven people and injuring over two hundred.

The crash is being investigated by the National Transportation Safety Board, whose mission is “to determine the probable cause of transportation accidents and incidents and to formulate safety recommendations to improve transportation safety.”

The NTSB has investigated over 140,000 accidents and made over 14,000 safety recommendations. For example, after investigating an aircraft fire in 1983, the NTSB recommended that smoke detectors be installed in aircraft lavatories, and this is now standard practice in the industry.

This sounds hardly worth mentioning. There’s a fire on a plane; the fire started in the bathroom; there are no smoke detectors in the bathroom; NTSB recommends adding smoke detectors to bathrooms; the industry complies. Obvious, isn’t it?

But that’s not what we do in computer security.

We have lots of computer security “accidents” that lead to catastrophic failures (remote code execution).

We investigate those failures and find that they start with a buffer overflow, a “type confusion,” a use-after-free, or some other memory corruption in C/C++ code.

And then? The best recommendation we can make is patch-and-pray?

The deficiencies of this compared to the NTSB approach are legion, but start with this: the NTSB recommendation is effective.

Patch-and-pray is not effective, it is a band-aid, as Blaze himself complains. And yet when given an opportunity to communicate an effective recommendation in the New York Times, he comes up empty.

Worse, there are practically no prominent voices in the infosec community who are routinely promoting safe languages. I’ve never seen Bruce Schneier recommend them, and I’ve been reading his blog for 20 years. Google’s Project Zero doesn’t mention them. Gary McGraw gives keynotes on software security but doesn’t mention them, and started an organization devoted to making recommendations for building secure software that doesn’t mention them. (Sorry if I’ve insulted anyone—if you are a prominent security professional who is not promoting safe languages, let me know and I’ll add your name here.)

I hadn’t meant my blog to become the place to find rants against C/C++, but since the people who can get space in the New York Times aren’t taking up the challenge, here we are: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15.

Recommendation: Don’t use C/C++, use safe languages

Yes, using safe languages won’t solve all security problems, but it very effectively eliminates a bunch of the worst. This is a recommendation that works. And I, for one, look forward to finding out more about the remaining vulnerabilities—I’m sure there are many that we barely know about because they are lost in the noise of the memory corruption bugs in C/C++ that plague us.

Are safe languages feasible?

Is the idea of replacing C/C++ with safe languages just the fantasy of a crazy blogger?

No, not at all. In fact I believe this will inevitably happen, regardless of what the security community does. If you look at any measure of language popularity, you’ll see that most code is now being written in safe languages. C and C++ are holding on in some application areas but it is only recently that safe “systems” languages like Rust have become viable alternatives.

Look at it this way: yes, it would take an enormous amount of effort to fix memory corruption bugs by writing everything in safe languages, but this is much easier and more effective than any other “fix” we have for any other class of security problems. It’s the single easiest and most effective improvement that we can make, and it is achievable.

Programmers know how to program, and safe languages are easier to program in than C/C++. Furthermore, programmers love to program. They like to program so much that they can’t resist reimplementing programs from scratch. This tendency is so strong that programmers have to be forcibly restrained from doing it!

As you read these words, people are programming text editors, device drivers, kernels, compression algorithms, and every kind of program in safe languages, even though we already have working alternatives.

So, the ascendance of safe languages is inevitable. However, I’d like to see memory corruption bugs eliminated in my lifetime instead of in fifty years, which is why the leaders of our field need to start recommending safe languages. That would really make a difference.