:: extra ::

Seems like we security people don’t get to celebrate a victory nearly as often as we get to learn from defeat, so please take a moment to enjoy some good news. I’ll try to prolong the moment by saying this: I spend a lot of time telling programmers that they are no longer in a position where they can pretend that security isn’t part of their jobs, but my message is contravened by most of the training material programmers see. Whether it’s documentation a new framework, library, or platform, the standard play is to pretend that security doesn’t exist. No mention of what you need to do in order to make your code secure. No mention that security is anything other than a user name and a password. I’m happy to say that Apple is bucking this trend.

Apple opened up the iPhone for third party applications last week. That means they’re providing programmers a software development kit and instructions on how to write code for the iPhone. On the home page for iPhone development, they have a list of common coding questions such as “How do I debug my application?” and “How can my application detect motion?” At the bottom of the list is “How do I write secure code?” The answer links to a secure coding guide that discusses topics like validating input and avoiding buffer overflow as well a discussion of the security services the iPhone’s OS provides. Nice.

(In order to browse the links above, you have to register as an iPhone developer. It’s free. Go here.)

By Brian Chess on Mar 14, 2008 | Permalink

Ed Felton and the gang at Princeton have struck again! This time they've figured out how to defeat the disk encryption schemes built into Vista, MacOS X, and others. The attack works because the values held in RAM don't disappear instantly when a computer is switched off. They decay slowly over a period of seconds, and that can be extended to minutes with a little bit of coaxing. That's long enough to boot up a second OS and read out the contents of memory. After that, it's just a matter of extracting the crypto keys, and the game is over. Awesome work. Read about Cold Boot attacks on Encryption Keys.

If there's a lesson to be re-discovered here, I think it's the amazing way we end up building security systems on what seem to be solid ground (as in "computers forget stuff when you turn them off"), and only when it's too late do we find out that our premise was strong enough for trying to explain computers to someone like your old uncle Hugo, but not strong enough to adequately secure your data.

It appears to me that this attack is still too sophisticated for the average thief who steals laptops in coffee shops, but it's plenty easy for the forensics guy down at the police station.

By Brian Chess on Feb 21, 2008 | Permalink

Some inspired soul has reworked the New Face of Cybercrime trailer. Watch this. My favorite bit: the cat and the baby.

By Brian Chess on Feb 19, 2008 | Permalink

It's been a while since Brian or I posted anything about Secure Programming with Static Analysis, and Gary McGraw's mention of the book in his recent article on Dark Reading seems like as good an excuse as any. Gary concludes his post, The Truth Behind Code Analysis, with the following:

"If you’re interested in static analysis for security (and you should be), buy and read Secure Programming with Static Analysis by Brian Chess and Jacob West."

The book was also recently reviewed in a recent blog post by the folks over at the Denim Group.

And the following are just a few of the other relevant mentions it has received:

- SDTimes
- Dr. Dobb's Journal
- Sylvan von Stuppe
- Justice League (Cigital)
- SANS
- Deep Inside | Security & Tools

I've also been (pleasantly) surprised by how much interest we've gotten in the warez scene. I won't post those links, however.

By Jacob West on Feb 16, 2008 | Permalink

We don't get that many cartoons about code review, so when a new one crops up, it's cause for celebration. If you don't think it's hilarious, you need to do more code review. Many thanks to Mark Curphy.

By Brian Chess on Feb 06, 2008 | Permalink

NIST has announced what they call a Static Analysis Tools Exposition (SATE). Participating static analysis tools will be used to analyze a small set of programs selected by NIST. Eventually all of the results will be made public. I like the idea a lot, and I'm going to make sure Fortify takes part in both the C and Java tracks.

Running a bunch of programs against the same test cases might seem like a straightforward exercise, but it's not. Finding an even-handed way to examine complicated tools is tough, and the fact that NIST is emphasizing the detection of security vulnerabilities makes it that much tougher. (Tell me again, what exactly constitutes a "vulnerability" in source code?) Just browse through the steps in the SATE protocol to get a feel for the complexity involved.

To make the exercise even more difficult, everyone who makes a tool can't help but worry that they'll come out looking bad. After all, this sounds a little bit like the setup for a product review. We've seen those before. (Here's a link to the one Network Computing did in the middle of 2007: link.) Product reviews generally have winners and losers. NIST says they'll work hard to avoid these kinds of labels, but it's not going to be easy. All of this makes test case selection a touchy subject, and comparative presentation of the results is an absolute minefield.

