Buggy code and cyber security: a conversation with Steven Bellovin.
In 2009, Columbia Computer Science Professor Steven Bellovin said, "the odds on anyone ... finding a magic solution to the computer security problems are exactly zero. Most of the problems we have are due to buggy code, and there's no single cause or solution to that. In fact, I seriously doubt if there is any true solution; buggy code is the oldest unsolved problem in computer science, and I expect it to remain that way."
Bellovin, who became the Federal Trade Commission’s chief technologist this month, has a long history of IT experience, including more than two decades at AT&T Labs Research in Florham Park, N.J. “I do research on networks, security and why the two don't get along,” he explains in his bio.
Will there ever be a complete solution to computer security? Government Technology asked Bellovin that question and others. He was careful to point out that these opinions were his own and not necessarily those of the FTC.
GT: Three years ago you said buggy code is the oldest unsolved problem in computer science, and that you expected it to remain that way. Is that still your viewpoint three years later? It seems that as our infrastructure becomes "smarter" we will become a much bigger target for the bad guys, with potentially much more dangerous consequences. One failed traffic light at a busy intersection, for example, can snarl vehicles for miles.
Bellovin: Yes, I still think that. Exactly what to do is still a research area; while I have some ideas, they’re not even to the half-baked stage yet. I think we need to build systems with different architectures, ones that are designed under the realization that there will be security failures. Authentication won’t do it — in most breaches, the bad guys go around the strong authentication, not through it.
My own working philosophy is that programs will have security bugs — then what? But that’s a research agenda, not guidance I can give to a programmer, let alone an end site. You cite the failed traffic light, and you’re absolutely right — what is the fallback position when a component fails?
GT: Why is buggy code such an intractable problem?
Bellovin: Fundamentally the issue is the intellectual difficulty of managing the complexity of programs. Take, for example, the Thunderbird mail program. When I checked a few years ago, it was about 6 million lines of code. (That’s a very rough estimate; I’m confident about the “millions” part, but much less confident that it’s 6 million as opposed to 3 million or 12 million.)
Suppose I want to write some code concerning how the number of attachments is displayed in the summary line. That section of code will have to interact with the vastly complex code that looks at the entire message and parses it to see exactly where each attachment starts and ends. (That code itself is of mind-boggling complexity, because the specifications are so complex.) Do I understand the other code correctly? Will I do something wrong because I don’t understand it? How many attachments can there be? Suppose I look at the code today and realize that it can’t handle more than 99 attachments, so I allow for a two-digit field to display. Sometime later, someone else comes along and — not knowing what I did — changes the code to allow for 9,999 attachments. My code can’t handle it, so there’s now a bug. Is it exploitable by a hacker? Possibly, possibly not — but that’s how these things can start.
A better design would have been for the attachment-handling code to have some way to tell another part of the program what the limit is, but that would have implied a great deal of foresight. Sometimes programmers have enough, sometimes they don’t – or they might have [in the past], but requirements change over the years.
Beyond that, there is sometimes carelessness. I’ll dredge up a story from about 35 years ago, when I was in grad school and teaching introductory programming. For complicated but understandable reasons, one student put a semicolon into an operating system command. (This was an IBM mainframe, back in the punch-card days.)
Semicolons were necessary in the program but forbidden in the command language. However, the person who programmed that part of the command language wasn’t expecting a semicolon, so when this command showed up — that is, every time they tried to run this student’s deck of punch cards — it crashed the entire mainframe. The student wasn’t very popular, but the fault was really the programmer’s – he should have written his code better, to avoid crashing the system when someone submitted garbage like semicolons.
Programs today are a lot better, but they’re far from perfect. You may have heard the phrase “SQL injection attack” — it’s a problem that occurs when programmers don’t cope with unexpected inputs. (http://xkcd.com/327/ makes the point in a humorous way.)
The problem is that other than “write better code,” there aren’t great ideas on what to do about the complexity problem. (The “I forgot” problem is somewhat more tractable.) Now, “write better code” can be very helpful. Microsoft has spent vast sums of money in the last decade on that, ranging from programmer education, to automated checking tools, to code review teams. It’s helped; it’s helped tremendously, but — as witnessed by [Microsoft’s] rate of critical bug fixes — they’re still far from where they’d like to be. There also are lots of ideas on how developers can write better code, but I’ve been watching panaceas show up since at least the early 1970s. Needless to say, the problem isn’t solved yet.
GT: Does IPv6 offer fewer vulnerabilities?
Bellovin: It offers some minor advantages, but nothing major. Back when we were designing it, we had higher hopes. In fact, circa 1994 the claim was made that it would be more secure. Unfortunately that statement is, as they say, “inoperative” for several reasons. First, what we mean by “more secure” was really “built-in cryptography” — what we now call IPsec, a VPN (virtual private network) protocol.
There are several problems with that. For one thing, we have a better understanding today of the causes of insecurity. Crypto is a great thing, but it’s not going to solve the buggy code problem. (In 1998, as part of a National Academies study, I analyzed every CERT advisory issued up to that point. 85 percent of them described problems that encryption couldn’t fix: code problems, configuration errors, etc.) Second, we assumed that IPv6 would be deployed a lot more quickly than has turned out to be the case. In the interim, every shipping operating system has added IPsec support to its IPv4 code. That negates the advantage that IPv6 was supposed to have.
There are still some benefits: privacy-enhanced addressing is one; the relative immunity of a v6-only net to scanning worms — ones that spread by trying to find all hosts in a given range of IP addresses — is another. These are minor advantages, though, and have to be balanced against ISP and [system administrator] relative inexperience with IPv6 operation and tracing. (By the latter, I mean answering the question “which host did that nasty thing?” when the host is using a privacy-enhanced address and hence isn’t easily identifiable unless you take other precautions.)
GT: So if buggy code and the problems you mentioned will remain, where do we go from here?
Bellovin: Just because there’s no such thing as perfect, it doesn’t mean there isn’t ‘better’ versus ‘worse.’ Good practices can go a long way to help — but don’t assume that they’ve solved the whole problem.