How to cyber security: Faceplanting in 10 lines of code

Sometimes it’s hard to convince people that security needs to be part of every software development process. “We passed all our tests,” they might tell you. “Isn’t that good enough?” 

The problem is that functional testing usually focuses on the happy path—a place where users act rationally, systems behave well, and nobody is attacking your application. The job of the testing team is often defined too narrowly as ensuring that the software has the required functionality. 

The real world is a messy and chaotic place. As soon as your software is deployed, it will encounter a wide range of unexpected and badly formed input coming from systems and humans that are accident-prone, like Mr. Magoo—or actively malicious, like Lex Luthor. 

To make this absolutely clear, let’s take a look at an extremely simple piece of software. It passes functional tests but is alarmingly easy to break. 

Requirements and design

Somebody in your company has a great idea for a software product. “Give it your name,” gushes your product manager, “and it says ‘hello’ back to you. Everybody’s gonna love this thing!” They decide to call it faceplant.

The product has a single functional requirement: 

• Given an input string x, the product will produce the output “Hello, x.” 

Without any security review of the design, the requirements are done and get handed off to the development team. 

Implementation

In the absence of any consideration for security, the development team has latitude to choose programming languages, frameworks, and open source software components to meet the functional requirements. 

For whatever reason, your developers use C to implement this software. Here’s what they write:

#include <stdio.h> 
#include <string.h> 
 
int main(int argc, char** argv) { 
  char message[32]; 
  strcpy(message, "Hello "); 
  strcat(message, argv[1]); 
  strcat(message, ".\n"); 
  printf(message); 
  return 0; 
}

The developers build the software and do a little local testing to make sure it works: 

$ ./faceplant Fleur 
Hello Fleur. 
$ ./faceplant Viktor 
Hello Viktor. 
$ 

Everything looks good, so they tell the testing group that it’s ready for testing. 

Testing

The test group designs tests to make sure the functional requirements are met. They might do these manually, or they could automate them. Regardless, they work up a series of test cases that will ensure the software works as intended. 

They might start with the same test cases the developers used, and then expand them. 

If they’re really going the extra mile, they might throw in some test cases to support non-English-speaking customers even though there’s no functional requirements for this.

$ ./faceplant Sørina 
Hello Sørina. 
$ ./faceplant Étienne 
Hello Étienne. 
$ 

The software passes all the tests and gets handed off to the deployment and release team. 

Wait … what?

The product team is just about finished with champagne toasts when things start falling apart. 

Bug reports start flooding in. When faceplant is deployed as a network service, servers start suffering from denial-of-service attacks and possibly being compromised. 

What happened? All the tests passed, which means the software is perfect, right? Right? 
Nope. 

Meanwhile, in a secret hacker lair

The fundamental problem here was trusting user input. Both the developers and the testers focused on functionality, assuming that the software would be handed input that makes sense. 

An attacker looking to exploit faceplant would utterly disregard any explicit or implied rules about input. The first thing a hacker might try is supplying no input at all: 

$ ./faceplant 
Segmentation fault (core dumped) 
$ 

Woops, that produced a segmentation fault. Next, an attacker might try supplying some long input: 

$ ./faceplant 1234567890123456789012345678901234567890 
Hello 1234567890123456789012345678901234567890. 
Segmentation fault (core dumped) 
$ 

That gave another segmentation fault. This one seems promising for the attacker—maybe it could lead to a remote code execution exploit. 

The attacker might also try supplying format strings: 

$ ./faceplant "%p %p %p %p" 
Hello 0x7ffd1acd62ec 0x11 0xffffffffffffffed 0x7ff5d8d41d80. 
$ 

Now the attacker is able to see the contents of memory, which could be useful in crafting an exploit or could reveal sensitive data, just like the Heartbleed vulnerability.

Yes, it’s a toy

Of course, faceplant is not a real piece of software. But it highlights how easy it is to have implementation bugs in even a trivial implementation. 

Admittedly, our development team did a truly awful job with this one. But that’s not really the point. Developers will make mistakes—they’re human, after all—so the process that surrounds them must help drive down risk in the software they’re creating. 

If this happened in 10 lines of code, what about an application with 10k lines of code? 100k? 1m? 

Make sure it doesn’t fail

Functional testing is important. You use it to make sure that the software works when used as intended. 

But it’s equally important to make sure that the software doesn't fail when weird stuff happens. If somebody runs the software without specifying a name, it shouldn’t produce a segmentation fault. Instead, it shouldn’t respond at all, or respond with a polite error message, or write information to a log file somewhere. If somebody calls the software with a very long name, the software should handle it properly. 

Battle-hardened developers know these things and write more-robust, more-secure code. Battle-hardened test teams know these things as well, and make test cases that supply unexpected or unusual inputs to software to see what happens. 

Use SCA to manage third-party components

Nearly all applications use third-party, often open source, components as building blocks. Keeping track of those components, their known vulnerabilities, and their licenses is a crucial part of building software. It even extends to the maintenance phase, when teams must respond appropriately to newly discovered vulnerabilities in components they previously used. 

Our faceplant example is small enough that it doesn’t use any third-party components, but many applications have hundreds or thousands of components. 

Automation helps here, too. Synopsys Black Duck® scans source code to find third-party components and provides comprehensive reports on the vulnerabilities and licenses associated with those components, as well as workflows, reports, and much more.