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.
I gave this book to Bill for Christmas. I'm not convinced he read it though.
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.
While open-sourcing your project may help ensure that you're a bit more proactive in securing your applications, it also gives the keys to the castle to anybody that decides to find programming mistakes in your code. Closed-source projects, while simply hiding any potential security holes, really does add an additional layer of protection, albeit a very thin one. But the issue of open-source vs. closed source as it relates to security is an entirely different argument of open-source vs. closed source as it relates to a company's right to keep trade secrets as just that. It's my opinion that if a company writes some code that they don't want shared, then they've got every right to keep it that way.
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.
I'm sure that this book will be most helpful. After all, who better to learn from than the staple of application security?
Do you like German cars?
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
If only the right people would read them
Conversion Rate Optimisation French / English consultant
Cigital is a company who is majority controlled by MS. 'Gary', if that is his true name, has a PHD from the University of San Carlos. T
he PHD, which was purchased for less than 200 US Dollars, is in Business CS, and his first job was at MS where he worked for five years as a contractor to Cigital before being brought on full time to their staff (about the same time MS bought majority share in the stock)
Thus, the poster who you claim was FUDing was actually right. Do your research!
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!
Was 'Gary' the one who came up with the '80s marketing campaign "Cigital has it now"?
-- Nobody should take away Microsoft's freedom to innovate, particularly since they haven't used it yet
This author of this article should have posted this review under the Worst Acronyms headline from a few days ago.
Why would MS want to produce secure and stable software? It would not be wise for them financially to release an OS or any other product that has the security and stability of BSD or linux. If Win95 didn't BSOD every other minute, then it would still be the standard. Instead we get PokemonXP which has about 10 GB of integrated crap that no one wants.
--Mike--
...please finish your high school English class.
I'm taking an Intro to C++ course, and the assignment is to roll two dice, add the results, and keep track of the frequency of each result from 2-12. Easy right?
I've got a function called roll() that returns (rand()%6)+1, and then in main I have a loop that does "results[roll()+roll()]++" 36000 times.
Pretty straight forward program, and works as expected compiling under Metrowerks on Windows and gcc on a Linux box, but under cygnus (egcs 2.91.57) all of the results are odd. In other words, only 3,5,7,9,11 have any results, the evens are completely skipped.
Added in some cout's to see what was happening, and the roll()'s were alternating, without fail, between even and odd results - all numbers 1-6 were present, but they marched lockstep even-odd.
Presuming there was a problem in cygnus' implementation somewhere, the instructor proceeded to try it on a BSD box (with a later gcc - 2.95, I believe) with exactly the same result.
Searching on google proved fruitless (I was crushed!) - anyone know where I could get more info on this?
Outside of a dog, a book is man's best friend. Inside a dog it's too dark to read. - Groucho Marx
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'm talking, of course, about the only languages that actually SUPPORT buffer overflows - C, C++, and Assembly. Not exactly the sorts of languages that are considered seriously in software engineering these days."
They may not be considered, but they're sure used a lot more than other languages these days.
"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
I design and sell 3rd party applications to cheat MMORPGS :) And I design but not develop server code for like 10 years. Once someone cheats, then everyone cheats just to comepete. Its like taxes too.
Whats funny is that I designed Gnutella without knowing about it. I was designing an unhackable version of Diablo 1. Where characters are stored client side... The key was there was a psuedo server made up of the thousands of other people playing who also kept your data... It was a P2p network as base then everyone stored extra data... If you looked like you were cheating by a large % of computer police, then you're no longer in the network... This may sound shady and up for corruption, but online communities do flag people as shady to begin with... Its not really succeptable for conspiracy either because if you want to take your ball and go home, you can do it with your friends too.
God spoke to me
There are many punctuation and spelling problems with this article. Far too many to call out in detail. Perhaps my favorite error however, is the author's use of the word "peaked" instead of "piqued". You should say, "...your curiosity is piqued," not "...your curiosity is peaked." Of course, an automated spell checker would never catch this error; one would have to actually know the difference to begin with.
Gary McGraw is a card carrying member of the IRA! He was their ace in the hole during the early 90's, inserting software backdoors into server apps so the IRA could shut down the Internet and corporatations as a massive political gesture.
Sounds like a goofy question, I know.
I understand the majority of security breaks are perpetrated by people who are already authorized to use the software in question, but do so in a way not consistent with their job description, as if the only security was the job description.
Insiders, in other words.
I went looking for security books a while ago and found lots of books on how to secure your web server and keep your machine from getting rooted and how to encrypt data sent over the wire. Now I see a book with a chapter on buffer overruns.
How hard can it be to write a book on keeping the various legitimate users of the system from snooping around the parts of the system they aren't supposed to go to? Doesn't anybody remember the scandal at the dept of Health & Human Services (I think that's the right dept.) in which users of the system were essentially surfing people's social security data for entertainment? I don't believe that had anything to do with buffer overruns or rooting servers or any of that hacker shit.
The problem of malicious insiders is one that the software can only deal with up to a point. You need to have good physical security and good network security (e.g., strong passwords, etc.) I think it'd be good to see a book on defending against malicious insiders, but you can bet it will focus more on aspects other than the software security.
Hofstadter? The "G*del, Escher, Bach" Hofstadter?
A monkey is doing the real work for me.
21% off at bookpool
BSS
My blog: http://jkratz.dyndns.org/~jason/blog/
I'm new, I'm just about to start programming. But I'm not stupid and I've done some research.
.NET is not immune to security flaws so that platform is not the future, maybe just an intermediate step.
The future of programming is programming for Virtual Machines. There are several reasons for this but one of the reasons is security. The number 1 in the list of security risks every year is "buffer overflows". It seems it's very hard to program in such a way that programs don't have buffer overflows.
Instead of twisting and turning into all kinds of strategies to prevent buffer overflows you can instead completely bypass the issue by programming in Java. Java doesn't have "buffer overflows" at all! Scratch that from the list of security flaws for free.
If you have a problem with the control that Sun has over Java (which is sometimes a good thing) you can use this platform instead: http://www.squeak.org/
Although I'm not sure if Squeak is immune to "buffer overflows" or not, Someone please give a noob like me some help and tell me if this is the case? thanks.
I know from articles that
The disadvantages of Virtual Machines that I've read about are that they're a bit slower than languages like C or C++. Well I've done some more reading and it seems that problem is almost history. Seems that C++ is only between 2x and 1.5x faster than Java now. Taking into account that PCs will reach 10GHz within a couple of years, I'm convinced that Java like languages are the future.
The only exceptions are things like TCP/IP routing and server stuff like that where every percent of performance is vital.
I know it's difficult to just throw away all that experience in C++ that you have now but if you can find the heart, switch. And if you're new to programming, like me, then there's only 1 sensible choice for the desktop. A Java-like language!
P.S. please don't forget to tell me whether Squeak is immune to buffer overflows or not, thanks.
I downloaded bss_examples-1.0.tar.gz from the web site, but a lot of the files seem strangely corrupted, e.g. spaces before > where there shouldn't be. Makes HTML look funny and Perl not work.
Try Security Engineering by Ross Anderson, which looks at security at a somewhat higher level.. :) )
I just read it and it's great (atm, i'm reading BSS
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.
The *RIGHT* way of solving a buffer overflow problem would be to have a return address stored on a SEPARATE stack, different from the stack where the parameters and such are stored for the function being called.
Recall that the way this usually works, is overwriting a return address through the non-bound-checked data with some function address that will execute a shell or something of the sort. If it's not on the data stack - you CAN'T overwrite it.
This will require changes both in compilers and in the instruction set, true. But it will make things inherently more secure. The worst one will be able to do with buffer overflow is corrupting data, but no NEW functionality will be executed.
I find bugs in server software, so I picked this book up as a reference.. Its reminded me of some areas of testing that I hadn't paid much attention to before. Its well-written, modern (at the moment), and provides a good overview of software security issues and how to avoid them. I would definitely recommend it to coders, testers/QA, and maybe even administrators who want to understand software security issues. This book should be required reading for anyone who develops server software products..
Security is like ... a stream of bat's piss. It shines out like a shaft 'o gold, when all around is darkness.
Judging from this short review, it just sounds like another in-depth Ode to the various inherent flaws of C. Is that all?
/. thats what it really seems to boil down to -- and its really beginning to annoy me to hear about some big "security community", and all these "security issues", security this and that, blah blah blah which all boils down to a design problem with C which has been beaten to death by now and is not very interesting.
Hopefully not, but from other reviews/stories I've seen here on
If that isn't the case, I would have really appreciated a more thorough review (beyond "I liked it").