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.
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.
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!
"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)"
The first line here starts with a ridiculous comment about why the review is so short. Thanks for telling me you're lazy. Then, the review jumps to the middle of some paragraph that apparently only partially made it on the page. Why do they do what? Could someone please explain to me what "This means not keeping things security and calling it secure." means? I could go on to the rest of the paragraphs which are two line summaries rather than any analysis of quality, but the point is made.
We are a technical audience, and could have had a much more in-depth review without the nuances being lost on us. Even more so, PLEASE get an editor to at least LOOK at the reviews. Now I have to go elsewhere to find a review so that I can figure out whether or not this book is worth buying. The author's positive review sounds like it came right out of:
http://www.quartertothree.com/features/editorials/ lackey/game_reviews_gone_bad.shtml
You will probably come back with some retort about chaos theory and the formation of patterns, so let me tell you what's wrong with that idea right now: Chaos theory does say that in many cases, "random" data will form identifiable patterns. However, often those patterns are not distinct over a small sample. Even given a few million numbers from a sophisticated random number generator, you would be hard-pressed to come up with a pattern in them - even using incredible amounts of computing power. This is why the NSA was so scared of things like PGP a few years back (and still are!). In short, the world is definately not "un-random", especially in very small domains -- such as those microprocessors operate in.
That's it. I'm no longer part of Team Sanity.