Slashdot Mirror

prostoalex writes "Why are networked computing environments so insecure? You've heard the story before - early computers were not designed to work in the network environment, and even most software written later was designed to work on benevolent networks. As Bruce Schneier says in the preface to Building Secure Software: How to Break Code, 'We wouldn't have to spend so much time, money and effort on network security if we didn't have such bad software security.'" Read on for prostoalex's review of Exploiting Software, which aims to balance that situation somewhat. Exploiting Software: How to Break Code author Greg Hoglund, Gary McGraw pages 512 publisher Addison Wesley Professional rating 8 reviewer Alex Moskalyuk ISBN 0201786958 summary Techniques and software used to attack applications.

What kind of secure are you after? There are many published titles on the topic of software security are numerous, but most of them follow certain patterns. Building Secure Software by Viega and McGraw was mainly concerned with proper techniques and general software engineering mindset without going into specifics. Then there was Writing Secure Code , by Howard and LeBlanc, which provided concrete examples and showed the "right way" to do secure coding. I heard the title instantly became a required reading at world's largest software corporation. It's currently in its second edition.

Secure Programming Cookbook for C/C++ by Viega and Messier, was the hands-on title for those developing C/C++ application with security in mind, as the cookbook recipes generally gave examples of good code, with each chapter providing some general background information on the topic discussed (I reviewed it on Slashdot in September last year).

Just in case you were wondering, the list above wasn't just retrieved by a quick search at Amazon. My Master's degree, completed last summer, dealt with the topic of software security, and those are the titles I've read preparing to write the theoretical part.

From the other side With the variety of books on how to write secure software, and what techniques to use to make existing software more secure, there was a niche for a book targeted specifically to those who wanted to break software. Black hat or white hat, the network security experts always had titles like Hacking Exposed to give them an idea of what was available in terms of techniques and methodologies used out there. For software security most of the articles and books generally would tell you something in the terms "do not use strcpy(), as it introduces buffer overruns".

Great, so I won't use strcpy(), did it make my application more secure? Is it more or less hack-proof? What if I am a tester and required to play with this aspect of the application to ensure the application's security before the product ships? Theoretically hanging out at proper IRC rooms and getting lifetime Phrack and 2600 subscriptions should be enough to cover you at the beginning, however, the learning curve here leaves much to be desired, let alone the fact you will probably be kicked out of the IRC rooms for asking n00b questions. Another path would be to take an expensive training course by someone with a name in the industry, but the price tag for those generally leaves out self-learners and those operating on limited budgets, which adds up to about 99% of software engineers and testers out there.

Exploiting Software to the rescue.

Exploiting Software fills the void that existed in this market. Eight chapters take you through the basics and some advanced techniques of attacking software applications with the purpose of executing arbitrary code supplied by an attacker (you).

The book mainly deals with Windows applications for x86 platforms, and some knowledge of C/C++ and Win32 API is required to go through the example applications. To automate some processes and demonstrate possible attacks the authors use Perl, so knowledge of that would help the reader, too. Some chapters, (e.g. the buffer overflow one) show disassembler output, and while you're not expected to read x86 ASM code as if it were English, knowledge of how the registers work and how the subprocedure calls are handled on this Intel architecture are required. After all, if potential attackers know it, you better familiarize yourself with some low-level code, too.

While discussing various possible attacks, the authors post different attack patterns. The patterns themselves usually appear in gray textboxes and talk about the possible exploit in general terms. After that, a series of attack examples follow, with specific descriptions on what can be done, and how. For example, the attack pattern on page 165 is titled "Leverage executable code in non-executable files." The following attack example is "Executable fonts," and it talks how the font files are generally treated by the Windows systems (they are a special form of DLLs). Thus it's possible to embed some executable code into a font library you're creating, for which the authors provide an example in Microsoft Visual Studio.

What's cool is that all the attack patterns are listed in a separate table of contents (alas, not on the Web site table of contents, which just lists the chapters and subchapters), so you can browse to the attack pattern you decide to learn about, read some general info about it and then study specific examples. The examples themselves are not in the table of contents, which I think is a mistake, as it would make searching for possible patterns much easier. After all, how are you supposed to know that "Informix database file system" (p. 189) is under "Relative path traversal" pattern? Well, unless you know specifically that the line http://[Informix database host]/ifx/?LO=../../../etc/ is the one discussed in the example, you would have to either go through the index hoping no omissions were made, or read the chapter in its entirety.

One of the best chapters of the book, Reverse Engineering and Program Understanding, which provides a good introduction into techniques used throughout the book, is available online from Addison Wesley. By having a free chapter you already have 1/8th of the book, but don't think that the low number of chapters makes this 512-page title an introductory book.

Target Audience

Looks like there are two major audiences and reading patterns for this book: those wanting to fix their systems ASAP and thus using Exploiting Software as a reference, and those using it as a text book to learn about security. I've discussed the organization of the book above, and the reference types will probably be more interested in patterns and examples. For a casual reader (although casual readers wouldn't generally pick up a title with C++, Perl, ASM and hex dumps spread around the chapters) this is a book with great educational value, from two authors who have discovered numerous security vulnerabilities themselves.

Exploiting Software is not an easy title to read. Addison-Wesley shipped me the manuscript copy a month before it hit the bookshelves in its final version, and I found myself going through about two pages an hour. The authors bring up sometimes unfamiliar Win32 APIs and occasionally use ready-made tools available on the Web, so generally I found myself visiting MSDN and Google a lot to read through available documentation and download the latest version of the tools used. The book doesn't come with a CD. Some of the stuff, like inserting a malicious BGP packet to exploit a Cisco router (p. 281) is not really testable at home, and I have some reservations about verifying the example with my employer's routers.

The book is probably apt for 2nd or 3rd year computer science students and above. Besides the variety of languages that I mentioned above, you need to be familiar with the basics of Intel architecture, and generally be fluent with terminology like "buffer," "stack," "syscall," "rootkit," etc., as this is not an "Introduction to..." title. From my experience, you probably won't read it from page 1 to page 512 understanding everything perfectly, but for anyone interested in security and those making a career in software development it looks like a bookshelf must-have.

I interviewed Gary McGraw on the current state of software security, the relevance of the topic to the issues beyond C/C++ and improper buffer usage, and future directions in security. Network World magazine also ran an interview with the McGraw in which he talks about the reception of the book at the RSA Conference, whether the economics is right to invest in building secure systems, and whether his book does more harm by providing a compendium of known exploits.

Alex has written numerous reviews of other software and security titles. You can read more of his opinions at his Web site. You can purchase Exploiting Software: How to Break Code from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

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.