I’m going to take a break from ranting about C/C++ for a minute to explain my purpose.

Like anyone working in any field, I want to improve the world. But many of us think that security hasn’t improved at all over, say, the last twenty years. We still grapple every day with the same problems we saw twenty years ago.

I believe that technology alone is not the solution. We have plenty of technology. I don’t know that we have all the technology that we need, but we have plenty of technology that we don’t need. We keep “solving” the same problems over and over but none of the solutions has emerged as a winner, and most are simply not used.

In order to understand why this is I think you have to understand human behavior, and I don’t mean “figure out why humans are dumb about security.” Security solutions must be designed around human nature. If they go against human nature then they will fail. Humans won’t change and it is pointless to blame them.

For example, after working in security for a couple of decades I can say with assurance that normal people (anyone outside of the security field) do not care about security. “Security” is the thing that stops people from getting their work done. People won’t take action just for security, they need other reasons.

This is why I believe that safe programming languages are going to be the solution to memory corruption vulnerabilities. McCarthy, after all, was not a security researcher; he worked in artificial intelligence. Safe programming languages were not invented to improve security—they were invented to improve programming. And there are many, many ways in which they do improve programming. And, fortunately for those of us who care about security, they also improve security.

Now, we have developed many other technologies to combat memory corruption. We have virtual memory protection, stack canaries, address space layout randomization, control-flow integrity, system call monitoring, and on and on. Many of these technologies use mathematical tools like static analysis, program transformation, model checking, symbolic execution. Often, these same techniques are used in safe languages, and in fact many are directly inspired by safe languages. These are good technologies.

There are two problems with these technologies. The first, and least important, is that they are not as effective as safe languages. They are all about closing the barn door after the horses have left—they try to limit the damage that can occur after memory has been corrupted. Consequently there is always a gap in protection compared to safe languages. All of these protections have been broken over time.

Most important, these techniques are only for improving security—remember that ordinary people don’t want to do things only for security. That’s a tax, a burden. For example, the grsecurity team has worked hard to bring various security tools into Linux, but the response from kernel developers and others upstream has not been encouraging. We cannot expect these tools to succeed because they go against human nature.

We can see what has succeeded historically: safe languages have taken over most programming, because they are not about security at all. Programmers think that they help them to program well. That is why those of us in security ought to promote them before other security technologies.

Dark patterns of human nature

A flip side to the idea of “going along” with human nature is to exploit human nature, as practiced, for example, in the dark art of social engineering, but for good. We should use insights into human psychology and “irrational” behavior to increase security.

This is why I have taken a great deal of time to criticize C/C++ and promote safe languages. Today, suggesting that we can and should replace C/C++ with safe languages is seen as unhinged ranting. That is why it must be said, over and over again. We must shift the Overton window so that the public can realize that it is possible. This isn’t security or mathematics, it is politics and advertising. And it is necessary.