MWJ update read by some

We’ve had our heads buried in the upcoming issue for a while and forgot to post an update until a few of you reminded us – sorry. MDJ 2006.12.06 is now in the MWJ RSS feed to help tide you over.

Long-time MWJ readers may remember May 2003, when MWJ seemed to vanish for a couple of weeks back before any health problems had come to the fore. The reason? MacCyclopedia was taking a complete look at HFS and HFS Plus, something we believed was necessary at a time when non-developer explanations of the Mac file system simply were not available. It took a long time, and not everyone agreed with that decision, but we were comfortable with the editorial decision. We’ve built on those concepts many times in the past 3.5 years, and will do so again this month with coverage of Alsoft’s DiskWarrior 4.

Right after WWDC 2006, we knew that the Macintosh story of 2006 was going to be security. We’ve covered the topic on and off in MWJ, including a few explanations of terms like buffer overflow, but it was time to take a much broader look at the issue. We set out to answer some of the obvious questions:

  • How do you know if a “vulnerability” is serious or not?

  • What was the deal with the “MacBook wireless hack?”

  • How can data, like movies or JPEG files, be a security problem?

  • When should I apply security updates?

  • What’s wrong with Safari’s “Open ‘safe’ files after downloading” preference?

And, of course, the big one:

  • Is Mac OS X more secure than Windows?

This is what we started assembling in August, even as the publisher’s “flu” got worse and worse until it turned out not to be the flu at all, and that became the primary focus for a couple of months. That’s how that had to be, and we all know that, though we still grump about it (especially him).

But both before and after the major health problems, this security story has been kicking the crap out of us, and we’re not too shy to admit it. It’s not just that security reports change by the day – that’s confusing, but we’re used to changing situations. It’s that our repeated attempts to put a narrative structure around these concepts failed, and failed, and failed again.

Some of the above questions have only unsatisfying answers, as you’ll see in our coverage. You can’t always know certain details about security problems, and you must make the best you can with what’s available to you. Discussing that process has taken more than we ever imagined, because every explanation tries very hard to slip into the Land of Jargon. You can find explanations like “the exposure for the vulnerability is predicated upon privilege escalation and user participation in adversarial activities,” but it’s a lot harder to find “You’re relatively safe from this problem if you don’t click on the URL or download the program. If you do, it could run with the same privileges as your user account. If you’re running as ‘root’ and let this thing have control, you’re totally screwed.”

Jargon is safe and comforting – passive voice, concept nouns, linking verbs. Jargon has no action – bad things “could result” from vulnerabilities that “allow” tasks “to happen.” It’s like the gag a few years ago in The Simpsons where Lisa tips off a local newspaper reporter that her brother and his friends are doing good in the community. The reporter says he has the perfect headline for it: “ACTIVITY PARTICIPATED IN BY SOME.”

It’s not that we have to “translate” this, for we understand the concepts. It’s that we fall into jargon as well because it’s so familiar when describing security issues, even though jargon obscures the facts. It turns into page after page of deathless, impenetrable babble, and no one knows any more after reading it than they did before. You expect better from us, and we expect to provide it.

We just didn’t expect it to kick the crap out of us for so long. Some of the sections in MDJ 2006.12.06 (and upcoming in MWJ) have, literally and without exaggeration, been rewritten 15 times since August to cut out the cruft. The newer material hasn’t had such extensive review, but we’re looking at it very carefully. As Strunk & White say, “Omit needless words. Vigorous writing is concise.” Zinnser adds, “There’s not much to be said about the period except that most writers don’t reach it soon enough.”

Sound like any security writing you’ve read?

A heap buffer overflow may be triggered when the Finder is used to browse a directory containing a corrupt “.DS_Store” file.

An integer overflow exists in Perl’s format string functionality. This integer overflow may lead to arbitrary code execution in Perl applications which use format strings unsafely.

It is possible to create an X.509 certificate containing a public key that could consume a significant amount of system resources during signature verification. An attacker may cause a system to process such a certificate, leading to a denial of service.

Sure, there are some subjects and direct objects, but not many. It’s so familiar we don’t even notice the writer passing the buck. Try these replacements:

  • The Finder may overflow a buffer in its heap if it reads a corrupt “.DS_Store” file.

  • A bug in Perl’s “format string” functions overflows an integer variable when Perl code uses the functions unsafely, either accidentally or deliberately to exploit the problem and execute attack code on your system.

  • Mac OS X’s X.509 certificate verification code has a bug – it can get stuck forever during signature verification if the certificate contains a public key crafted to exploit this bug. A malicious Web site or other Internet resource could present such a certificate to the system, locking up the program that tried to verify the certificate, a “denial of service” problem.

What may overflow a buffer? Finder (or, just as likely, the private “Desktop Services” framework that provides the Finder’s back-end). In Apple’s description, you can’t know – the problem “may be triggered” when the Finder does something. Does the X.509 code have a bug? Apple only wants to say that “it is possible” for an unnamed someone “to create” a certificate “that could consume” system resources. But certificates don’t consume resources. The code that verifies certificates consumes resources. That’s where the problem lies – and that’s what Apple (and every other company with security problems) conceals with the passive voice.

It’s not just about vigorous writing – passive voice hides the facts by leaving out subjects and objects. We want facts like “Pre-Teen Braves Restore Local Field,” but we get “Activity Participated In By Some.

We’re trying not to fall into that trap, and it’s taking time. Read the first part from your secure MWJ RSS feed and tell us how we’re doing. This is MWJ’s Book on Security, and we want it to settle as much as it possibly can.