According to an official “Technical Details” document, when OSX.Macarena is executed, it performs the following actions:

1. Infects other files when they are executed in the current directory, regardless of file name or extension.

Let us get some context in here. Let me quote something from one of my old writings on Unix viruses:

Well, Unix viruses are hardly new. Fred Cohen, who pioneered the formal definition and study of computer viruses, implemented a Unix virus in 1983. The virus ran on a VAX 11/750 system. Dennis Ritchie, one of the inventors of UNIX, had the following to say about Unix viruses:

Does that sound familiar? This was in the late 1980s.

In reaction to a similar controversy as we are talking about now, I wrote a portable “Unix virus” as a trivial C program many, many years ago. I called it the Jingle Bell Virus since I wrote it in the Bell Labs cafeteria at Murray Hill, NJ. Jingle Bell attaches itself to the first executable found on the command line. Of course, you can configure the infection scheme to whatever you want. You can read Jingle Bell’s source code and also “see it in action” on the following page:

• Viruses on Unix: Jingle Bell: A Simple Virus in C [kernelthread.com]

Somebody has even trivially ported Jingle Bell to the Plan 9 operating system. You can find it in one of the contrib subdirectories within the Plan 9 source distribution. You can just as easily port it to Mac OS X (by “easily”, I mean change the value of the constant V_OFFSET in the code and recompile—that’s it).

What this newborn Mac OS X virus essentially demonstrates is merely a manifestation of how operating systems work. Portraying this as a newly found threat is just not right, at least if you do so without clarifying that this is how operating systems work; you can do this on any operating system in general; you could do this on ancient UNIX; the real threat is not every such individual program but flaws that might allow such malware to spread; and so on. And no, the fact that this particular one does its job by mucking with Mach-O structures doesn’t justify the terror alarm. What’s next? Saying that “Mac OS X allows sensitive information to be leaked (because you can read files on Mac OS X)”? Wouldn’t it be far more worthy and worthwhile to point out and address real vulnerabilities in Mac OS X?

To be fair, if there indeed is no FUD involved and the parties involved are truly well meaning, now that I’ve made Jingle Bell public (well, I made it public many years ago and the relevant page has been accessed hundreds of thousands of times), shouldn’t it also be on the anti-virus lists for all operating systems it can be compiled on? While we are at it, we should also read all relevant academic papers and include any viruses found therein too.

It should not be any harder to write a virus for Unix (and Mac OS X) than it would be for any other system. However, spreading a virus would have different logistics on Unix as compared to, say, Windows. Given the default usage scenarios (note that I’m not saying design or architecture) of Windows and Unix, it is generally harder to spread such things on Unix. That said, Mac OS X does have some potentially very troublesome aspects. (Think about what an admin user on Mac OS X can do—by default—in terms of file permissions.) So, I am not saying everything is rosy and wonderful for Mac OS X. Please be wary of that creeping smugness.

Rather than repeat many other details here, let me refer those interested in the history and nature of digital life forms to some more things I have written in the past:

• Digital Life: Viruses [kernelthread.com]
• Digital Life: Worms [kernelthread.com]
• Viruses on Unix [kernelthread.com]

All these are sections within the following bigger document:

• A Taste of Computer Security [kernelthread.com]

Besides these, there is an abundance of academic papers and articles on computer viruses and worms. Just search.

The accompanying website (osxbook.com) of my forthcoming book (Mac OS X Internals) is up. Although the site is preliminary at the moment, it has useful information related to the book. In particular, a detailed table of contents is available for browsing.

osxbook.com also has a blog, which will eventually cause this blog to retire. In fact, all new Mac-OS-X-related material will only appear on osxbook.com. The existing material on kernelthread.com will remain, but will be obsoleted by osxbook.com’s material over time.

Finally, many readers of kernelthread.com have expressed dissatisfaction in the past about the disappearance of kernelthread forums. Well, osxbook.com has its own forums, which will serve as a venue for discussing topics related to the book and Mac OS X internals in general. The forums are now open for registration and discussion.

I hope to be able to say “done” in a matter of days now, if you know what I’m talking about.

