Using an unsafe language is a design flaw
January 17, 2019  

As part of my dumb life, I recently got into an argument about whether using an unsafe programming language like C or C++ in a project is a software security design flaw. Of course, the answer is “hell yes.” In fact, it belongs at the very top of lists such as this one from the IEEE: Avoiding the Top 10 Software Security Design Flaws. Tragically, the IEEE does not get this, resulting in this blog post right here.

As a service to my readers with a short attention span, the TLDR is that choosing an unsafe language is a big dumb mistake, and it occurs before writing actual code, that is to say, in the design phase.

For the rest of you, here is the analogy that this question deserves.

Carpentry

Consider the familiar frame-and-panel door:

Why do doors look like this, with large panels set into thinner vertical and horizontal framing elements? It seems complicated. Why not just get a bunch of tall, flat planks and glue them edge-to-edge into a rectangle?

The reason is that the door is made out of wood, and wood expands and contracts according to the moisture in the air. If you look closely at wood you’ll see it has a grain structure. Think of it as made out of little straws, all lined up in the same direction. When the air is moist, water can enter the straws from their ends, and they get fatter: the wood expands across the grain.

If you make a door in the dry winter out of a solid rectangle of wood, the door will not fit in the door opening in the moist summer season. In the increased humidity, the wood will expand, the door will get wider, and it will jam in the doorway.

The frame-and-panel door is made out of wood but is cleverly designed to avoid this problem. The frame elements are thin enough that they do not suffer from much expansion and contraction. The panels are wide enough to expand significantly, but they are not attached to the frames. Instead they are “floating” in a slot in the frame, which gives them enough room to expand and contract without breaking the frame.

This is a brilliant hack, invented by some genius carpenter long ago; and now we see these doors everywhere. You even see it on doors that aren’t made out of wood at all—because people think that’s what a door should look like.

Most people don’t know why doors are built this way, but every architect should know. An architect who designs a house with solid wood doors is committing malpractice. An architect building with wood, steel, and concrete should know the properties of all of those materials and use them appropriately.

Memory corruption is a fundamental property of code written in unsafe languages

Expansion and contraction is a fundamental property of wood that carpenters and architects must take into account when they design and build wooden structures.

Similarly, memory corruption is a fundamental property of code written by hand in unsafe languages. Programmers and software architects must take this into account when they design and build software.

If you decide to write your project in C/C++ you must have a plan for handling the inevitable memory corruption in advance. Anything else is malpractice.

It’s completely normal for carpenters and architects to build houses out of wood, because they plan for wood movement. They know when it will cause problems and they engineer solutions to work around those problems; solutions like frame-and-panel doors, or engineered woods like plywood and MDF. They also have other materials, like concrete and steel, which they use where warranted.

Similarly, it’s completely legitimate for programmers and software architects to use hand-written C/C++ code in their project, provided they have built in other measures to deal with the inevitable memory corruption. For example, they could isolate that code in a sandbox, or use a compiler that adds in protections such as CFI or ASLR, or they could formally prove that the code is correct.

If you don’t take those protective measures, you can expect to get memory corruption that will lead to things like remote code execution. This is not just my opinion: it is a statistical fact backed up by decades of data.