Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts published in March, 2006

Well, who’d have thought it. Custom icons are now a security risk, and in fact always have been, since the first Macs came out!

Just look here:

It is now still possible for hackers to construct a file that appears to be a safe file type, such as an image or movie, but is actually an application, they said…

Apple acknowledged that, despite its patch, it is still possible to make a malicious file look innocent.

and here:

However, the new “download validation” – which warns users that the file may be malicious – does not completely solve the widely touted, ‘extremely critical’ Mac OS X zero-day exploit that allows hackers to disguise malicous [sic] files as routine files, thus allowing Safari browser or other internet application to automatically unpack and execute the file.

and here:

The unresolved vulnerability is due to a problem with the Mac OS Finder, the component of the operating system used to view and organize files, […] said. The operating system assigns an identifying image, or icon, for a file based on the file extension. However, it decides which application will handle the file based on information that is stored separately from the file, called metadata…

…the problem has nagged Apple for years, yet it has not been fixed. “This vulnerability derives from the exact same flaw deep inside the OS that should have been addressed by Apple several times in the past two years.”

Yes, all this refers to custom icons, a facility introduced by the Finder since its very early releases, and which was much used (many would say over-used) in the Classic days to “customize” one’s system.

Now, it seems, custom icons have gone from being an innovation to an “extremely critical zero-day exploit”. icon_lol.gif

Also, apparently, this unsettling misfeature has appeared only “in the last two years” instead of being in place since, at least, 1990, and Apple should have done something about it as soon as it appeared – a hacker’s conspiracy, no doubt.

The last quote above (for the quoted expert’s sake, I hope he was misquoted by a clueless journalist) also repeats the widely held myth that Mac OS X only considers the file extension for obvious functions and that other, more obscure, functions are affected by the mysterious “metadata” (or sometimes it’s the other way around?), which nevertheless were wrongly implemented by the clueless newbie programmers that apparently are entrusted by Apple to write the OS’s most critical layers. Hah. By implication, it also asserts another myth, namely that custom icons – which are a type of “resources” – are stored in those eldritch metadata. Double hah.

In fact, it goes like this. Files on Mac OS X, as they were on Mac OS Classic, can contain unstructured data (in what is called the “data fork”), as well as unstructured data (in what is called the “resource fork”) as well as metadata, which is to say, data describing the file or its contents (in what is called the “directory”). In contrast, most other operating systems have only unstructured data, so there’s no concept of separate “forks” for a file, and they also usually have less varieties of metadata. So this confusion often affects people not familiar with the details of the Mac’s file system.

So, when the Finder displays the icon for a file it doesn’t check only the file extension (if any). It also checks various metadata – some of which can even cause the extension to be ignored – to index into a database of existing applications, and from that loads the appropriate icon to display. However, this icon can be overridden for a particular file by assigning a custom icon to it, which is stored in the resource fork and whose presence is announced by a flag in the metadata.

Now, application and document icons are usually assigned to minimize confusion as to what that particular application or document does or contains. As soon as custom icons were invented, we could occasionally see custom icons designed to cause confusion instead – usually as a prank, sometimes to implement special functions, even more rarely maliciously.

Still, assigning a malicious icon only affects the file’s icon itself as displayed by the Finder’s icon view (does anybody still use that?). The Finder’s information panes still show the correct file type, and everybody should check that as a matter of routine before double-clicking on any icon in the Finder. (Does anybody still do that? Apparently yes. I offer Zingg! as a more secure alternative.)

Still, the sky is not falling. Falling prey to a custom icon disguising a malicious application as a warm, fuzzy well-known document would apparently affect people who install and run everything as “root”, or as an administrator, turn most warnings and safeguards off, then ignore the message that this application is being run for the first time, then blithely furnish their administrator password when solicited. No doubt there’s a surfeit of such people, but should they run a computer unsupervised..?

So, the suggested solutions range all the way from the not-very-useful but popular “Apple should get a clue” to the radical “disable all custom icons forever”. I think a more of middle-of-the road approach would be best. There should be a Finder preference to show custom icons or not, and perhaps applications with custom icons should have a little “app” badge in one corner. I suppose this would be easy to implement with some hackery. Pity I’m too busy right now…

Well, here I’m plugging away at XRay II and making reasonably good, if at times uneven, progress.

People ask now and then how I work. Just now I was reflecting on how, sometimes, reams of code get turned out on one day and then almost nothing on another day. Or how, sometimes, many parts are changed or refactored, while at other times updates are confined to a single routine or source file…

It may just be true for my style of programming, but I now see the process resembles very much the way a Mandelbrot Set is plotted. I start out with an empty project and iterate over everything repeatedly, adding a handful of code at a time, zooming in on as much details as is needed, then zooming out again to recheck the broad outlines, then zooming in again elsewhere.

I never manage to plan ahead how it will work, except for having a broad idea of what I want to do, and often I need to change direction radically at some point, either in fine or broad detail. Sometimes I need to take off for hours or days (or even months, as was the case for RBSplitView) to investigate a possible solution. I spent a couple of months learning about WebKit to format my information, only to run into trouble on some details and abandoning it again.

Then, of course, there are phases where it seems necessary to refactor some stuff that’s already done, either to make it smaller, more elegant, or just nice to look at – even if nobody else ever sees this code. It makes for slow progress sometimes, but the results are usually very satisfactory.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2024 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.