I know the motion sensor software doesn’t work on Mac OS X 10.4.2 (it’s related to the OS version, not to whether it’s an iBook or a PowerBook). The integer ID of the function used for retrieving acceleration values has changed, so the fix is trivial. I still haven’t found the time to do it.

The kernelthread forums are down… the unceremonious shutdown is rather unfortunate, but there was a spam incident one day and somebody human was signing up like crazy. I temporarily took them offline and forgot to bring them back. They will resurface eventually on www.osxbook.com.

One more thing: some news coverage on the Assured eXecution Environment (AxE) for Windows and Mac OS X. I can’t say anything that’s not already public about AxE here, but I would like to point out a rather important aspect of it: it is not a white/black listing mechanism.

This should be of particular use to those who are interested in a Linux driver for the ThinkPad accelerometer. Although Mark is not permitted to release any source code yet, he can describe how things work. It should really be trivial to follow his description to create a functional Linux driver.

Here is the relevant discussion and the download:

A File System Change Logger For “Tiger”

I think this is a pretty exciting update, even for something as unexciting as a “debugger”. The following primary changes have happened:

1. hfsdebug now understands and displays the on-disk raw structures corresponding to HFS Plus extended attributes.
2. In particular, hfsdebug can process Access Control Lists (ACLs) from scratch, and can display both the corresponding low-level data as well as the high-level semantical representation of that data.
3. The old hfsdebug had a problem right from the very beginning: the problem showed up rarely, and was reported to me a handful of times within the last year. In the user-visible manifestation of this problem, hfsdebug would complain that it could not process a volume because a B-Tree node size was unacceptable (for example, too large). I think this is fixed now (but please let me know if you run into this again). The issue was that I had a particular block number calculation where a 64-bit result was expected, but because of a missing cast, the result was being truncated. Thus, whenever a B-Tree’s starting point was above the 4 GB boundary (not very common in practice), hfsdebug would look at the wrong data thinking it’s a B-Tree header. For those using Panther, hfsdebug-1.18 should fix this problem.

Note: This is a beta version. I say “beta” not as in “it would want to eat your disk” (this is a read-only debugger), but as in “it may be erroneous in its processing or displaying”. I’ve only spent about two hours updating it, and things look in order at the moment. Looks can be deceiving though! I would appreciate all bug reports.

Result and Report: The Mac OS X Expert Challenge 2005.1

1. Operating System Internals
2. Security

My goals for this endeavor are the following:

• Probe popular interest in system-level Mac OS X topics. Knowledge of such interest is currently valuable to me as I am creating a book on such topics.
• Gauge the inquisitiveness and initiative of the Mac OS X community based on
  the kind of response generated.
• Use the outcome to roughly quantify Internet-wide Mac OS X expertise outside
  of Apple.
• Facilitate sharing of Mac OS X knowledge.
• At the very least, provide an interesting problem for some people to solve.

The Mac OS X Expert Challenge 2005.1

In a pinch, the Linux-based technology “transforms” a personal device, such as an MP3 player, a USB pen, or even a cell phone, into a powerful “Rescue and Recovery” device that can be used for things such as:

• Booting a PC “from” the personal device
• Accessing data from the PC’s unbootable drive
• Accessing specific backups located on the personal device
• Providing an emergency productivity environment (e-mail, Lotus Notes, web, …), even if the PC’s drive is completely dead
• Rebuilding the PC’s drive
• More …

An iPod mini was used in the PartnerWorld demonstration.

I think it’s cool because we are packaging all this functionality into personal devices that people won’t find a chore to carry around, and in many cases, already carry around. Moreover, the original purpose of the personal device is unaltered. For example, if it’s an MP3 player, it will remain so.

I’ve seen the software been described as “IBM One-touch Rescue & Recovery On Linux” in the press.

Some relevant links [updated]:

TechWorld Coverage
Breaking News @ CRN | IBM Software Performs BSOD Rescues
Webcast Containing the Demo (the demo is approximately 25 minutes into the webcast)

Three complete (though prototypical) examples are included: Towers of Hanoi (textual) for EFI, Towers of Hanoi (graphical) for Open Firmware, and creation of a mouse-draggable window for Open Firmware.