Title: Professionalism in Programming #28

Not so long ago computer access was a scarce commodity. The world contained only a handful of machines, owned by a few organisations, accessed by small teams of highly trained personnel. In those days computer security meant wearing the right labcoat and pass card to get past the guard on the door.

Fast forward to today. We carry more computational power in a pocket than those operators ever dreamt of. Computers are plentiful and, more pertinently, highly connected.

The volume of information carried by computer systems is growing at a fantastic rate. We write programs to store, manipulate, interpret, and transfer this data. Our software must guard against data going astray: into the hands of malicious attackers, past the eyes of accidental observers, or even disappearing into the ether. This is critical; a leak of top-secret company information could spell financial ruin. You don't want sensitive personal information (your bank account or credit card details, for example) leaking out for anyone to use. Most software systems require some level of security^[1].

Whose responsibility is it to build secure software? Here's the bad news: it's our headache. If we don't consider the security of our handiwork carefully, we will inevitably write insecure, leaky programs and reap the rewards.

Software security is a really big deal, but generally we're very bad at it. Nearly every day you'll hear of a new security vulnerability in a popular product, or see the results of viruses compromising system integrity.

This is an enormous topic, far larger than we have scope to go into here. It's a highly specialised field, requiring much training and experience. However, even the basics are still not adequately addressed by modern software engineering teaching. The aim of this series is to highlight security issues and explore the problem. We'll learn a number of basic techniques for protecting our code.

Building secure software requires a mindset that is sadly lacking in the average programmer. In the day-to-day madness of the software factory we're too focused on getting the program working, on getting it out of the door on time and in a reasonable state. We sit back and breathe a sigh of relief when our streamlined application appears to be doing what its supposed to. Rarely do we turn our attention to how secure the code is. Unless the test department is particularly skilled in this area, it's easy to ignore the whole issue - we'd rather not think the worst of a new creation.

If you do eventually turn your gaze to security issues, perhaps with a little test department prodding, it's probably too late anyway. Once a system is built, patching up any security problems is a hard job; the problems are either too fundamental, too prevalent, or far too hard to identify.

It's probably hard to believe that anyone would take the time and effort to hack your applications. But these people exist. They're talented, motivated, and they are very, very patient. Why do they do it? Some malicious crackers intend to steal, commit fraud, or cause damage, but their motive can equally be to prove superior skills or to cause a little mischief. They might not want to compromise your application specifically, but won't hesitate to exploit its flaws if you leave a hole open.

Sadly, no application is totally hack-proof. Writing a secure program is no easy task. Yet even the most secure application must run in its operating environment: under a particular OS, on some specific piece of hardware, on a network, and with a certain set of users. An attacker is just as likely to compromise one of these as your actual code. Indeed they're probably more likely to; social engineering - the art of acquiring important information from people, items in an office, or even the outgoing trash - is usually a lot easier (and often quicker) than worming a way into your computer system.

Software security presents a myriad of problems and challenges for the poor overworked programmer.

Why would anyone bother to attack your system? It's usually because you've got something that they want. This could be:

They might even attack you for the sheer fun of it, or because they dislike you and want to cause harm by disrupting your computer resources. Of course, we must remember that whilst malicious people are lurking around looking for easy, insecure prey, a security vulnerability might equally be caused by a program that accidentally releases information to the wrong audience. Sometimes this won't matter. More often it's just embarrassing. In the worst case, though, that lucky user can opportunistically exploit the leak and cause you harm.

To understand the kinds of attack you might suffer, it's important to mark the difference between protecting an entire computer system (comprising of several computers, a network, and a number of collaborating applications) and writing a single secure program. Both are important aspects of computer security; they blur together since both are necessary. The latter is a subset of the former. It takes just one insecure program to render an entire computer system (or network) insecure, so we must take the utmost care at all times.

Let's take a look at the ways you can be caught with your pants down. These are some of the most common security risks and compromises of a live, running computer system:

The problem scales as the number of routes into a system grows. It gets worse with: the more input methods (web access, command line, or GUI interfaces), the more individual inputs (different windows, prompts, web forms, or XML feeds), and the more users (there is more chance of someone discovering a password). With more outputs there is more chance for bugs to manifest in the display code, leaking out the wrong information

How do you know when your program has been compromised? Without detection measures you'll have no idea - and will just have to keep an eye out for unusual system behaviour or different patterns of activity. This is hardly scientific. A hacked system can remain a secret indefinitely. Even if the victim (or their software vendor) does spot an attack, they probably don't want to release detailed information about it to invite more intruders. What company would publicise that their product has security issues that are effectively wide-open doors? If they are conscientious enough to release a security patch not everyone will upgrade, leaving a well-documented security flaw in many operational systems.

To defend yourself adequately it's important to know whom you're fighting against. As they say: know your enemies. We must understand exactly what they're doing, how they do it, the tools they're using, and their objectives. Only then can we formulate a strategy to cope.

Your attacker might be a common crook, a talented cracker, a 'script kiddie'^[2], a dishonest employee cheating the company, or a disgruntled ex-employee seeking revenge for unfair dismissal.

Thanks to pervasive networking they could be anywhere, in any continent, using any type of computer. When working over the internet attackers are very hard to locate; many are skilled at covering their tracks. Often they crack easy machines to use as a cover in more audacious attacks.

They could attack at any time, day or night. Across continents one person's day is another's night. You need to run secure programs around the clock, not just in business hours.

There is a cracker subculture where knowledge is passed on and easy-to-use cracker tools are distributed. Not knowing about this doesn't make you innocent and pure, just naive and open to the simplest of attack.

With such a large bunch of potential attackers, the motives for an attack are diverse. It might be malicious (a political activist wants to ruin your company, or a thief wants to access your bank account), or it might be for fun (a college prankster wants to post a comical banner on your website). It might be inquisitive (a hacker just wants to see what your network infrastructure looks like, or practice their cracking skills), or might be opportunist (a user stumbles over data they shouldn't see, and works out how to use it to their advantage).

How do attackers manage to break into code so often? They're armed with weapons we don't have or (due to lack of education) know nothing about. Tools, knowledge, skills: these all work in their favour. However, they have one key advantage that makes all the difference: time. In the heat of the software factory, programmers are pressed to deliver as much code as humanly possible (probably a little bit more), and to do so on time: or else. This code has to meet all requirements (for functionality, usability, reliability, etc) leaving precious little time to focus on other 'peripheral' concerns, like security. Attackers don't share this burden, have plenty of time to learn the intricacies of your system, and have learnt to attack from many different angles.

The game is stacked heavily in their favour. As software developers we must defend all possible points of the system; an attacker can pick the weakest point and focus there. We can only defend against the known exploits; an attacker can take their time to find any number of unknown vulnerabilities. We must be constantly on the lookout for attacks; the attacker can strike at will. We have to write good, clean software that works nicely with the rest of the world; an attacker can play as dirty as they like.

What does this tell us? Simply that we must do better. We must be better informed, better armed, more aware of our enemies, and more conscious of the way we write code. We must design in security from the outset and put it into our development processes and schedules.

We'll conclude this topic by investigating some specific code vulnerabilities, and working out good techniques to defend our code from attack.