Suggestions
blog December 5th, 2006
We’re interested in hearing your thoughts on what you’d like to see covered in a second edition. The following is a summary of the feedback we’ve received from readers, as well as an outline of some of our ideas.
Suggestions
Here are some of the suggestions we’ve gotten so far:
1. Binary Analysis
This is a popular suggestion. We don’t spend too much time talking specifically about binary analysis, though there are some useful tidbits:
Chapter 4 - tracing back blackbox hits - page 124-128, debugging / binary analysis tools - page 151-158
Chapter 6 - auditing for sign-extension - page 258, arithmetic right-shift - page 274, idiv vs. div - page 277
Chapter 12 - RPC binary audits - page 722, COM binary audits - page 743
Chapter 16 - Reverse-engineering protocols - page 924-937
In general, much of our coverage also applies to binary analysis, even though it’s targeted at higher levels of abstraction. There’s definitely a void in the market for a good binary analysis book focusing on security. (To be fair, we haven’t reviewed the current offerings, but our gut instinct is that no one has really nailed it yet.) That said, we definitely think we could put together a good chapter that would help arm the reader with the basic lay of the land, and show how to apply the other information in the book in a binary audit. We’re not bad at binary analysis; using the standardized ISO 2005 NNMI rating (Normalized Neel Mehta Index), Mark, John, and Justin rate a .72, .63, and .54 respectively. That said, we’ll probably get Halvar and Neel to lend a hand in making this chapter, if we can bribe them sufficiently.
2. Web Frameworks
We cover general web security and the fundamentals in Chapter 17, and we provide a decent reference for common technologies in Chapter 18: CGI, Perl, PHP, Java, ASP, and ASP.NET. That said, we could definitely improve the depth of our coverage in Chapter 18. Readers have suggested that we also cover some of the popular web frameworks and technologies in more depth, such as struts, websphere, ruby on rails, web 2.0, and J2EE. We’ll have to wait and see what makes sense and how much space we have to work with. Let us know what you’d like to see and we’ll add it to the priority queue.
3. Kernel Auditing
A few of you suggested that we put some more information specific to auditing kernel code in the book. We’re not sure if this would be +EV, so we’ll crunch the numbers and get back to you.
4. Firewalls and NIDS
The firewalls chapter is pretty short, and could use a little love. Next time around, we’ll do this better, and give some treatment of NIDS/NIPS. There’s some discussion about this in the Vault entry on the Firewalls chapter.
Our Ideas
Here are some ideas we had for further content. These are just brainstorming, so no promises. Let us know what you think!
1. IPv6
We’d like to do some coverage of IPv6 since it’s fun. Mark’s already done some great research, available here, that’s resulted in at least one advisory. Ideally, we’ll integrate this into Chapter 14 on Network Protocols, which currently covers IPv4, UDP, and TCP.
2. File Formats
The coverage of auditing application protocols in Chapter 16 is actually quite applicable to audits of file parsers. If we revisit that, we’ll probably refactor the coverage to include both topics.
3. Deep Language Coverage
Our book is very much focused on C, since much of the software we audit is written in C/C++. Furthermore, we use it for most of the examples of security issues that are basically language agnostic, like the Unix and Windows chapters and the content in the Strings and Metacharacters chapter. This is mostly because C is a good common denominator that everyone should be able to follow. We reserve most of our treatment of the higher level languages for the Web content, as that’s the context in which we encounter it the most in our day to day jobs. That said, we’d like to take a couple of languages and really give them the in-depth focus that we allocated towards C. C++ would be a good candidate, especially focusing on all its subtle gotchas, and also STL and pitfalls with other common libraries. Java, C#, VB, and perhaps Ruby and Python would be other good candidates. Let us know your thoughts and what you’d like to see us dig into deeper.
4. Databases
In the vein of more language coverage and improving the web stuff, we could use a more direct treatment of databases and SQL dialects. In particular, we’d like to show how popular databases have subtle differences in handling exceptional conditions—or even some common operations. At a minimum, we could make sure to cover SQL injection in the stored procedure languages of each RDBMS.
5. Cryptography
Cryptography is a tricky one, but we think there’s room for an interesting chapter that would extend the coverage we currently give in Chapter 2. The premise would of course be that we’re not qualified to review crypto mathematically, and chances are pretty good you aren’t going to be either. However, we do review crypto code in our day to day jobs, and we’ve found some rather interesting vulnerabilities. Basically, we’d try to explain how to walk the fine line between reviewing cryptography protocols and implementation and reviewing cryptography algorithms. We could cover all the common misuses that we see crop up, and also talk about how to take an observation of a deviation from best practice and try to research it against the existing academic crypto literature. We could also run through common mistakes with popular APIs such as OpenSSL and the MS Crypto API.
6. MacOS X
We could probably extend our Unix coverage to include MacOS. That would probably mean one of us would have to buy one.
Added suggestions 7-9.
Broke it up into two sections and added MacOS X. Changed intro.
A little birdy told me that we forgot to mention this:
http://lists.seifried.org/pipermail/security/2006-April/013124.html
Unfortunately, the little birdy spoke German, so I’m not sure if I understood him correctly. :>
When may we expect the second edition to be available?
Well, we’re being a bit presumptuous in assuming there will be a second edition. If there is, it probably won’t be for a couple of years.
That said, we’ll use reader suggestions to help plan our ongoing research, which we’ll publish here as time permits. If there is a second edition, this content will probably get rolled into it.
duke, horizon and justin
Just got a copy of taossa and wanted to say thanks for such great book.
Hands down best book on this subject!
Page 208: Ones complement . has the amusing ambiguity of
having two values of zero: positive zero and negative zero.
This is not amusing, since at the hardware level there is no ambiguity. Since negative zero is less than zero. So, there is a potential security problem, since codes often compare to zero. Since we are talking about integers and not IEEE floats, negative zero and positive zero are the same.
((-x) - (-x)) < (x-x), for positive x, if done directly in hardware as printed, and the hardware does not have extra hardware to check for this special case.
Kurt-
I responded on the Errata page. Thanks!
> 1. Binary Analysis
I would like to see this covered more in-depth. I would like to see a walkthrough of using IDA Pro (as an interactive disassembler/debugger) with HexRays (decompiling) to find a heap overflow in a Windows application. Additionally, finding a heap overflow using BinNavi (interactive disassembly/debugging) or IDA Pro (disassembly). Techniques such as call flow graphs, basic blocks, leap frogging, and boron tagging would be excellent to demonstrate.
Also - using Jode/JReversePro (decompiling) along with JSwat (debugging) and IDA Pro (supports Java bytecode and call flow graphs). Instead of using IDA Pro to do binary analysis on Mono/.NET assemblies, you could show how to use .NET Reflector and Salamander (in addition to Reflector plugins such as Deblector, Graph, and Reflexil).
> Theres definitely a void in the market for a good binary analysis book focusing on security
A new book on IDA Pro is coming out soon - http://isbn.nu/9781597492379/
> 2. Web Frameworks
> Readers have suggested that we also cover some of the popular web frameworks and technologies in more depth, such as struts, websphere, ruby on rails, web 2.0, and J2EE
Dont cover everything. Cover Hardened-PHP, ASP Classic, and HDIV+Spring for primary web frameworks. If you want, cover JSF (but please no Struts/Struts2 or JSP), although Java / JEE really isnt very popular and Id rather see up-to-date information on ASP.NET or something else. I suggest covering point technologies such as Javascript, Ajax, and Flash as best as you possibly can (Aptana, Firebug, and flashsec.org / http://code.google.com/p/swfintruder/wiki/SWFIntruder - all come to mind first).
> 3. Kernel Auditing
Secure design and code inspection for kernel software weaknesses would be my top pick, especially if you went into xg++ / Coverity Prevent Sqs. An interesting combination would be binary analysis and kernel bug-finding. I had the thought the other day to try and combine WinDbg with SDbgExt (from Skywing) to output to IDA Pro for reversing of the Windows Vista kernel and drivers (although debugging in IDA would not be possible, sadly). Although I think some sort of reversing technique for Mac OS X at the kernel/driver level would be even more educational, especially iPhone or similar embedded device.
> 2. File Formats
File fuzzing is such an important field of security testing. There is way too much to talk about and this should really be its own book. However, if possible to cover a commercial tool such as Symantec Engine Evasion Attack Suite from Ollie Whitehouse - this would be ideal. I would like to see examples of enhancing the test cases in SPIKEfile, notSPIKEfile, FuzzyFiles, and FileFuzz (http://fuzzing.org), as well as how to identify/monitor exceptions - especially along with AppVerifier or gflags.
For dealing with binary files of an unknown type, it would be interesting to show how to build a parser to find TLVs and export the file format structure as XML (possibly compatible with SEEAS). I can think of many other features to add, but being able to search by bytes with different encodings/compressions and ability to update these and CRC values would be very nice. Everyone seems to be relying on PaiMei or EFS to locate the areas of code so they can manually do the rest of the work.
> 3. Deep Language Coverage
>
> Java, C#, VB, and perhaps Ruby and Python would be other good candidates
Write about all the software weaknesses you want! Thats the primary benefit of the current edition.
> 4. Databases
Im a bit sick of hearing about input validation / output encoding (for XSS) and parameterized queries (for SQLi) every single day of my life and covering 1-3 chapters of every book. These issues are simple. If you could talk about more advanced techniques such as using PQL to help find SQL injection, I would stay interested.
Awesome, dre! Thanks for the feedback and ideas!
Analyzing obfuscated code?
Kernel Exploitation?
Regards
Hi, I think it would be nice if you add something (chapter) about shellcodes in Unix and Windows environments.