A Perspective on Code and Components – assert(), don’t assume()

René Pfeiffer/ July 21, 2016/ Development, Discussion, High Entropy

Have you ever looked closely at the tools you use on a daily basis? Taking things apart and putting them back together is an integral part of understanding the universe. Scientists do it all of the time (well, at least some do, there are things that can’t be put together easily once taken apart). So lets focus on components and how they interact.

ASN.1 and libraries that deal with it are popular components. Few people get a kick out of ASN.1, so they use code that does it. It’s just an example for parts that handle data being sent to and received from other systems. We live in a networked world, so communication is a crucial part of modern software. So to use business lingo: Most software works by delegating tasks to third-party code. It helps to focus on the problem the software needs to solve. While this is no epiphany it’s something worth remembering. Usually you rely on these components to do their job. What happens if a particular tasks fails? The manual says that you will get a proper return code or error condition in order to take adequate steps. This works in theory and in well-designed projects where all the rules of secure coding are observed. The guidelines for dealing with failure works somewhat less for code being produced under pressure. Products that need to hit the market in a short time frame are prone to bugs. BIOS/(U)EFI, Wi-Fi drivers (where standards are ready after they are already implemented), apps on mobile devices, your new shiny OS release prior to an important exhibition or press conference, Internet of Things stuff, everything beginning with smart, and probably the occasional prototype from start-ups serve well to illustrate this point.

Information security people know this, or at least they should. Penetration testers and software quality testers know a lot about components, as do sysadmins (this is why they still and will always hate printers). So if you are in charge of a development team, please make sure you eliminate as much assumptions as you can. Networks will fail, servers will be unreachable, data integrity will be compromised, system resources will be tight, and so on. There is an endless list of issues to think about. I’d like to illustrate the point with two links to material that takes a really close look at database software of all kinds. Take a look at Jepsen. It is a project designed to stress test the claims of distributed databases, queues, consensus systems, and similar tools. In addition there are notes from Kyle Kingsbury titled An introduction to distributed systems. Make sure everyone on your teams gets this memo and reads it! No exceptions!

If you are wondering how much effort proper coding (you may also call is secure coding, but it is really the same thing) is, here’s a quote from the Jepsen web site: „Would you like to see a system analyzed? … A full analysis and writeup typically take a couple months.“

There you go. Now fix stuff. See you later!