In the early 1990s, there were many excellent printed Mac magazines, including the high-end and expensive MacPublishing, aimed at the flourishing Desktop Publishing market. This featured a cover disk – an important asset in the days when there was essentially no distribution of software online. One issue in about 1990 came with a special free feature, a virus known as Wdef.

Wdef was a highly successful virus which infected a great many Macs at the time. It was innovative because it was the first malware for the Mac which used not executable code files but came in what’s now known as an extended attribute (xattr). At the time, these were known as resources; in this case, the malware posed as a ‘window definition’, then present in every Mac app and in many other files. Being a resource, it was hidden from conventional anti-virus tools, and from Mac OS itself.

Fast forward thirty years, and Phil Stokes of Sentinel Labs has just reported what’s believed to be the first malware to affect macOS which uses the same trick: it hides in what we now call a com.apple.ResourceFork extended attribute containing a resource of type icns, an icon suite, another reminder of the days of Classic Mac OS. I’m surprised that it’s taken so long, and interested that whoever is delivering what looks like a Bundlore variant chose to use that type of xattr. Are we about to see more malware come in xattrs?

Xattrs have long been a very effective way of malware flying under the radar. To demonstrate their potential, try adding some xattrs to the executable code in a notarized app and checking its signature. I took a copy of my app LockRattler, which is signed to the standards required by Big Sur and notarized by Apple without any xattrs. Using my free utility xattred, I added a xattr of custom type co.eclecticlight.test3 and an old fashioned resource. Each addition amounted to 80 KB of binary which was actually an old icns resource, just as used by the new malware reported by Phil Stokes.

macOS Catalina doesn’t notice those substantial additions. The doctored app flies through full first run checks and clears quarantine without a problem. Signature checks are also fine, even though the executable code in the app now has 160 KB of potentially malicious binary attached to it.

The reason for this is that much of macOS still ignores xattrs. Finder doesn’t include their size when it reports the size of any file: to see that, you’ll have to use a utility like my free Precize, which lists xattr size in full. The cdhashes used to check the integrity of signed bundles exclude everything stored in xattrs, as a result of which you can do anything you like in the xattrs of files inside bundles without affecting their signatures.

Not only is macOS blind towards xattrs, it actually relies on this blindness for its own security. Quarantine flags are xattrs which are attached to all the files within a bundle that has been downloaded from the Internet. If adding those xattrs to the contents of the bundle broke the bundle’s signature, quarantine could never work.

So if xattrs are such a good way of flying under the radar, why aren’t they used by more malware?

Perhaps the biggest reason is that they’re a powerful way of smuggling code onto a Mac, but not such a good way of being able to execute that code. In Phil Stokes’ analysis of this new malware, he reports that this resource is simply a compressed payload which has to be decompressed to storage before it can be used. Simply loading a xattr into memory and executing it is something made difficult in the layered security deployed in recent versions of macOS, and you’ve still got the problem of getting the loader code there in the first place.

Xattrs also aren’t always reliable means of moving anything around anyway, and this is where I’m puzzled at the choice of a classic resource in this instance. Xattrs of type com.apple.ResourceFork are among those most frequently stripped when files are moved around, and don’t normally survive passage through iCloud, for example. If you really want to do the job properly, it would be more robust to use the inbuilt mechanism for marking a xattr for preservation by appending flags to its type name.

There are plenty of other types of xattr which could readily accommodate large chunks of malicious code, but there’s another danger for those tempted to try. While most code traps errors in the data it reads, xattrs are often used with minimal checking for errors. Repurposing an existing type of xattr for a malicious payload could readily cause warning signs of other apps crashing when trying to access that xattr, which was one of the best indications of infection by the original Wdef virus. So a malware author would be far wiser using a custom xattr type instead.

Unlike a well-known xattr type such as com.apple.ResourceFork, that would in turn make their smuggled code more easily detected, provided that anti-malware protection went to the trouble of looking for suspicious xattrs. That’s probably the biggest lesson here: for anti-malware detection to be reliable on macOS now, it can’t afford to be as blind to xattrs as in the past, something we learned thirty years ago with Wdef. That applies most of all to Apple’s malware scanner used to check apps submitted for notarization.

Postscript

Thanks (as so often) to @rosyna for pointing out that resource forks are different from regular xattrs in various ways, some of which may be relevant to their (ab)use in malware. Technically, the com.apple.ResourceFork xattr access to them was seen as a convenience for compatibility with the more recent system of xattrs. However, apart from providing an additional API which gives access to them as resources, there don’t appear to be any practical differences now in APFS.

@rosyna considers that, because this particular dropper can be detected, this is just another use of steganography to hide a more malicious payload in a malicious binary. Thus resources and extended attributes aren’t a vulnerability, and that “there’s no new risk here.”