justin February 3rd, 2007
This is just a short post to let you know we haven’t forgotten the blog. Things have been pretty busy for the three of us and we haven’t had an opportunity to finish off any new content. The fact is that we still haven’t figured out that whole trick of referencing other people’s content while adding pithy summaries and unique insight.
Since there’s nothing new to show you at the moment I’ll try to bribe you instead. Informit has our book on sale for $32.99 right now, which is about $20 less than everywhere else. It’s almost like I’m giving you $20 out of my own pocket. Failing that, perhaps you’ll be distracted by our death bunnies.
Continue Reading »
blog January 18th, 2007
Robert C. Seacord of CERT was kind enough to provide us with the following proposal for addressing integral vulnerabilities in future versions of the C standard. It’s an intriguing approach that we hope generates some good discussion. So, without further adieu…
Ranged Integers and Saturation Semantics
By Robert C. Seacord
In 2005, I wrote that "Integers represent a growing and underestimated source of vulnerabilities in C and C++ programs" as the lead sentence in the "Integer Security" chapter of Secure Coding in C and C++. This prediction has been borne out in a recent study published by MITRE on the types of errors that lead to publicly reported vulnerabilities. "Integer overflows, barely in the top 10 overall in the past few years, are in the top 3 for OS vendor advisories."
Fortunately, some individual members of the ISO/IEC WG14 international standardization working group for the programming language C are starting to mull over some options for addressing integer issues. One idea is to adopt ranged integer types; a second idea is to implement saturation semantics for at least signed integer types.
Continue Reading »
justin January 14th, 2007
We’ve added Chapter 2 - Design Review and Chapter 3 - Operational Review to The Vault, putting the tally at chapters 1, 2, 3, 5, 6, 9, 14, 15, and 17. We’re now at the halfway mark as we continue to work through the remaining chapters. You can expect an update post whenever we add new chapters or make a significant change to existing chapters. One particularly interesting thing in this round of updates is a link to The Protection of Information on Computer Systems, a 1975 paper by Jerome H. Saltzer and Michael D. Schroeder. It’s really fascinating to think that the field of software security had already seen such major development as much as 30 years ago—a bit humbling too.
The reviews are still coming in too. Tom Duff posted a very positive review on his blog and at Amazon. We’ve also started to receive some useful critical feedback through other channels. We’re always happy to get intelligent criticism so we have an opportunity to improve the book with supplementary content here or, hopefully, through a second edition.
jm January 7th, 2007
You should check out the CERT Secure Coding Standards. We’ve started contributing to them recently, as we think they are interesting and quite well done. The standards are a community effort and a work in progress, so feel free to help out. The best way to start is by leaving comments on the appropriate pages with your ideas and/or criticisms.
One aspect of the system that I think is particularly good is the separation between rules and recommendations. Rules are things that you definitely don’t want to do in your code, as you’re very likely shooting yourself in the foot. Recommendations are more best practice coding standards or idioms that will buttress your code base against attack or help inform program design. So, for example, there is a rule that says "MEM31-C. Free dynamically allocated memory exactly once." Double frees are obviously something categorically bad, and should never occur in production code. An example of a recommendation is "MEM00-A. Allocate and free memory in the same module, at the same level of abstraction." This is absolutely sound advice. However, it’s a recommendation and not a rule because there are situations in real-world code where you might have solid reasons for violating this design. I think it’s this subtlety of analysis that will make the standard actually useful in real-world development efforts.
It looks like it will be a useful resource for its intended purpose as a baseline for secure coding standards. (i.e. if you need to put together secure coding guidelines for your organization, it should be a great starting point.) That said, it’s also useful for code auditing, as the rules encapsulate a lot of ideas about what can go wrong in code. It’s approaching the problem from a slightly different angle, but in general, for every rule, there are one or more implied insecure practices that you can audit against.
A quick plug: Robert C. Seacord is one of the chief contributors to the effort, and we might be able to coerce him to do a guest post later on. If you haven’t bought his book, "Secure Coding in C/C++," we highly recommend it.
blog January 6th, 2007
Stephen Northcutt (of SANS fame) was kind enough to let us ramble at length on a few topics. The interview is a departure from our usual technical focus, as it’s mostly a discussion of our views on how an SDLC and supporting processes affect software security. The subject was a nice change of pace, and let us present our approach to software security to a different audience. You can read it here: http://www.sans.edu/resources/leadershiplab/interview.php
blog December 24th, 2006
We’ve added some new content to the Vault: Chapter 17 - Web Applications, Chapter 9 - UNIX 1: Privileges and Files, and Chapter 1 - Software Vulnerability Fundamentals. We’ve also updated the Suggestions page based on some initial reader feedback, and there are a few new Errata entries. We’ve also got some original content we’re working on for a few new blog posts that should show up in the next two weeks.
Initial reviews have started coming in, and so far they’re pretty positive. Stephen Northcutt posted a review in the SANS Technology Institute Leadership Laboratory, which made our moms proud. Emmett Dulaney, of UnixReview.com, also posted a positive review. Dave Aitel liked our book, and Halvar lent his support. Chris Rohlf gave us a positive review on his EM_386 blog, and the OpenBSD guys added us to their Books page. There are also several reviews on the Amazon page for the book, including write-ups from J. Ferguson, W. Boudville, Robert C. Seacord (author of the excellent Secure Coding in C and C++), Dave Maynor, and Marisa Mack. Marisa’s is hilarious, with choice quotes such as:
[…] You might notice that many of the reviews posted here are exceedingly informative and written by very well-respected security industry leaders. This is not one of those reviews. But I’ve found this book extremely valuable, and I’m an order of magnitude hotter than those other guys. […]
jm December 20th, 2006
We’ve added a new section to the site: The Vault. The goal is to have a web page for each chapter that collects all of the links and external references, and contains a mirror of the vulnerable source trees behind the real-world examples. We’ll also add further discussion and pointers to resources that you should find useful. It takes a bit of time to write these up, so you can probably expect them to be populated over the next two months or so. Currently, we have pages for Chapter 5 - Memory Corruption, Chapter 6 - C Language Issues, Chapter 14 - Network Protocols, and Chapter 15 - Firewalls. Enjoy!
jm December 15th, 2006
Check out this presentation by Ilja van Sprundel: Unusual Bugs.
Also, check out Ilja’s blog.
mark December 9th, 2006
Hi There!
Well, the blog is officially underway so I thought I should make an introductory post since John and Justin have already made several. I am Mark Dowd, one of the co-authors of "The Art of Software Security Assessment." We decided to make this web page for supporting material that readers of the book (and other interested parties) might find useful. Here we will post errata, along with code auditing challenges and little tips that we come across in our travels. New stuff that we put on here will likely go into a second edition. Feel free to send us any questions/comments/suggestions for how we could improve this page or stuff you would like to see in the book that we didn’t cover the first time around. Enjoy!
jm December 3rd, 2006
You might have noticed that Michal Zalewski was one of the most referenced researchers in our book, since he’s basically published something cool with just about every technology we cover. Unfortunately, you also might have noticed that we refer to him throughout the book as Michael Zalewski. Crap. We’re sorry Michal.
In recompense, we’ll now refer to all badass “Michaels” in security as “Michal.” Our apologies in advance to Michal Howard.
