REVIEW: "Exploiting Software", Greg Hoglund/Gary McGraw

Discussion in 'Computer Security' started by Rob Slade, doting grandpa of Ryan and Trevor, Jun 28, 2004.

  1. BKEXPLSW.RVW 20040531

    "Exploiting Software", Greg Hoglund/Gary McGraw, 2004, 0-201-78695-8,
    %A Greg Hoglund
    %A Gary McGraw
    %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
    %D 2004
    %G 0-201-78695-8
    %I Addison-Wesley Publishing Co.
    %O U$49.99/C$71.99 416-447-5101 fax: 416-443-0948
    %P 471 p.
    %T "Exploiting Software: How to Break Code"

    I have learned to beware of books with titles like this, which
    generally indicate a hastily compiled set of old vulnerabilities,
    benefitting nobody save the author. This work, however, turns out to
    have a lot of value for those interested in security of software.

    Although it does not deal with the factors inherent in software that
    almost ensure problems, chapter one outlines the fact of bugs in
    software, the relative rate and increasing prevalence, and future
    developments that may exacerbate the issue. Chapter two provides
    taxonomies of general types of software problems (distinguishing, for
    example, between a bug and a flaw), patterns of attack activities
    (pointing out that most exploits are used in combination), and types
    of system scanning activities (used to determine specific attacks that
    might be effective). This material is very useful in structuring the
    debate about software exploits and attacks in general, but,
    ironically, the chapter (and book) itself could benefit from better
    organization. Reverse engineering, both via black box testing and
    through code analysis, is described in chapter three. The discussion
    is general, and presents the different activities that can be
    undertaken, usually at a fairly abstract level. (This is not true in
    all cases: there is a chunk of twelve pages of code for a plug-in
    module and eight pages of script for the IDA disassembler, which is of
    questionable utility, depending on the familiarity the reader may have
    with that particular program.)

    At this point in the book, the issue of the validity of the "learn to
    exploit in order to learn to protect" philosophy should be addressed.
    In general, the "hack to protect" books do not provide much that is of
    value for the defenders. That statement is not necessarily true of
    this work. Since most of the presentation is at a conceptual level,
    it is the ideas, and not particular exploits, that are being reviewed.
    The authors are explaining tools and techniques that, yes, can be used
    by attackers, but can equally be used by those who wish to probe a
    given system for weaknesses in order to determine vulnerabilities to
    be patched. (There appears to be only one exception in chapter three:
    the authors note that vendor patches tend to act as a roadmap for
    vulnerabilities, and it is difficult to say how this technique is
    useful for defence, other than to note that the probability of an
    exploit increases after a patch has been issued.)

    Chapter four lists types of attacks on server software, while five
    looks at clients, primarily web browsers. Indications pointing to
    patterns of malformed input that are likely to generate successful
    exploits are described in chapter six. The classic and ubiquitous
    buffer overflow gets a detailed explanation (supported with a number
    of examples) in chapter seven, which has a strangely extensive section
    on RISC (Reduced Instruction Set Computer) architectures. Chapter
    eight is rather disappointing in light of the tone of the rest of the
    book: it is primarily concerned with how to create and program
    rootkits, and the worth for defence is doubtful.

    While ultimately of greatest use to a rather select audience (those
    specifically concerned with finding and patching loopholes in
    software), this book does have a lot to say to most security
    professionals. The security aspects of software development tend to
    be glossed over too quickly in most general works on security.
    Specific examples of malformed input are used, in too many security
    texts, as evidence of the author's superior security erudition, rather
    than to explain the underlying concepts. Hoglund and McGraw have
    prepared solid tutorials and definitions of these important ideas
    (although one could wish that they had prepared the arrangement of the
    book with the same degree of care).

    copyright Robert M. Slade, 2004 BKEXPLSW.RVW 20040531


    ============= for back issues:
    [Base URL] site
    or mirror
    CISSP refs: [Base URL]mnbksccd.htm
    Security Dict.: [Base URL]secgloss.htm
    Security Educ.: [Base URL]comseced.htm
    Book reviews: [Base URL]mnbk.htm
    [Base URL]review.htm
    Security Educ.:
    Review mailing list: send mail to
    Rob Slade, doting grandpa of Ryan and Trevor, Jun 28, 2004
    1. Advertisements

  2. Rob Slade, doting grandpa of Ryan and Trevor

    johns Guest

    I have a simple solution that bypasses all of this. Every
    computer on the web should transmit its ID and exact
    location with every transaction it generates. That
    transmission should come at the "ISP" level, and include
    access to Personal information about the user. That
    way, when someone pushes a new virus or whatever,
    we can pay him a little visit ... sort of like a cop stopping
    a speeder on our public roads. I don't see any problem
    at all with applying our traffic laws to the computer
    industry .. including licensing of users. Personally I
    think that no one under the age of 35 should be allowed
    to touch a computer that is attached to the internet.
    I think licensed users should be required to take a
    "driving" test every 2 years .. both written and on
    the web. And I think a valid login license card should
    be required for a user to even turn his system on.
    I also think that the net cops should be allowed to
    turn his system off until he reports in person to a local
    Magistrate and explains what he was doing .. at which
    time, the Judge could pull his access card if need be.
    Even better .. if someone wishes to "travel" across
    our borders, they should be required to present border
    access agents with a photo id registered with our Federal
    Government at the time of passage. And even more
    better .. If that individual is an "outsorced" employee
    of a company physically located on our soil, the
    transmission should be assessed a tax for the use of
    our tax-supported networks. In particular, if that
    transmission involves payment of saleries to this employee
    I think that a percentage of that salery, depending on
    the country that it came from, should be returned to
    the American taxpayer to repay debts those countries
    have incurred to us during past wars and other
    emergencies. The Internet is a business. It should be
    guided by the laws that govern any business.

    johns, Jun 28, 2004
    1. Advertisements

  3. Rob Slade, doting grandpa of Ryan and Trevor

    madmax Guest


    To help you stay safe see:
    This message is virus free as far as I can tell.
    Change to so you can reply
    ( has been set up specifically for
    use in Usenet. Feel free to use it yourself.)
    madmax, Jun 29, 2004
  4. Rob Slade, doting grandpa of Ryan and Trevor

    *Vanguard* Guest

    johns said in news:cbq5tn$bi7$:

    Changing the Internet from anonymous to non-anonymous will almost
    require a parallel Internet be setup for those that want a non-anonymous
    Internet. You can then decide what, if anything, you would permit to
    cross-over from the anonymous Internet into your accounts. In a way,
    SPF (Sender Policy Framework) tries to do this within the existing
    Internet (see Although SPF sounds like it is a
    solution in the right direction, there is a lot of debate over its draft
    proposal (by folks a lot more knowledgeable than I).

    Beyond this, I think much of your other "suggestions" would make
    computer use so onerous to each user that no one would use a computer.
    Suggesting that only folks over 35 years old could use a computer
    assumes that users are extremely slow to learn and have little retention
    (may be true for you but not most of the last 2 generations; I'm used to
    learning new technologies EVERY year!). If technology becomes
    oppressive then it goes unused as folks will find a simpler solution.
    Just eliminating the ability to hide would itself eliminate a huge
    majority of the problem (and blocking any sending server that doesn't
    comply with providing non-anonymous traffic would quickly get them in
    line or create a dichotomy of 2 Internets).
    *Vanguard*, Jun 30, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.