Breaking code in the name of good

We talk to Gary McGraw, author of “Exploiting Software: How to break code”, about where users should be spending their security dollars, the difference between open-source and closed source software security, application layer security as the Holy Grail and more

It may seem odd to release a book called “Exploiting Software: How to break code” at a security conference.  But co-authors Gary McGraw and Greg Hoglund did just that at the RSA Conference in San Francisco in February and weren’t thrown out on their ears.  That’s because their real intent is to help people build better code by showing them how attackers work.  Network World Editor in Chief John Dix caught up with McGraw to learn more about the book, which was three-and-a-half years in the making, and follows McGraw’s other books, “Building Secure Software” and “Securing Java.”

Inside you say, “This is a dangerous book, but the world is a dangerous place.  Knowing more serves to protect you.”  Do you think IT professionals will agree with you?

Gary McGrawFor the most part security professionals do.  I was expecting more controversy, but at RSA everyone was saying “Wow, it's about time we had a book like this.”  And no one said, “Ooh, way to dangerous.”  So I think almost every security professional will agree we have to get more serious about what we’re up against.  And the only way to know how to build software right is to know how your creation is going to be attacked.  That’s one part of the justification. The other part is, there aren’t any brand-new techniques in the book that are going to cause havoc.  The bad guys already know this stuff.  Some of the attacks we talk about are truly as old as the hills.  And if we begin to have a clearer, more scientifically grounded discourse about this stuff, maybe we’ll make some progress in this space. We surely need it.

In the book you say, “Software defects are the single most critical weakness in computer systems” and “Bad software is ubiquitous.”  Are all network defenses, then, merely chewing gum stuck in the cracks of a sinking ship?

The fact is network security mechanisms are necessary but not sufficient.  We keep trying to protect our broken stuff from exploit by building a perimeter defense around it.  The notion of defending the edges of a system is not bad, it just doesn't work all the time.  Especially when it comes to complex software that is Internet based, highly distributed, and designed to be extensible - meaning it is based on the Java Virtual Machine or the .Net Common Language Runtime. 

So we have our work cut out for us.  The issue is, as software gets more important and gets more complicated, the chances of us solving our problem with edge-level network mechanisms is zero. We have to do some other stuff. We have to make software more secure from the get-go.

One of the biggest problems in software security is, people will build the whole system and then say, now that it’s done let’s make it secure. So they try to sprinkle magic crypto fairy dust on it, or close off the ports so no one can get to it from outside the firewall. Those two approaches aren’t working. 

In Chapter 1 of your book you talk about software’s trinity of trouble - complexity, extensibility and connectivity - and point out that vulnerabilities are related to the number of lines of code. So if Linux has 55 million lines of code and XP has 40 million, is this to say there is no way to ensure the security of these and other large systems?

No. It's just that these systems are really big, and unfortunately when they were built no one was really thinking about security. So we have some work to do going back to fix these things up. The guys at Microsoft have spent a lot of effort trying to get a handle on the security problem, with some success.  They have a long way to go but it's not like they’ve been doing nothing over there. Unfortunately for them they remain the butt of all security jokes, but I guess they have a big target painted on their tummy.

In the book you carefully describe why it is easy to tear into anything and everything, leaving me with a feeling of despair. Is there hope?

The antidote was published in “Building Secure Software,” so now that you’re despairing you should go back and reread that. I think the good news is that, if you look at the evolution of the software security space, people understand the problem now and are beginning to work on it. We want to make sure they don’t just stick lipstick on the pig, but instead try to breed better pigs. We don’t have to give up hope and throw our hands up. Our hope is that some of the discussion in this book will relegate many of these problems to the dust bin of history. 

You have two pages of snippets from hackers about the general state of affairs, one of which reads: “Hardware attached to the Internet (with few expectations) can be remotely exploited right now - including 3Com switches, the Cisco router and its IOS software, the Check Point firewall and the F5 load balancer.” Are they true?

Nobody really knows. The claims made by hackers are certainly bellicose, at best. The issue to think about is, what if these things are true, or even partly true? If you look at myths and Internet rumor, occasionally there is a grain of truth underneath. For example, the notion that there is a Fortune 500 list showing how to get into various huge corporations. I know people that claim to have seen it. It's not surprising when you think about the fact that most of those corporations have tens of thousands of machines, maybe even hundreds of thousands, and they have to protect them all in order to avoid being compromised.

My co-author on this book, Greg Hoglund, dabbled on the other side. He doesn’t any more, but he brings a kind of hacker mentality to the book. So our book is kind of hackerdom meets science - I’m the science guy - and we’re just trying to understand this problem and jolt people into reality.

People are so excited about the attack of the day they forget to step back and talk about how these things unfold over time and how big the problem is and whether or not there is such a thing as attack patterns. And there are, as it turns out, but identifying them takes a lot of work. The thing is if you start talking about attack patterns instead of the problem of the day, you start building better solutions because you can build a solution for the pattern and not just for the particular bug. 

You talk a lot about attack patterns in Chapter 2. Is this aimed at people building software or users of software?

It is aimed at a lot of different audiences.  The primary audience is people that are building software, people that need to understand software security, and people that have to protect a network full of software. 

