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

BKEXPLSW.RVW 20040531

"Exploiting Software", Greg Hoglund/Gary McGraw, 2004, 0-201-78695-8,
U$49.99/C$71.99
%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
%O http://www.amazon.com/exec/obidos/ASIN/0201786958/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0201786958/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0201786958/robsladesin03-20
%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 http://victoria.tc.ca/techrev/
or mirror http://sun.soci.niu.edu/~rslade/
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
Partial/recent: http://groups.yahoo.com/group/techbooks/
Security Educ.: http://groups.yahoo.com/group/comseced/
Review mailing list: send mail to
or

 

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

 

-max

--
To help you stay safe see:
http://www.geocities.com/maxpro4u/madmax.html
This message is virus free as far as I can tell.
Change nomail.afraid.org to neo.rr.com so you can reply
(nomail.afraid.org has been set up specifically for
use in Usenet. Feel free to use it yourself.)

 

johns said in news:cbq5tn$bi7$:

<snip>

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 http://spf.pobox.com/). 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).