The problems are many, but there's also a lot to be gained. Here are the three reasons I'm looking past all of the complexity and anxiety and participating in SATE:
1) People who want to run their own tool comparisons will benefit. You might like the way SATE works or you might not, but you'll be able to see what they did and where it took them.
2) Tool builders will benefit. Static analysis for security is a hot topic in both industry and academia. The results will give us a little bit of insight into which problems we've conquered and which ones require more work.
3) The security community will benefit. Being able to compare output from different tools will give us a better idea about how the tools classify code, and my guess is that we'll learn that our nomenclature still needs improvement. Better nomenclature makes it easier to talk to the 99% of humanity that doesn't think about software security every day.

By Brian Chess on Feb 04, 2008 | Permalink

It appears that a buffer overflow vulnerability in The Legend of Zelda for the Wii, and that’s all hackers need in order to run their own code on the machine. Here’s the scoop.

Pretty soon this will mean game pirating for the Wii without the need to get out your soldering iron. That’s important if you want to get people to steal games in the same casual manner they steal music. Piracy is a big deal for all modern gaming platforms because most of the money comes from software (games) not from hardware.

Apple has run into similar trouble recently. It seems that more than a million iPhones have been unlocked, and I think it’s safe to assume that it’s mostly happening using the simplest mechanism out there, a web site that exploits a buffer overflow in the iPhone. That means Apple is missing out on their cut of the phone subscription going to AT&T, and that has to hurt.
The moral to this story is this: if your business relies on the security of your software, you’ve got two choices:

• Design a system that will be secure even when people discover a few bugs.
• Make sure you don’t have even a single bug.

By Brian Chess on Jan 29, 2008 | Permalink

For as long as there have been breathalyzer machines, DUI suspects have been looking for creative ways to beat them (see newspaper clipping below.) The latest trend is to go after the source code. Here are three recent cases:

• August 2007: Minnesota Supreme Court rules that source code must be revealed.
• December 2007: Source code analysis in New Jersey class-action breathalyzer case.
• January 2008: Kentucky appeals court rules that source code must be revealed.

My favorite anecdote so far comes from the New Jersey analysis. One of the teams used Fortify to analyze the code, and lo-and-behold, they found a buffer overflow vulnerability! This raises the possibility that if you mix just the right cocktail at just the right time, you could craft an exploit. (Dream on.)

The real lesson here is that our legal system is waking up to the importance of code. If the code isn’t trustworthy, the outcome isn’t trustworthy either. (Electronic voting machine vendors, you might want to read that last line again.) If the code provides evidence that the programmers weren't being careful, that's going to be bad news for the vendor.

By Brian Chess on Jan 28, 2008 | Permalink

“What do you do when expertise is not enough?”
Atul Gawande

Hundreds of little decisions per day. Screw up any one of them, and disaster could ensue. Smart and highly trained professionals who know what to do, but who aren’t always focused on the details. A transition from a cowboy mentality to an emphasis on a boring but safe and repeatable process.

Sound like the hymn of software security? It does indeed, but it’s also the way Atul Gawande describes modern intensive care units in his article The Checklist. Intensive care units appear to suffer from many of the same problems the software community faces. Too much complexity creates too many opportunities for error. Little mistakes lead to complications, and those complications can, quite literally, kill.

As with software, there is no easy or complete answer to the problems doctors face in the ICU, but the surprising finding this article points out is that a simple tool, the checklist, is enormously effective. Arm nurses with a five step checklist for avoiding an infection when inserting a line, and secondary infection rates plummet.

Do programmers in your organization have the equivalent for common security-sensitive operations? Maybe those cross-site scripting errors keep popping up because there’s no template to guide programmers as they create new code. If you’re still casting around for one or two more new year’s resolutions, resolve to give programmers good examples they can follow. In the book, we try to give a positive, correct, and secure code listing for every broken, bad, or vulnerable piece of code we discuss.

By Brian Chess on Jan 25, 2008 | Permalink

Software security can be hard to talk about, sometimes because people who make software are an incredibly diverse bunch. I’m not talking about globalization, I’m referring to the fact that the term “software” covers a lot of ground. Building operating systems, web sites, cell phones, and airplanes all require major software chops, and they all require an understanding of security, but they are very different undertakings.

If you’re talking to someone about the new software security initiative you just got off the ground, the result can be wild confusion before you figure out that the other person’s take on what a “software security initiative” means is completely different than your own. I like McGraw’s latest DarkReading column because it gives a nice overview of the different ways people get started.

By Brian Chess on Jan 14, 2008 | Permalink