Government Technology

    Digital Communities
    Industry Members

  • Click sponsor logos for whitepapers, case studies, and best practices.
  • McAfee

Have Hackers Won?




Photo of Steven Bellovin by Eileen Barroso of Columbia Engineering

September 12, 2012 By

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.


| More

Comments

Add Your Comment

You are solely responsible for the content of your comments. We reserve the right to remove comments that are considered profane, vulgar, obscene, factually inaccurate, off-topic, or considered a personal attack.

In Our Library

White Papers | Exclusives Reports | Webinar Archives | Best Practices and Case Studies
Digital Cities & Counties Survey: Best Practices Quick Reference Guide
This Best Practices Quick Reference Guide is a compilation of examples from the 2013 Digital Cities and Counties Surveys showcasing the innovative ways local governments are using technological tools to respond to the needs of their communities. It is our hope that by calling attention to just a few examples from cities and counties of all sizes, we will encourage further collaboration and spark additional creativity in local government service delivery.
Wireless Reporting Takes Pain (& Wait) out of Voting
In Michigan and Minnesota counties, wireless voting via the AT&T network has brought speed, efficiency and accuracy to elections - another illustration of how mobility and machine-to-machine (M2M) technology help governments to bring superior services and communication to constituents.
Why Would a City Proclaim Their Data “Open by Default?”
The City of Palo Alto, California, a 2013 Center for Digital Government Digital City Survey winner, has officially proclaimed “open” to be the default setting for all city data. Are they courageous or crazy?
View All