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.
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.
Actually, that's the thesis of the first couple chapters of the book. We discuss how to incorporate security into the design process from the beginning.
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.
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
You have obviously never used a dis-assembler, or a debugger. Once you use either for a while you quickly notice the patterns in the code (without dwelling on the specifics) and find areas of interest very quickly.
People do not realize how easy it is to make changes to a program, or gleam its purpose/implementation from views of such code fragments.
The average copy protected game is hacked to undo the copy rotection in less than 2 days. Even if it is a new copy protection method.
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 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.