For the sake of brevity I’ll assume you’re familiar with the full description of the “Safari shell脚本执行” exploit publicized Monday by Heise Online.
The trick here is that when you use the Finder’s Get Info window to assign a custom application with which to open a particular file, the Finder stores this information in a resource of type ‘usro’ that it adds to that file’s resource fork.
如果您安装了Mac OS X开发人员工具，则可以使用
从任何您知道没有资源分叉的文件开始Let’s say it’s named “testfile” and it’s on your desktop.
Get Info on that file using the Finder and change the “Open With” application to any other app than the default for that file.
/ Developer / Tools / DeRez~ / Desktop / testfile
The output should show that the file now has a resource of type ‘usro’, and, if you look at the data of the resource, it begins with the full path to the application you chose to open the file with.
This feature has nothing to do with type and creator codes — which, contrary to popular misconception are not stored in resource forks, but are stored as HFS Plus metadata, just like the file name and modified and created datesIn fact, despite the fact that it uses the resource fork for storage, it has nothing to do with the classic Mac OS此Finder行为始于Mac OS X.
Normally, files are associated with a default application by means of either an HFS creator code, or by their file name extension(And where by “default application” I mean the app that opens the file if you simply double-click it.) Creator codes have higher precedence than file name extensions, which means that, for example, you can have files with “.html” extensions map to your favorite web browser by default, but have “.html” files you’ve created yourself open by default in your favorite text editor by saving those files with the text editor’s creator code.
However, when you assign a custom “Open With” application in the Finder, this choice trumps all othersIf you use the Get Info window to, say, specify that a particular file should open in Terminal by default, this choice is binding no matter what the file’s creator code and file name extension say.
And so that’s what is being exploited with the “Heise.jpg” example fileIt doesn’t have a creator code, and the file name extension is “.jpg”, but the file also has a ‘usro’ resource specifying that the file should open in Terminal — or, specifically, with/Applications/Utilities/Terminal.app, which is why some people are recommending that you move or rename your copy of TerminalIf you change the path to the Terminal.app bundle, the ‘usro’ bundle will no longer work(I do not recommend this, however, because moving or renaming Terminal might cause conflicts with future updates from Apple — and who’s to say there aren’t other apps that can be taken advantage of similarly?)
When Safari downloads a zip archive containing such a file, and Safari’s pref setting to “Open ‘Safe’ files after downloading” is turned on —因为它是默认的— what happens is that Safari looks at the expanded “Heise.jpg” file, sees that it doesn’t have a creator code, looks at the file name extensions and decides that “.jpg” is a “safe” file extension, and, so, it opens it.
在这种情况下，文件扩展名是谎言The file is not, in fact, a JPEG image这是一个shell脚本And so when it is “opened”, it’s opened by Terminal because of the ‘usro’ resource, and the shell script is runBecause “Heise.jpg” is a harmless proof-of-concept exploit, not a genuinely harmful Trojan horse, all it does is print the contents of your home folder and a few lines of text to the Terminal.
A harmful exploit using this very same technique could do just about anything to and with the entire contents of your home folder, however这不是一个他妈的玩笑But nor should you be overly concerned: if you turn off Safari’s “Open ‘safe’ files after downloading” preference — which I’ve recommended ever since the两年前启动服务imbroglio— you’re safe, unless you download such a file and open it manuallyAnd if you use Camino or Firefox instead of Safari, you’re safe, too(This is probably true for all browsers other than Safari, but I haven’t tested any others.)
There are a couple of things Apple could do about this (and these options are not exclusive):
Get rid of Safari’s “Open ‘safe’ files after downloading” preferenceAt the very least it should be turned off by defaultDoing this would not only stop this particular exploit, but it would also cut off any future exploits from taking advantage of holes in the “safe files” algorithm.
If Apple had gotten rid of this preference two years ago, we wouldn’t be having this discussion now.
Greatly restrict what constitutes a “safe” file to a short list of known archive formats like zip files and disk images, and only pass such files off to the system’s default helper applications.
Change the implementation and format of the ‘usro’ resource such that it only applies to the user account used to create it. I.e所以，如果一世decide to open “testfile.jpg” with Terminal, it only applies to my user account, and so if I send the file to you, my custom “Open With” setting will be ignored when you open the file.
This would be an inconvenience for people who use the same file on multiple machines and who想these custom bindings to apply across machinesIt’s an issue of balancing convenience versus security.
This entire exploit falls under the same category as a number of other possible Trojan horse techniques where you make an application or script看起来像an innocuous file by giving it a custom icon and a non-application-looking nameExcept in this case, it’s not a fake icon pasted on the file, but instead, a “real” icon that Launch Services applies based on the file name extension.
So one problem is that while ‘usro’ resources have the highest precedence when determining which app will open a file, they have no bearing on the icon used to represent the file但是，Finder不use this info when determining the file’s “kind”; here’s how it represents the “Heise.jpg” example file in column view; notice that it displays the file’s kind as “Terminal.app document”:1
But this is only a slightly different problem than that of custom icons pasted on applications so as to disguise them as innocuous documents — look no further than last week’sOompa Loompa Trojan horse。
It boils down to this: you can’t safely double-click files from untrusted sources,而你永远不可能This is no different today on Mac OS X 10.4 than it was a decade ago on Mac OS 8 and 9.
Apple should consider addressing this in the Finder, by, say, adding some sort of visual treatment周围application icons, which would provide some measure of warning for malware apps posing as documents — if there were some sort of halo around applications and you saw such a halo around a malware app posing as a JPEG, you’d have a visual indication that it’s not really a JPEG.