特別編 Safariの脆弱性に学ぶBAHとusroリソースの働き：Undocumented Mac OS X（2/3 ページ）
今回は、いつもの連載から少し離れ、2006年2月に発表された、Safariの外部から送り込まれたシェルスクリプトを自動的に実行してしまう脆弱性について考えてみたい。
“安全な”ファイルを開く
次に挙げられるのが、Safariの「“安全な”ファイルを開く」機能だ（図2）。これは本来実行されるコードを持たない「“安全な”ファイル」をダウンロード完了時に自動的に開くことで、いちいちファイルを展開したり開いたりする手間を省くというものだ。自動的にファイルを処理することから、以前からこの機能には批判があり、セキュリティに敏感なユーザーはチェックを外して機能を無効にしていることが多い。しかし、デフォルトではこの設定は有効になっており、初心者ユーザーを中心にそのまま利用している者が少なからず存在する。
usroリソース*
そして最後が、「usro」リソースだ。前回のコラムで述べたように、Mac OS Xは拡張子やMIMEタイプ、ファイルタイプといった、ファイルに付随する情報を基にその形式を表すUTI（Uniform Type Identifier）を推定、UTIに適したアプリケーションを起動する。なお、UTIに対応するアプリケーションはアプリケーション自身の定義（Info.plist）に書かれた情報をデフォルトに、Finderの「情報を見る」パネルからユーザーが自由に切り替えられる。
少々話は変わるが、Mac OS 9までの旧Mac OSではファイルタイプとクリエータが絶対の存在であり、ファイルをダブルクリックするとそのファイルに記載されたクリエータに対応するアプリケーションが必ず起動された。このため、同じHTMLファイルでも、あるファイルはNetscape Navigatorで開き、別のファイルはInternet Explorerで、さらに自身の編集しているHTMLファイルはPageMillで開くといったように、ファイルごとにクリエータを変えていくことでそれぞれ別のアプリケーションを起動させることができた*のだ。
Mac OS Xになってからというもの、主に旧来の口のうるさいユーザーがそうしたささいな優位性からファイルタイプやクリエータを偏重し、ほかの情報を排除する意見が何度となく語られた。発想自体は時代錯誤だが、確かに特定ファイルだけはファイル形式で規定されるアプリケーションとは別のもので開きたいという要望には説得力がある。Appleの開発陣もそう考えたのか、usroリソースによる起動アプリケーションの制御の機能がひっそりと搭載された。
usroリソースの中にはアプリケーションのパスが記録されている（実行例1）。usroリソースを持つファイルがダブルクリックされた場合、標準の関連づけによるアプリケーションではなく、このusroリソースに記録されたアプリケーションがそのファイルを開くアプリケーションとして選択される（図3）。
図3 特定のファイルに限って通常とは別のアプリケーションで起動させたい場合は、usroリソースが使われる。LaunchServicesはusroリソースの中に格納されたアプリケーションへのパスを利用し、UTIで指定されるアプリケーションとは別のアプリケーションを起動する
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このページで出てきた専門用語
usroリソース
usroはUser Overrideの略だといわれている。
それぞれ別のアプリケーションを起動させることができた
Mac OS Xと違い、Mac OS 9の標準機能では、ファイルに記載されたクリエータを書き換える手段は提供されていなかった。つまり、ファイルをダブルクリックしたときに起動するアプリケーションを標準では変更できなかったのだ。どうしても変更したい場合は、いったん別のアプリケーションのメニューから［開く...］を選んで読み込み、別ファイルとして保存するという面倒な手続きを取るか、いわゆるフリーソフトに頼るしかなかった。標準でクリエータの書き換え機能が提供されなかったことから、クリエータを操作することで別アプリケーションを割り当てていたのは少数の玄人ユーザーが中心であり、Macの標準的操作とはとうてい呼べなかった。
Copyright © ITmedia, Inc. All Rights Reserved.