What do you make of the Microsoft’s behavior blocking approach to security that was discussed at the RSA show?  (A technique for protecting applications and operating systems from worms and other attacks by recognizing when systems aren’t acting like themselves.)

I think that’s not a bad thing to do. It is kind of a reactive approach, and there’s nothing wrong with it. But there is no alternative to actually building things that are not broken. Of course, everyone always talks about defense in-depth when it comes to security - you should try to build a perimeter around it, you should watch it behave, watch it get attacked and try to build it to defend itself. And all those things will help, but no one of those things will solve the problem. There is no silver bullet for software security.

It has been said that it would take too long and cost too much to build Windows and other large systems to be secure. How do you balance the economic trade-offs?

There is a trade-off there, but I think it’s clear that the economics are on the side of security now. That is precisely why Microsoft has spent over $500 million trying to do a better job with software security, because they know the market is demanding code that is better. The market is no longer putting up with junk. That’s great for software professionals everywhere because a lot of people that build code, including people that work at Microsoft, have been saying for years we have to do a better job, but the economics was on the wrong side. It was on the side of more features, get it out fast, get mind share and fix it later. Those days, I think, are coming to an end as software takes on more and more prominent roles in everyday life.

Is there a difference between securing open source vs. close source software?

That’s a total red herring. There has been a lot of ink spilled over it, but software is software, and the fact that someone published the source code for everyone to look at doesn’t make it any more secure, and doesn’t mean we shouldn’t spend time worrying about the security of it. Economically speaking, the close source guys have a better handle on the problem because they can pay people to do the very, very hard work of software security and security testing. 

You hear more and more about application security being the Holy Grail. Is it?

This is a pet peeve of mine. Here’s the deal. You have to be concerned about all kinds of software, and the good news about the application security movement is that, at least those guys realize we have a software problem and we need to solve it. The problem is that, by and large, most of the vendors that are approaching the applications security space are doing it with their network security hat on. And frankly, they don’t understand software. They see it as a broken thing that must be protected by sticking an application firewall in front of it or probing it with various black box tests to see if it is truly broken. It is a very outside approach to software. 

Where should users be putting their security dollars? Obviously they’re already spending on the perimeter …

And they should continue to do that. The thing they need to do is educate the people building their software.  Most big banks, for example, are huge software houses, with thousands of developers - those developers need to understand the software security problem, and you will get the most impact by training those guys, giving them proper tools, working on integrating software security best practices into the entire software life cycle so you start thinking about security when you conceive of a system, instead of thinking of it when you already have a system. If we start paying more attention to the building side of the house, we’re going to have a lot easier job on the operations side of the house down the road.

How about software that you buy. Can you hold vendors to a higher standard?

You sure can. You can impose things - especially on outsourcers - like service-level agreements. Big corporations are beginning to push back on the independent software vendors and say, “Hey, we expect this stuff to be better than the crap you’ve been sending us all along.” 

But coming back to big systems with lots of code - you point out in the book that programs average 5 to 50 bugs per thousand lines of code, so can you really expect to be able to buy secure products?

I don’t think there is a notion of security that is completely attainable. Secure is a relative term. One guy’s “secure enough” is another guy’s “Oh my God.” You have to figure out what it is you’re trying to accomplish and what you need for your own business to be considered secure enough. I think corporations are taking a look at their risk exposure with regards to software and determining that it is unexpectedly high and they stand to lose a lot in terms of reputation, liability, productivity and just plain bottom and top line, if the software they are producing doesn’t work. 

Think about a car.  If a car fails because of a software problem, people are not going to blame the software vendor, they are going to blame whoever has their name on the car, Honda or Ford or whomever. That’s becoming a more common phenomena. As software gets embedded in everything, we get major brands that have more software risk exposure than they used to and those guys are trying to get a handle on that. The good news is you can in fact do something about it, even if you didn’t write the code. Your vendors will listen to you.

I have faith that we can solve the problem. It’s not going to be “just add water, instantaneous solution,” or like some kind of product is going to come out next year that will solve the problem. But I do believe we are making progress. We’ve made more progress in the last three years than we had in the last three decades.  And that’s a good thing.

If you were a hacker, how good would you be? 

I’m not a hacker. But I think anyone that is a hardcore software person could be a pretty darn good hacker.  The thing it takes is identifying and understanding assumptions people make, and then making those assumptions go away. I’ve been building software things since I was 12. You sort of get this intuitive feel for how to build stuff and add functionality, and it turns out you make an awful lot of assumptions about how things work. The truth about attacking a system is you go in and make those assumptions go away and watch what happens.  Usually what happens is the whole system comes crumpling down.  I have a bumper sticker on my car that says, “Assume Nothing.” 

When we go to customers and find a security problem and go to show them, the first reaction of engineers and architects is, “Well, you can’t do that,” like there’s some sort of rule [laughs loudly].  And we say, “But we’re the bad guys, of course we can do that. That’s the whole point. These people are criminals that are attacking your systems.” In order to do a good job with security you have to be able to find out, and probe into, what you can’t do.

Learn more about this topic

Security research center

The latest news, alerts, reviews and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2004 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)