Slashdot Mirror
Building Secure Software
BSS:HtASPtRW should be available at your favorite book outlet. It is available in hard cover from Addison-Wesley Professional Computing Series (white cover with blue strip). Since it is a security book, the forward is by Bruce Schneier and displayed on the cover. When you open the book, there are three pages of "Advanced Praise" for the book. So, the stage is set and the expectations are high. Will the book live up to the hype? I thought so.
Who should read the book? Anyone who cares about security. There is information for the manager, coder and everyone in between. Throughout the book, there are plenty of examples which I found very useful. John and Gary use code to show th at what they are talking about is not 'just theory'. That is right, there is code that shows the problems. That means samples of bad code, 'secure' code and code to show exploits.
I decided to look at a few chapters and talk about them specifically. Why did I pick these chapters? Because I found them interesting and thought others would too. I can't cover each chapter because I want John and Gary to write more books , so they need to sell a few copies!
Why do they do this? Isn't this giving the bad guys what they need? The bad guys have the information already. There is belief in the security community of full disclosure. This means not keeping things security and calling it secure. "Full disclosure means that hackers publicly disseminate information about your security problem, usually including a program that can be used to exploit it (sometimes even remotely)." (page 81)
Chapter 7 is on buffer overflows. I have read about buffer overflows for years. The chapter starts by explaining what a buffer overflow is and why it is a problem (pointy headed manager stuff). At this point John and Gary talk about how to protect yourself from buffer overflows. They start by listing problems in C and show why it is a problem. A list of functions that are 'bad' are given, but as any list, this isn't comprehensive. While avoiding the list is a good idea, you need to read why the calls are a problem so you can think about any call you use and why there maybe a buffer overflow.
The chapter then turns very technical. The difference between a heap and stack o verflow is discussed. An example is given that takes a C program and shows how to smash the heap and then how to smash the stack. This is pretty technical stuff , but very interesting. Finally an exploit is given. Very informative.
Chapter 9 is on race conditions. Time-of-check, Time-of-use (TOCTOU) is used to demonstrate a race condition. There is discussion on what a race condition is. John and Gary again step through code that is vulnerable and explain why it is vulnerable. Of course they show you how to write the code securely.
Chapter 10 is on randomness and determinism and lives up the the others. I know that random() isn't really random, is a pseudo-random number generator and should not be used when you need a real randomness. John and Gary give a great example to show how an online gambling poker application was open to cheating. Using some math and educated guessing, a GUI was written that would show you everyone's hand and how to win.
The next part of the chapter talks about how to generate randomness via software and hardware solutions. A discussion on entropy and how to determine the amount of entropy from the random source is given. Things get technical (I think), but you can follow the details or skim them. Regardless of how you decide to read this section, you will walk away with a better understanding of the problem.
I hope from the chapters I discuss, your curiosity has been peaked and you pick up a copy. There is other interesting stuff, like the 10 guiding principles for software security.
Web Resources
The web site recently was overhauled. The code from the book is
there as well are web resources. It is worth it to
take a look at
the web site for more information and to get a feel for the
information the book covers.
Contents
Foreword
Preface
Acknowledgments
- Introduction to Software Security
- Managing Software Security Risk
- Selecting Technologies
- On Open Source and Closed Source
- Guiding Principles for Software Security
- Auditing Software
- Buffer Overflows
- Access Control
- Race Conditions
- Randomness and Determination
- Applying Cryptography
- Trust Management and Input Validation
- Password Authentication
- Database Security
- Client-side Security
- Through the Firewall
Appendix A. Cryptography Basics
References
Index
You can purchase Building Secure Software from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
I'll send a copy to Microsoft... let's hope they abide it :D
There should be a byte available on each chip (or memory cell) that samples thermal noise in some way. This, as I see it, is the only way to get uncorrelated noise. The other systems use iterating functions and take advantage of chaos to produce 'unpredictable' but certainly not random sequences. Know the iterating function and the last result to the precision it is stored in the iterating function- know the next number in the sequence.
I'm one of the authors of Building Secure Software. First, thanks for the flattering review. We certainly worked hard on the book for a long time, and believe that we've produced something that's very useful for anybody involved in the development process. That having been said, I would like to let you all know the shortcomings I see, even though they are all fairly minor: 1) The book hasn't really seen any substantial discounts, as far as I know. Being a 400 page hardcover book, it's somewhat expensive to begin with, and I'm sure some people won't buy it just for that reason. We've requested that the next printing be done in soft cover, but I don't think that's going to happen, unfortunately. 2) New books always have tons of little problems with them. Several unfortunate things have been noticed already. Most unfortunately, there were a few outdated or inaccurate statements on MS technologies. All of the problems we've found so far will be fixed in the next printing, which should be pretty soon. However, if you notice a problem, and don't see it on the web site's errata, send us e-mail. 3) The topic area is moving pretty rapidly. We essentially finished the text minus edits in February, 2001. Since then, there have been some new things come up the pike it would have been nice to discuss. Over time, we'll update the book's web site with articles that are interesting supplemental reading. All in all, I hope that people get a lot out of the book, and that it does well enough that we'll have the opportunity to do a second edition at some point to make the book even better.
This type of book will no doubt help people write more secure applications, but security in larger projects still needs to be engineered in, rather than added on at a later date as a "feature".
:)
For example, Freenet starts with the assumption that nodes on the network will sometimes be hostile to the network, and that they will fail without reason. That fundamental assumption makes their network stronger IMHO than it would have been if they started with a blue-sky look at the network and added code to prevent certain types of attacks.
Also, it seems to me that security in applications is probably something won by hard experience. I'm not even sure if it's possible for somebody whose been hacking for just 1 year to build a fundamentally secure application, but trying to learn never hurts.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
This book was a very good read technicly. However, it's dry and we had to strugle to get through it. I just wish Tolkien had written books about crypto and secure software. They would have been more interesting that way. In the end, I recomend Building Secure Software.
My favorite:
http://www.dwheeler.com/secure-programs/
RFC1925
Nice FUD, but untrue. Gary got his PhD under Doug Hofstadter, then went directly to the company that is now Cigital.
-Minus not followed by digit
It goes to show, it is easy to catch the under/overflows (and even that doesn't happen all to often) but writing good software is hard. This book is definitly going to be on my teachers wish list for this year.-several minus signs after each other
-minus preceded by a digit
No, really. Software for both has to be designed from the *start* with certain ideas at hand.
For security? Everyone and everything around you is a hax0r. Games? Everyone and everything around you cheats.
Look at a game like EverQuest. Are their cheaters? Certainly. Are nintey nine percent of the subscribers to EQ affected by them? Nope. The reason being, EQ realizes that to remain 'cheat free', it has to look at every aspect at the game that the design team proposes, and sit their thinking of ways that people might try to take advantage of and cheat with them.
Other games don't do this. The Diablo series, with duping/etc. Phantasy Star Online, with duping/illegal player killing/corruption of characters/etc. Half-Life and its mods, with spiked models/etc.
The result? Games which believe the player is guilty until proven innocent tend to remain, for the most part, cheat free. Those which don't end up ridden with so many cheaters that the game then becomes unplayable.
Security is the same way. If you think, "No one will do that." with your program, you've already lost. Because, in the end, someone will, just to be an ass.
As has been said quite a few times before, security isn't an option. It's not something that can be added as an afterthought. It's a vital part of the design process, and cannot be left out.
Software isn't the United States - remember, it's okay to design with the thought that all your users are malicious.
It's hosted by the Centre For Applied Cryptography Research (CACR) at the University of Waterloo. Anyone in southern Ontario who liked the book might consider attending.
Info:
Building Secure Software: How to Avoid Security Problems the Right Way
Gary McGraw, Cigital
Mar 20 (Wednesday), 2:30 pm, DC 1302
Its a well known fact that security is a process, it should be considered right from the word go, and not just prior to a software release.
I've been writing a network server, recently, for streaming MP3's, so I been thinking a lot about the various issues.
I came up with a list of things that I should be doing, partly after reading bugtrack, and partly due to things I've picked up over the years.
I think its good to see books like this come out - if only to educate the newer/younger programmers who've never though about the issues before. After all many programmers just work on applications which aren't installed setuid, etc, so when they have to work on such a beast, for the first time, they're likely to work the way that they always have.
I believe that all the programmer courses available should have a section on security - largely because too many people learn from code printing in books, or online, which has all the error checking omitted, so the user can focus on the example. Its obvious from reading many peoples code that they never expect a malloc to fail!
--Mike--
Um, in the mid 80's I was in high school in East Tennessee. Had a little company named "M^2 Computing, Inc." with my friend and current compiler god Greg Morrisett (Cornell CS). More detail here . Oh yeah, and I was an apple ][+ kid. gem
I think the parent poster was trying to point out that some vulnerabilities conform to general patterns that can be spotted in a debugger. There is a big difference between looking for a few specific cases in the code and trying to reverse engineer an API.
I wouldn't be surprised if black hat tools exist which can scan disassemblies for probable stack and buffer vulnerabilities. Where this gets tricky is figuring out enough of what that section of code does to craft an exploit. It is still less difficult than full blown reverse engineering. The process would be akin to finding cheats in MAME or looking for Nintendo cheats with a Game Genie. One way I can think of to ease that part of it is to rebuild the disassembled code so that it can be single stepped when executed. Something like Bochs could also be used so that the black hat investigator can monitor the execution environment to any level of granularity desired. Once it's known what functionality the suspect code implements, one can start coding prospective exploits.
Recreating a secret API would be FAR more difficult. An exploit is basically something that adds itself to already running code. One doesn't have to have extremely deep knowledge of what the vulnerable code does. A project like WINE attempts to replicate the functionality of that code in a source maintainable format. It's a whole 'nother kettle of fish altogether.
I saw an older manpage of rand() years ago, where they explicitely stated that the lowest bit would alternate and recommended only to use the high bits.
For a good PRNG check out the Mersenne-Twister
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Quite an abbrevation, doncha think?
Abbreviations are supposed to be shorter than the word... how about BSS (Building Secure Software). One can normally omit the subtitle in an abbrevation
Moderators NB: This is intended as humor. The last bit (about an abbrevation suggestion) was tacked on 'cos it was a thought.
Everything is mainstream now.