Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Books Media Book Reviews

Building Secure Software 113

Posted by timothy from the circle-the-wagons dept.
greg pryzby writes: "A friend has been pushing me to read a number of technical books lately. After reading Building Secure Software: How to Avoid Security Problems the Right Way (BSS:HtASPtRW), I decided I needed to spread the word." Read on below for Greg's word on this one.
Building Secure Software: How to Avoid Security Problems the Right Way
author John Viega, Gary McGraw
pages 528
publisher Addison-Wesley
rating 8.5
reviewer greg pryzby
ISBN 0201-72152-X
summary Good information for anyone involved with the creation of software which should be secure.

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

  1. Introduction to Software Security
  2. Managing Software Security Risk
  3. Selecting Technologies
  4. On Open Source and Closed Source
  5. Guiding Principles for Software Security
  6. Auditing Software
  7. Buffer Overflows
  8. Access Control
  9. Race Conditions
  10. Randomness and Determination
  11. Applying Cryptography
  12. Trust Management and Input Validation
  13. Password Authentication
  14. Database Security
  15. Client-side Security
  16. 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.
This discussion has been archived. No new comments can be posted.

Building Secure Software More

Building Secure Software

Comments Filter:

  • *runs to post office* (Score:4, Funny)

    by RinkSpringer ( 518787 ) <rink@ri[ ]nu ['nk.' in gap]> on Thursday March 07, 2002 @10:33AM (#3124275) Homepage Journal
    I'll send a copy to Microsoft... let's hope they abide it :D

  • Random Numbers (Score:2, Informative)

    by Joel Ironstone ( 161342 )
    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.

    • Re:Random Numbers (Score:3, Interesting)

      by swagr ( 244747 )
      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.

      This can be very hard to determine. Here [keio.ac.jp] is a random number generator with period 2^19937-1. Presumably it could be modified to support a larger period.
    • The most common random-noise collection method in use is measuring the time between keystrokes. It doesn't require any additional hardware (except a keyboard ;-) and is fairly random.

      PGP/GnuPG use this method, and if I'm not mistaken, so does the Linux kernel (to feed /dev/(u)random).

      • The most common random-noise collection method in use is measuring the time between keystrokes. It doesn't require any additional hardware (except a keyboard ;-) and is fairly random. PGP/GnuPG use this method, and if I'm not mistaken, so does the Linux kernel (to feed /dev/(u)random).

        I have a hard time believing this... You're seriously implying that Linux servers (no keyboard) have an inferior /dev/urandom?

        • > I have a hard time believing this... You're
          > seriously implying that Linux servers (no
          > keyboard) have an inferior /dev/urandom?

          That's true, actually. Check out /usr/src/linux/drivers/char/random.c.

          /dev/urandom uses all sorts of hardware timings (like incoming packets, hard drive seeks, etc.) to produce add entropy to its pool. Typing or moving the mouse improves this, though I think "inferior" might be too strong a word since they are both nearly unpredictable anyway.
    • Interesting idea, but somehow I think it would still be too predictable. Taking the principle even further, they should have multiple sensors that measure thermal noise, sound variations, RF signals, power fluctuations, light levels, and humidity. Then combine all that data with a big old hash function, and you'll probably get as close to "random" data as one could hope for in this distinctly un-random world.

      • Re:Random Numbers (Score:2, Insightful)

        by PurpleFloyd ( 149812 )
        Then combine all that data with a big old hash function, and you'll probably get as close to "random" data as one could hope for in this distinctly un-random world.
        This world is incredibly random. While things may seem predictable on the human scale, that tends to disintegrate as you go smaller and smaller. Things like Brownian motion (the more or less arbitrary "vibrating" motion of heated particles) are very random.

        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.

    • Re:Random Numbers (Score:2, Informative)

      by Fuzion ( 261632 )
      Don't the Intel CPUs have some feature like this? I remember them advertising a while ago that they can generate true random numbers for power dissipation on resistors or something like that. I'm not very familiar with this, and am just recalling something I heard a while ago.

      If all CPUs implemented something similar then can true random numbers be obtained from that?
      • Yes, the 810 (and later) series chip sets include a hardware random number generator, based on thermal noise. They have done quite a few things to make sure that it holds up well as a good source of randomness. Intel has a FAQ [intel.com] on the hardware, and how to use it.

        --Mike--

        • I read the white paper by the designers of this chip; it sounded like these guys really knew what they were doing. We are a Solaris shop, but will probably write a program to generate random numbers using the Intel chip, and read that over a socket. You could also write the random numbers to CD-ROM.
      • The original Pentiums has the ability to do this... it was involked by the FPU, and basically took an integer and returned a float that was offset by approximetly 1E-10, IIRC ;)
    • Perhaps someone could point me to an answer on this very strang problem I've got with rand().

      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?

      • Not surprising. Many implementations of rand() return even, then odd, then even, then odd, etc. That is why you should never do rand()%2 for a random bool. It is better to use something like rand()&32&lt&lt5. Anyway, even+odd=odd, so your problem would fit that pattern. Mod 6 and + 1 won't change that (Mod 6 preserves parity and + 1 just swaps parity between your two rolls). Look in Knuth for some better random number generators that don't have such restrictions. For dice rolling, there is a really convenient one that just XORs two bits in a number and shifts everything to the right replacing the leftmost bit with the XOR result. It's extremely easy to code, but I don't have my copy of Knuth at work right now.
      • you can xor all the bits sequentually and get a repeating string of 1's and 0's 2^15 in period
      • From the manpage under linux:

        The versions of rand() and srand() in the Linux C Library
        use the same random number generator as random() and sran
        dom(), so the lower-order bits should be as random as the
        higher-order bits. However, on older rand() implementa
        tions, the lower-order bits are much less random than the
        higher-order bits.


        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 [keio.ac.jp]

      • The C rand() function has very few requirements imposed on it. Implementations that alternate odd, even, odd, even, ... used to be very common, and there are still some around. This behavior is allowed by the standard. So, for truly random numbers, one should never use (rand() % n). There are warnings to this effect in the Linux man page for rand(3). At least in Debian.

        Use random() and srandom() (instead of rand() and srand()) if you have them available. If not, you have to do a little bit of work. The basic idea is to use the result of rand() to produce a floating point value in the range [0.0, 1.0). Then you can multiply that by the width of the desired range, 6 in this case, to produce a value in the range [0.0, 6.0). Truncate that to an integer, producing one of {0, 1, 2, 3, 4, 5}. Then add the lowest value in the range, 1 in this case, to produce a one of {1, 2, 3, 4, 5, 6}. I don't think this is quite perfect; it seems that the highest value would be slightly less probable due to the limited resolution of floating the point. But I think it works in practice. Some code like this (warning, not thoroughly tested):

        int rand_range(int low, int high)
        {
        return low + (int)((rand() / (RAND_MAX + 1.0)) * (high - low + 1));
        }

        And then, to roll a die, call it like this:

        rand_range(1, 6);

        HTH

      • The problem is almost certainly compiler optimization. When you ask for roll()+roll(), the compiler notices that you are calling the same function with identical arguments twice, so it only generates one call and puts the result in both places. This is why random number functions often take a dummy argument, so that you can do something like rand(dum)+rand(2*dum) to keep the compiler from outsmarting itself. Rewrite your roll() function to take a dummy argument like this and I bet it will start working correctly.
    • I have a friend who implemented some cryptographic stuff
      in his youg days. As a true random numbers generator he
      used white noise from the line imput of a sound card.
      It looks like quite unpredictable.

  • Comments from author (Score:5, Informative)

    by viega ( 564643 ) <viega@@@list...org> on Thursday March 07, 2002 @10:42AM (#3124303) Homepage
    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.
    • The book hasn't really seen any substantial discounts, as far as I know

      Just a heads-up for folk in the UK looking to buy this book - it-minds.com are doing it for £37.99, 10% off of list price. I think you have to go in via theregister.co.uk

      amazon.co.uk have got it for £41.99

    • 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

      It's on for a 15% discount at Readme.Doc [readmedoc.com] right now.
    • 21% off at bookpool

      BSS [bookpool.com]

  • Engineered in (Score:5, Interesting)

    by Uruk ( 4907 ) on Thursday March 07, 2002 @10:48AM (#3124338)
    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 [freenetproject.org] 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. :)

    • Re:Engineered in (Score:5, Informative)

      by viega ( 564643 ) <viega@@@list...org> on Thursday March 07, 2002 @10:51AM (#3124355) Homepage
      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.

    • For an example of the results of engineered in vs. added on security, examine Unix and Windows. Unix was from the start a networked multiuser system, and security was paramount. Windows on the other hand was based on DOS which was originally intended for single user non-networked PC's. The result? *nix community worried about a better firewall and password protection, and MS creating a department of 'Security Assurance' to tell customers their software is secure no matter what the truth is.

      So yes, designing security in from the beginning is important.

  • Great Read (Score:2, Funny)

    by tenman ( 247215 )
    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.
    • Tolkien did, and it's called: the Silmarillion.
      • LOL. I tried to read that book years ago, and I'm still running around dazed & confused.
        • Try again. It is worth it. Once you get into it, you'll wish it were longer.

          He Rewrote the stories about Turambar, Beren & Luthien, and Earendel at least 3 complete times. IMHO these are the most important stories. The versions in Unfinished Tales are the best but they are, um, unfinished.

          We now return you to your regularly scheduled program

  • Secure Programming for Linux and Unix HOWTO (Score:5, Informative)

    by geirt ( 55254 ) on Thursday March 07, 2002 @10:51AM (#3124361)

    My favorite:

    http://www.dwheeler.com/secure-programs/ [dwheeler.com]

  • Security is very important in today's software (Score:4, Interesting)

    by Semi_War ( 163701 ) on Thursday March 07, 2002 @10:58AM (#3124377) Homepage
    I'm teaching programming in a college in holland, and we have a nice course here to write a "simple" IntToStr. The outcome is so suprising, nobody thinks about simple things like:

    -Minus not followed by digit
    -several minus signs after each other
    -minus preceded by a 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.
    • Do you mean StrToInt?

      If so, I'm always surprised at how many people miss the common case of correctly parsing the most negative integer.

      Praise grid for libraries, in this case.
      • Indeed, Libraries are a good alternative, and yes I did mean StrToInt. The fun part of this whole exercise was that we had a test-program that would test these function on various conditions - (underflow, overflow, bounderies, syntax errors). I can't remember if we actually tested the library StrToInt. But sometimes we lay to much faith in libraries, and i guess that's the bigest security risk of all. That's probably the reason why so many programmers say: If you want to have good software you'll have to write it yourself... Although i must agree that OpenSource is the best step in making software bug-proof. I remain sceptic on the question if OpenSource is actually hack-proof.
    • You have a WHOLE course just to write a StrToInt function?!?

  • Security is like Online Gaming. (Score:4, Insightful)

    by Anonymous Coward on Thursday March 07, 2002 @11:01AM (#3124395)
    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 can't help but agree. Where I work, one of the senior developers' creed is: trust the user. Every time he says this, I think of my next performance review and getting comments like "Good work on finding those bugs by the way." The simple rule should always be: You are not the user, so design it for morons and maniacs.
    • Like online gaming.. and slashdot.

      Many changes to the mod system are rejected because of the possibility for abuse (see the FAQ). Not to say it's perfect as it is, of course.
    • 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.
    • The funny thing is, EQ wasn't designed with security in mind. Yes, they had some vague concept of "don't trust the client", but in fact most of their security was on the presumption that their byte stream wouldn't be hacked.

      Well, it was. And so came ShowEQ. And much of the world that was supposed to be "hidden" isn't. ShowEQ gives a tremendous advantage, if only to show things like bugged monsters that won't path back to their home properly and will continue to interfere with pulls. More shady people use it to check on mob spawns in a zone. All of this is possible because during the design of EQ they chose to send the client information on EVERYTHING in the zone instead of just an area near you (this is also why EQ is broken into zones in the first place, and is largely an artifact of EQ's MUD origins and how old it is now).

      They've gotten smarter though. They stopped sending the monster's hp's as a signed short and started sending it as a percentage (this also allowed them to exceed 32767 hp on monsters). They stopped sending the actual number associated with faction (-2000 to +2000) and started sending a number indicating level (0 = worst, 7 = best). Numerous other silly things like this, which should never have been in the datastream to the client in the first place, have been fixed.

      Of course, there's still the gaping holes of spdat.eff (the Spell Data Effect file - lists every spell in the game and their effects), the fact that they send full item data over the wire when you inspect an item (including undisclosed stuff like haste percentage), they still send mana available for spell casters over the wire, and several other things.

      The mantra of network game programming - don't trust the client - should be a mantra for most coding if you want it to be secure. And while you can attempt to patch crap afterwards, if you don't design it in from the start you will wind up with security holes that are too expensive to fix.
  • I'm sure that this [microsoft.com] book will be most helpful. After all, who better to learn from than the staple of application security?

  • Seminar By Author (Score:4, Informative)

    by Proaxiom ( 544639 ) on Thursday March 07, 2002 @11:13AM (#3124443)
    I find this interesting because I was planning on attending a seminar in a couple of weeks by Gary McGraw, one of the book's authors.

    It's hosted by the Centre For Applied Cryptography Research (CACR) [uwaterloo.ca] 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

  • Security is a process (Score:3, Insightful)

    by stevey ( 64018 ) on Thursday March 07, 2002 @11:20AM (#3124466) Homepage

    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 [gnump3d.org], 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 [securityfocus.com], 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!

  • This author of this article should have posted this review under the Worst Acronyms [slashdot.org] headline from a few days ago.

  • Worst review ever! (Score:1, Insightful)

    by Yankovic ( 97540 )
    The book may be good or not. The content may be good or not. The authors may have had insight or not. Too bad no one could possibly know after this review. There are entire paragraphs that make absolutely no sense. I quote:

    "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 [quartertothree.com]

  • 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.

    • Do you think a book on building secure software would be anything but laughed at if it didn't talk about buffer overflows? Actually, in the book, we do talk about how insider attacks are the most common kind of attack, and we encourage people to consider that in their risk management process, through design and into implementation.

      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.

    • 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 :) )
  • 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.

  • ... After reading Building Secure Software: How to Avoid Security Problems the Right Way (BSS:HtASPtRW), I decided I needed to ...

    Quite an abbrevation, doncha think? :D
    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.
  • 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.
  • Judging from this short review, it just sounds like another in-depth Ode to the various inherent flaws of C. Is that all?

    Hopefully not, but from other reviews/stories I've seen here on /. 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.

    If that isn't the case, I would have really appreciated a more thorough review (beyond "I liked it").

Slashdot Top Deals

UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker

Close