<div id="popup_box_thanks" style="display:none" onClick="close_popup_thanks('popup_box_thanks', 'ts')"><br>Thanks for submitting your tip! All submissions are moderated by an editor before appearing online. We've reset the form so you can enter another tip. Or you can close the tip submission box. <div class="x_close" id="thanks_upper_right"><a href="javascript:void(0)" onmousedown="close_popup_thanks('popup_box_thanks', 'ts'); return true;">Close</a></div></div>
<div class="tbf_row"><div class="tbf_wide_extra_top not_bold">Please submit only technical tips that will help other TidBITS readers better use their Macs, iPhones, and related software and hardware. All product announcements should be sent to <a href="mailto:releases@tidbits.com">releases@tidbits.com</a>.</div></div>
<div class="tbf_left">URL</div><div class="tbf_right"><input type="text" value="" name="tip_link_url" tabindex="3"><span class="tip_description"><br>Enter the URL to a Web page that supports your tip.</span></div>
</div>
<div class="spacer"></div>
<div class="tbf_row">
<div class="tbf_left">Linked text</div><div class="tbf_right"><input type="text" value="" name="tip_link_label" tabindex="4"><span class="tip_description"><br>Enter the name of the page linked above.</span></div>
<div class="tbf_wide"><input type="submit" value="Preview Your Tip" name="preview_tip" onClick="fill_preview('tipbits_enclosure_preview', 'ts', this.form); return false;" tabindex="7"> <input type="submit" value="Send Us Your Tip!" name="submit_this_tip" onClick="handle_tip_submission('ts', '', this.form, 'tip'); return false;" tabindex="8"></div>
</div>
<div class="spacer"></div>
<div class="tbf_row">
<div class="tbf_wide"><span class="fine_print">When you submit a tip, you give us permission to use it. Read <a href="javascript:void(0)" onClick="generic_show_hide('tip_terms')">our terms</a> for more details. All submissions are reviewed before publication.</span></div>
<div class="tbf_wide"><span class="fine_print">Our terms: By submitting a tip, you agree to assign TidBITS Publishing Inc., a non-exclusive, worldwide, perpetual license to reproduce, publish, and distribute your tip in connection with the TidBITS Web site and associated products in any media. You agree that you created the content you submitted, and that you have the right to assign us this license. You give us permission to use your name, but your email address won't be publicly displayed or shared. We review all submissions before publication, and reserve the right to select which submissions we feel are appropriate for our readers and to edit those we publish.</span></div>
<div id="comment_thanks" style="display:none" onClick="close_popup_thanks('comment_thanks', 'comm')"><br>Thanks for submitting a comment! Please check your email for a link that, when clicked, will verify that you're a real person and cause your comment to appear immediately. <div class="x_close" id="comment_upper_right"><a href="javascript:void(0)" onmousedown="close_popup_thanks('comment_thanks', 'comm'); return true;">Close</a></div></div>
<div class="tbf_wide"><span class="fine_print">Our terms: We reserve the right to edit or delete any comment, so please post thoughtfully. We use your email address <i>only</i> to send you a one-time verification message confirming that you posted this comment. We also store your address to allow you to verify using other Web browsers in the future. For more info, see our <a href="http://db.tidbits.com/privacy.html">privacy policy</a>.</span></div>
<li><a href="/feeds/tidbits.rss" title="Subscribe via RSS" class="gettb">RSS <img src="/images/feed-icon-12x12.gif" width="12" height="12" border="0" class="nav_img" alt="Subscribe via RSS"></a></li>
<li><a href="http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=276986548" title="Subscribe to the podcast" class="gettb">Podcast <img src="/images/feed-icon-12x12_podcast.gif" width="12" height="12" border="0" class="nav_img" alt="Subscribe to the postcast"></a></li>
<li><a href="http://www.twitter.com/TidBITS" title="Get Article Updates via Twitter" class="gettb">Twitter <img src="/images/feed_icon_12x12_twitter.png" width="12" height="12" border="0" class="nav_img" alt="Get Article Updates via Twitter"></a></li>
<li><a href="http://www.facebook.com/pages/TidBITS/195314925519" title="Go to the TidBITS Page at Facebook" class="gettb">Facebook <img src="/images/feed_icon_12x12_facebook.gif" width="12" height="12" border="0" class="nav_img" alt="Go to the TidBITS Page at Facebook"></a></li>
<li><a href="javascript:void(0)" title="Sections" class="tabhead" onClick="return showhide('articleslist')">Sections <span id="articleslist_triangle"><img src="/images/nav_triangle_open.gif" width="9" height="9" border="0" class="navtriangle" id="articleslist_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="javascript:void(0)" onClick="return showhide('stafflist')" title="Staff" class="tabhead">Staff <span id="stafflist_triangle"><img src="/images/nav_triangle_closed.gif" width="9" height="9" border="0" class="navtriangle" id="stafflist_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="javascript:void(0)" title="Issues" class="tabhead" onClick="return showhide('issuelist')">Weekly Issues <span id="issuelist_triangle"><img src="/images/nav_triangle_closed.gif" width="9" height="9" border="0" class="navtriangle" id="issuelist_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<li><a href="javascript:void(0)" onClick="return showhide('abouttidbits')" title="About TidBITS" class="tabhead">About TidBITS <span id="abouttidbits_triangle"><img src="/images/nav_triangle_closed.gif" width="9" height="9" border="0" class="navtriangle" id="abouttidbits_tri_image" alt="Click to show or hide the contents of this section."></span></a></li>
<div class="center_top">Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling <a href="http://www.takecontrolbooks.com/?pt=TB-TAGLINE" style="color:yellow">Take Control</a> ebooks.</div>
<!-- begin centercolumn -->
<div id="centercolumn">
<!-- begin rightcolumn_container -->
<div id="rightcolumn_container">
<!-- begin rightcolumn -->
<!-- rightcolumn is embedded within centercolumn so featured text wraps around it -->
</div><!-- end tearoffbox_wide_container for watchlist items -->
<!-- begin tearoff box wide -->
<div class="tearoffbox_wide_container">
<div class="tearoffbox_wide_tips">
<div class="tip_display">
<div class="tips_sponsor_logo">
</div>
<h6>Arrange Icons on the iPhone/iPod touch Home Screens</h6>
<p><p>Unhappy with the arrangement of your icons? You can move them around as follows: First, hold down on any Home screen icon until all the icons wiggle. Now, drag the icons to their desired locations (drag left or right to get to other screens). Finally, press the physical Home button on your device. (Unlike earlier releases, iPhone Software 2.1 doesn't move just-updated apps to the end of your Home screens, so your icons should be more stationary once you've installed the update.)</p>
<p>Remember that you can replace Apple's default icons in the four persistent spots at the bottom of the screen with your four most-used apps!</p></p>
<p>Visit <a href="http://www.takecontrolbooks.com/iphone.html?14@@!pt=TBTIPS">Take Control of Your iPhone</a></p>
</div>
<div class="tearoffbox_wide_bottom_tips">
<div style="padding-bottom:35px"><div class="tip_display" style="float:left"><p><br><a href="/tipbits/77">Link to this tip</a></p></div><div class="tip_display" style="float:right; width:150px">
<div class="tbf_wide_80" id="hc_rc_7047">To help us avoid automated posts and misuse of our site, please enter the words below.</div><div class="x_close_row" id="hc_upper_right2_7047"><a href="javascript:void(0)" onmousedown="HidePopupContent('hc_7047', 'hc', '7047'); return true;">Close</a></div>
<div class="featured_meta"><div class="meta_article">27 Feb 2006 | <a href="/article/8437?print_version=1">Print <span class="shift_up"><img src="/images/printer_icon.gif" alt="Printer-Friendly Version of This Article" border="0" width="9" height="10"></span></a></div></div>
<div id="article_box_7047"><P>As a level-headed, rational reader of TidBITS, you have, I trust, resisted being swept away on the wave of fear, uncertainty, and doubt spread this past week with regard to the latest variety of Mac OS X security holes to gain wide attention (see Geoff Duncan's "Significant Safari Exploit Discovered," elsewhere in this issue, for more details). The mass media, not unexpectedly, have eliminated from their "reporting" all historical perspective and technical details in favor of block-busting headlines whose actual semantic content ("Mac OS X has viruses!") is on a par with an inarticulate scream. And then there are the usual fear-mongering press releases from self-interested companies. Let us, however, ignore the hype and consider the facts.</P><P><STRONG>Open Sesame</STRONG> -- Those facts mostly involve how documents and applications are associated in Mac OS X. When you look at a document in the Finder, it has an icon supplied by the application that opens it. When you double-click the document, that application is launched and opens the document. How is this association maintained?</P><P>Back in the days of Mac OS 9 and before, the answer involved metadata invisibly stored in the file system and looked up through an invisible database. When Mac OS X emerged, though, Apple set out to supersede this architecture with those obnoxious little file extensions that appear, visibly or otherwise, after a period in the name of the file, along with a complicated series of strategies for locating the associated application.</P><P><<A HREF="http://db.tidbits.com/article/05415">http://db.tidbits.com/article/05415</A>><BR><<A HREF="http://db.tidbits.com/article/06584">http://db.tidbits.com/article/06584</A>><BR><<A HREF="http://arstechnica.com/reviews/os/metadata.ars/8">http://arstechnica.com/reviews/os/metadata.ars/ 8</A>></P><P>Apple thus suppressed an elegant method of performing document-application associations, one that worked reliably (barring the occasional need to "rebuild the desktop" when the association broke down) and was invisible to the user, in favor of an ugly and often unpredictable system of incorporating a file's type into its name merely because that's how other operating systems do things. Except that they didn't completely suppress the earlier method; instead, they incorporated it into an uneasy Jekyll-and-Hyde alliance. For one thing, a file left over from the pre-Mac OS X days might well have no filename extension. So a file might have type/creator metadata, or a filename extension - or both.</P><P>But there's more. Consider the problem of a generic file type, such as .pdf. Both Preview and Adobe Reader can open a .pdf, so which of them should open this particular .pdf file? You, the user, might answer that question on a one-time basis by dragging the file onto the desired application's icon in the Dock or the Finder. But what if you wanted to <EM>assign</EM> the file to one application or the other, so that it would <EM>always</EM> open with that application when double-clicked in the Finder?</P><P>For reasons that aren't entirely clear to me, Mac OS X does not use the type/creator metadata to handle this situation. Instead, Apple instituted a slot in the resource fork - the 'usro' resource - where the user's custom file association is stored. Thus, when you use the Open With pop-up menu in the Finder's Get Info dialog, you're actually setting the file's 'usro' resource. It's possible for a file to end up with all three - a 'usro' resource and a metadata creator code and a filename extension.</P><P><<A HREF="http://db.tidbits.com/article/07516">http://db.tidbits.com/article/07516</A>></P><P><STRONG>Exploring the Exploitation</STRONG> -- The trouble, it turns out, is that it is possible to misuse these pieces of information to generate a conflict. Such a conflict lies at the heart of the current set of security exploits. When you download and expand the demonstration file created by Heise, what you end up with is a text file containing shell script commands; but the file has a .jpg extension and a bad 'usro' resource. The extension determines the document icon (on my machine, it is a JPEG icon that comes from Preview), but the 'usro' resource associates the file with a different application, namely the Terminal. You can tell that in fact this is a Terminal document by examining the file's Get Info dialog in the Finder.</P><P><<A HREF="http://www.heise.de/security/dienste/browsercheck/demos/safari/Heise.jpg.zip">http://www.heise.de/security/dienste/ browsercheck/demos/safari/Heise.jpg.zip</A>></P><P>The fact that this inconsistency is possible is probably a bug in the system. Theoretically, the system ought to be able to detect that the 'usro' resource is invalid. When I test the user creator-assignment mechanism, I observe that the file, along with a 'usro' resource, gets an 'icns' resource which is labelled "Binding Override" and presumably is intended to be the document icon from the newly assigned creator. For example, GraphicConverter's JPEG icon is different from Preview's JPEG icon. But Terminal has no JPEG icon, because it doesn't open JPEG files; and besides, the exploit needs Terminal to treat the file as text, not as JPEG. So the Heise file has no 'icns' resource, and this should alert the system that something's wrong.</P><P><STRONG>Stuff and Nonsense</STRONG> -- The fact that the exploit involves a .zip file, which is expanded on your computer in order to generate the invalid document, is irrelevant. True, the document is expanded by either StuffIt Expander or Apple's own application, BOMArchiveHelper; but these applications play no important part in the story, as they are merely reproducing, correctly, the bad file that was handed to them in the first place. It is also true that the .zip file, internally, is in a special format; but the same thing would apply to any file with a resource fork.</P><P>The role of Safari in the story should also not be stressed unduly. It is true that if Safari's "Open 'safe' files after downloading" preference is turned on (which, for many reasons, it should not be), Safari will effectively open the downloaded file twice - once to unzip it, and once to open what it wrongly thinks is a nice safe .jpg file. But this is no different, really, from what <EM>you</EM> would do with the file in the Finder by double-clicking the .zip file and then the .jpg file.</P><P>It has also been observed that Apple's Mail suffers from the same behavior as the Finder - that is, when this file is sent to you as an email attachment, Mail shows you a JPEG icon (as well as the .jpg extension), but opens the file in the Terminal if you double-click it. However, I'm fairly sure that this is the same behavior as the Finder's, merely being displayed in another context.</P><P>Finally, there has been some misleading talk with regard to the fact that the file in question is an executable - it is a shell script, and its executable permissions are set so that when it is opened by the Terminal the script runs. That there is such a thing as a double-clickable executable shell script is nothing new; any text file with a .command extension and executable permissions will run in the Terminal when double-clicked, and this has always been true. (You might reasonably argue that it shouldn't be true, and you might also not have been aware of the fact that it is true; that's a different issue, which I'll come back to in a moment.) And the fact that an executable can be communicated as a compressed file is nothing new either; were this not so, it would be impossible to send someone else a compressed application. Some reports have stressed the fact that the file has no "shebang" line, but that is a red herring; the exploit works equally well whether or not the shebang line is present.</P><P><STRONG>Conclusions</STRONG> -- My conclusion has two parts, and they both amount to an assertion that computer files, as Iago says of men, "should be what they seem, or being not, would that they might seem none."</P><P>In the first place, Mac OS X has never fully rationalized its complex scheme of document-application association, and now we see that there is in fact a bug in that scheme. Apple needs to get this straightened out, on the double, so that a file always looks like what it is.</P><P>Secondly, an executable, of whatever sort - from a Cocoa application bundle to a lowly executable shell script - is a very special kind of file, and it needs to be marked as such. Data that you read and code that you run are both files, but they are crucially different kinds of file; so executables should look and behave specially. Any file which, if merely opened, will itself run as code, should be "badged" in some prominent and suggestive manner. It might also help if the first opening of every executable were preceded by an alert. Apple did institute something like this after the URL scheme debacle, but they didn't go far enough - an alert appears the first time you launch an application by double-clicking one of its documents, but not the first time you open the executable itself - whereas the entire problem, as we now see, is that you might not even know that this <EM>is</EM> an executable. This, when Apple fixes things so that executables can't be disguised as JPEGs, will make the world a safer place.</P><!-- Of Files, Forks, and FUD Matt Neuburg --></div>
<!-- end article text -->
<!-- PayBITS -->
<p> </p><div class="sponsorbox">
<div class="sponsortext"><A HREF="http://www.usefulfruit.com/tb"><IMG SRC="http://db.tidbits.com/images/badges/pear-note-icon50x50.png" ALT="" HEIGHT="50" WIDTH="50" BORDER="0" ALIGN="left"></A>Pear Note 2: More complete, understandable notes on your Mac.<br />Typed notes are blended with recorded audio, video, and slides<br />to create notes that make more sense when you need them most.<br />Learn more at <<a href="http://www.usefulfruit.com/tb">http://www.usefulfruit.com/tb</a>>!</div>
