Title: Professionalism in Programming #29

This is the most fundamental flaw, and consequently the hardest to fix. If you don't consider security at the architectural level then you will be committing security sins everywhere: sending unencrypted data over public networks, storing it on easily accessible media, and running software services that have known security flaws.

You could write a simple system, and rely on your host environment for security, but then your application will only be as secure as that system. For example, a Java program can be no more secure than the JVM it's running on.

Absolutely every system component must be considered for security concerns. A computer system is only as safe as its least secure part.

Many applications are public-facing, running an open network port or handling input from a web browser or GUI interface. All of this input must be parsed and acted on. If you're not careful, these are prime sites for security failure.

Parsing is often done using the standard C library function sscanf (although this exploit is far from a C-only problem). You might see code like this:

void parse_user_input(const char *input) {
  /* first parse the input string */
  int  my_number;
  char my_string[100];
  sscanf(input, "%d %s", &number, my_string);
  ... now use it ...
}

The problem is simple (and obvious). A badly formed input string could cause mayhem. Any string over 100 characters long will overrun the my_string buffer, and smear arbitrary data across invalid memory addresses.

The results of this can vary in severity. Sometimes the program will carry on unaffected; you've been very, very lucky. Sometimes the program continues, but its behaviour is subtly altered - this can be hard to spot and confusing to debug. Sometimes the program will crash as a consequence, perhaps taking other critical system components down with it. But the worst case is when the spilt data gets written somewhere in the CPU's execution path. This isn't actually hard to do, and allows an attacker to execute arbitrary code on your machine, potentially even gaining complete access to it.

Overrun is easiest to exploit when the buffer is located on the execution stack, as in the example above. Here it's possible to direct CPU behaviour by overwriting the stack-stored return address of a function call. However, buffer overrun exploits can abuse heap-based buffers too.

This breed of attack can be used to crash systems, execute arbitrary code, or fish for unauthorised data. Like buffer overrun it relies on a failure to parse input, but rather than burst buffer boundaries these attacks exploit what the program subsequently does with the unfiltered input.

In C programs format string attacks are a common example of the problem. A great culprit is the printf function (and its variants), being used as follows:

void parse_user_input(const char *input) {
  printf(input);
}

The input string is used as printf's format string parameter, and a malicious user could provide an input string containing format tokens (like %s and %x for example). This can be used to print data from the stack or even from locations in memory, depending on the exact form of the printf call. An attacker can also write arbitrary data to memory locations using a similar ploy (exploiting the %n format token).

Solutions to this problem aren't hard to find. Simply writing printf("%s", input) instead of printf(input) will avoid the problem, by ensuring that input is not interpreted as a format string.

There are many other contexts where an embedded query can be inserted maliciously into program input. SQL database query statements can be surreptitiously fed into database applications to force them to perform arbitrary database lookups for an attacker.

Another variant is commonly exhibited by lax web-based applications. Consider an online bulletin board system providing forums where users post messages to be read by any other web browser. If an attacker posts a comment containing hidden Javascript code, this will be executed by all browsers rendering the page - without their users realising. This is known as a cross site scripting exploit, due to the way the attack works 'across' the system; from an attacker's input, through the web application, finally manifesting on a victim's browser.

It is possible to exploit systems which rely on the subtle ordering of input events, to provoke unintended behaviour or crash the code. This is generally exhibited in systems with complex threading models, or which comprise of many collaborating processes.

A threaded program might share its memory pool between two worker threads. Without adequate guarding, one thread might read information in the buffer that the writer thread did not intend to release yet.

This problem isn't restricted to threaded applications, though. Consider the following fragment of Unix C code. It intends to dump some output to a file, and then change file permissions on it.

fd = open("filename"); 
/* point A */
write(fd, some_data, some_data_size); 
close(fd); 
chmod("filename", 0777);

There is a race here that at attacker can exploit. By removing the file at point A and replacing it with a link to their own file the attacker gains a specially privileged file. This can be used to further exploit the system.

Careless use of mathematical constructs can cause a program to cede control in unusual ways. Integer overflow will occur when a variable type is too small to represent the result of an arithmetic operation. An unsigned 8 bit data type renders this C calculation erroneous:

uint8_t a = 254 + 2;

The contents of a will be 0, not the 256 you'd expect; 8 bits can only count up to 255. An attacker can supply very large numeric input values to provoke overflow and generate unintended program results. It's not hard to see this causing significant problems; the following C code contains a heap overrun waiting to happen thanks to integer overflow:

void parse_user_input(const char* input) {
  uint8_t length = strlen(input) + 11;
  char *copy = malloc(length);
  if(copy) {
    sprintf(copy, "Input is: %s", input);
    ... do something with copy ...
  }
}

It's true that uint8_t is an unlikely candidate for the string length variable, but the exact same problem manifests itself with larger data types.

This kind of problem is just as likely with subtraction operations (where it's called integer underflow). It's not only generated by such simple operations, and can stem from mixed signed/unsigned assignments, bad type casting, and multiplication or division.

First we'll look at practices that will protect your software once it's been installed. Perhaps this is backwards, but it will highlight what holes remain to be plugged at a lower level. No matter how good your application, if the target system is insecure then your program is unprotected.

As programmers this is the essential place to get our security story straight. You can try to shoehorn it into code at the end of a development cycle, and you'll fail. Security must be a fundamental part of your system's architecture and design.

So what design techniques will improve our software security? The simplest software design is the easiest to secure. So don't run any software at all. Failing that, run your program in a sealed box in an underground bunker in an undisclosed location in the middle of a desert. That way, crackers can't get anywhere near it. Otherwise you'll have to think about how your software will be used, and how to actively prevent anyone from abusing it. Here are the winning strategies:

The least impressive security strategy is known as security through obscurity, yet this is really the most prevalent. It merely hides all software design and implementation behind a wall, so that no one can see how the code works and figure out how to abuse it. 'Obscurity' means that you don't advertise your critical computer systems in the hope that no attacker will find them.

It's a flawed plan. Your system will one day be found, and will one day be attacked.

It's not always a conscious decision, and this technique works very conveniently when you forget to consider security in the system design at all. That is, it's convenient until someone does compromise your system. Then it's a different matter.

With a bullet-proof system design your software is unbreakable, right? Sadly not. We've already seen how security exploits can capitalise on flaws in code to wreak their particular brand of chaos.

Our code is the front line, the most common route an attacker will try to enter through, and the place our battles are fought. Without a good system design even the best code is unprotectable, but under the shadow of a well thought out architecture we must build strong walls of defense with robust code. Correct code is not necessarily secure code.

This is largely a matter of training and education, although it helps to select users who aren't totally inept, if you have that luxury.

Users must be taught safe working practices: to not tell anyone their password, to not install random software on a critical PC, and to use their systems only as prescribed. However, even the most diligent people will make mistakes. We design to minimise the risk of these mistakes, and hope that the consequences aren't ever too severe.