The team at SysInternals has just released RootkitRevealer, which does essentially what Microsoft’s still-internal Ghostbuster tool does; namely, it runs a couple of scans of the hard drive from different levels (user mode and kernel mode, essentially). Any discrepency could potentially be the result of a rootkit attempting to hide its tracks.

In an earlier post, I talked about the applicability of tools like Ghostbuster vs. things like Tripwire. Seems like the guys at SysInternals are in agreement, noting that RootkitRevealer could still be tricked by really sophisticated kernel-mode rootkits, and that off-line (CD bootable, etc.) scanners would be more sound, but still potentially susceptible to false negatives.

Regardless, big kudos to them for getting the tool out there and not making us all wait for Ghostbuster. Plus, now we don’t have to put up with a bunch of “he slimed me” jokes.

Bruce Schneier points out, rightly, that Microsoft should release its internal-only security tool (codenamed GhostBuster) as an open source project, or at the very least, as a commercial tool for people managing Windows deployments. He is absolutely dead on; no matter what state this product is in, it is in Microsoft’s, and all of our, interest to get that in the hands of the public as soon as possible.

However, I’m not quite as keen on this tool as I am on something like Tripwire. GhostBuster relies on something inherently unreliable to do its job: the behavior of malicious software. One of the most common kinds of security problems found in the wild are rootkits. These are pieces of software that live on the machine, waiting for instructions from off-server (usually from an IRC server). More insidiously, they usually hijack system services to hide their existence, by filtering system requests for directory listings, registered ports, etc.

GhostBuster works by running a program within the potentially affected OS to, essentially, list all the files on the machine (its more complicated than that). Then, you boot to the GhostBuster CD and run the same probgram, this time from the bootable OS on the CD. This version of the program won’t be infected by any rootkits, and any files hidden during the first run will show up. GhostBuster then compares the two result sets and alerts you to the different (malicious) files.

This is a great idea, but as I said earlier, it relies on assumptions about what the rootkit is doing in order to work effectively. If a rootkit adapts to recognize when the GhostBuster program is being run, it can choose not to hide the offending results from the program. This will cause a tit-for-tat war of escalation, exactly like what we have in the anti-virus world.

Tripwire, and tools like it, work differently. You only run these tools from bootable CD, thus ensuring that they are never tainted. The tools check the files on a given disk, and record statistics about those files. Using highly configurable rules, the app then checks the results of future runs against the baseline, alerting you to changes. This means that, instead of fighting against the behavior of malicious code, you are fighting against the behavior of your own system adminstrators (changes will either be malicious code or normal changes to the system, and your rules have to rule out the good changes). This strikes me as an inherently more stable approach.

However, I’d love to have GhostBuster in my own toolchest, and a truly effective rootkit detection strategy would employ both approaches.

Here’s the text of the one-star review.

“This book with its talk of the business “sponser” was not even spell checked. The code will not compile because in Java declarations are case sensitive. Whole paragraphs are repeated. The content is vague and seems to be more of a rant than an attempt to teach.

Horrible. One star is generous.”

This reviewer sent an even more thorough review to O’Reilly directly, but as that was a private email, I’ll not repost those comments here.

Mr. Braithwaite may very well have some legitimate points. Our content might be somewhat vague, though I rather like to think of it as “general”. I also don’t see it as a rant, but a reader who is heavily invested in some of the technologies we target might very well feel ranted at, I suppose.

My only problem with the review? If you find a spelling mistake or an editorial problem, please let us know so it can go on the errata page. Luckily, we were able to figure out where the word “sponsor” was misspelled and add it to our list….

(p.s. the code problems were the result of MS Word’s auto-capitalization. We should have caught them nonetheless, but at one point, all that code compiled…...and even ran! :) )

Ted Neward has begged for a definition of “service”, fearing that SOA will become just so much marketecture littering our already littered landscape. Well, for starters, too late.

However, since he asked, here’s my definition of a “service”.

Service. n. (sir-viss) A unit of functionality that has a better than 10% chance of being called by an alien machine.

To further clarify: “a unit of functionality” means some set of related abilities of a system, like a bunch of document transformation code, or ways of processing credit cards, etc. “better than 10% chance” is a totally off-the-cuff WAG (wild-assed guess). “alien machine” means alien in the “not this machine” as well as the “foreign os/platform/vm” senses.

Because the definition of a service says that it represents functionality to be called from somewhere else, and since conventional wisdom about distributed application calls has already settled into advanced rigormortus stage, the transitive property of technical definitions applies and our definition of “service” implicitly includes the notion of highly granularized access levels to our functionality and the minimization of round trips and tight coupling to type systems, runtime support, or stateful connections.

There’s no need to make “services” out of library calls that will only be accessed by local or semi-local code. Likewise, if the functionality has a pretty good chance of being accessed by an alien, you’d better make it a service.

Ted, what’s missing from this definition?

Don’s been running with this meme started by Ted Neward about how OR/M frameworks are like the Vietnam war: tons of wasted resources and no clear exit strategy. Don has posted several times about this, clearly coming down on the side of the anti-OR/M folks. One of the reasons is that there are so many frameworks, so many developers chasing the same goals, throwing resources after the same problems, butting up against the same laws of diminishing returns.

Which is why I don’t understand how the fall of the JDO 2.0 spec in the JCP is a “victory”. The JDO 2.0 spec would have standardized the platform and, I think, brought the overall number of competing frameworks down somewhat. As the big JDO suppliers (both commercial and opensource) solidified around an accepted standard, there would be fewer and fewer open source OR/M frameworks springing up all the time. At the very least, the big boys would have a central sandbox to play in. Without the endorsed spec, we are left pursuing a lot of individual agendas and waiting to see what happens when EJB 3.0 finally makes it onto paper.

What I’d really like to see is the JDO 2.0 spec win the reconsideration ballot and get some real community momentum behind its various implementations, which would in turn keep the pressure on the EJB 3.0 team to create a workable replacement for CMP (or, more preferably, just a plugable facade behind which we can place whatever already working data layer we want).