今回のエントリでは、「将来的にアップルはOSXにサンドボックスを搭載するらしい」という話から始まって、なぜか「セキュリティの問題がAndroid陣営にとって最大の悩みの種に発展するだろう」という予測で締めくくられている。マジデスカ！！というツッコミが筆者の脳内を駆け巡り、脳内でツッコミが醸成されてネタとなったので、その成分を精製して皆さんにお届けしたいと思う。
サンドボックスとは
サンドボックスの機能は特別新しいものではない。コンセプトとしては「プログラムがアクセス可能なコンピュータ資源、例えばファイルやネットワーク通信などを制限することで、プログラムが不正な動作をするのを制限する」というものだ。不正なプログラムを不用意にも実行してしまった場合や、実行中のプログラムが攻撃によって乗っ取られてしまった場合、サンドボックス内で動作していれば被害は限定的になるというわけだ。古くはJavaアプレットの実行環境などが代表的なサンドボックスだと言えるだろう。LinuxではSELinux、AppArmor、Tomoyo Linuxといった優れたサンドボックスの実装が存在する。サンドボックスは、強制アクセス制御（MAC: Mandatory Access Control）と呼ばれるセキュリティ技術のひとつで、従来の「superユーザー権限があれば何でもできる」というような任意アクセス制御（DAC: Discretionary Access Control）と併せて利用される。サンドボックスのポリシーで禁止された操作は、例えrootユーザーであっても実行することができない。例えばexec(2)で実行できるプログラムの種類が制限されたりする。これにより、superユーザー権限が不正に奪取された場合にも、被害の範囲を限定することができるようになる。
OSXはどう変わるか
中島氏が紹介しているForbesの記事が紹介しているA brief introduction to Mac OS X SandBox Technologyという記事で、OSXのサンドボックスについて割と詳しい説明がなされている。ここで中島氏のエントリに対してひとつツッコミを入れると、アップルがOS X 用のアプリにウィルスやマルウェアの混入を防止する仕組み（Sandbox）を導入するらしい。
というのは間違いであり、事実はサンドボックス機能自身はLeopard（OSX 10.5）から搭載されている。
ではアップルがこれから何を導入しようとしているのか？というと、それはForbesの記事で述べられているように、「Mac App Storeに並ぶアプリがサンドボックスに対応する必要がある」というものだ。これは「サンドボックスが導入される」ということとは、大きく隔たりがあるので注意が必要である。余談だが、OSXのサンドボックスはTrustedBSD起源だそうだ。
サンドボックス内のアプリには、どのようなコンピュータリソースへのアクセスが許可されるのだろうか。この点については、Forbesの記事で紹介されているWhy the Mac App Sandbox makes me sadという記事に詳しい。下記のリストは当記事からの引用である。（括弧内は筆者訳）
- Read-only access to the user’s Movies folder and iTunes movies（ユーザーのMoviesフォルダまたはiTunesムービーへの読み取り専用アクセス）
- Read/write access to the user’s Movies folder and iTunes movies（ユーザーのMoviesフォルダまたはiTunesムービーへの読み書きアクセス）
- Read-only access to the user’s Music folder（ユーザーのMusicフォルダへの読み取り専用アクセス）
- Read/write access to the user’s Music folder（ユーザーのMusicフォルダへの読み書きアクセス）
- Read-only access to the user’s Pictures folder（ユーザーのPicturesフォルダへの読み取り専用アクセス）
- Read/write access to the user’s Pictures folder（ユーザーのPicturesフォルダへの読み書きアクセス）
- Capture of movies and still images using the built-in camera, if available（搭載されたカメラによる動画または静止画の撮影）
- Recording of audio using the built-in microphone, if available（搭載されたマイクによる録音）
- Interaction with USB devices（USBデバイスへのアクセス）
- Read/write access to the user’s Downloads folder（Downloadsフォルダへの読み書きアクセス）
- Read-only access to files the user has selected using an Open or Save dialog（開くまたは保存ダイアログを経由したファイルへの読み取り専用アクセス）
- Read/write access to files the user has selected using an Open or Save dialog（開くまたは保存ダイアログを経由したファイルへの読み書きアクセス）
- Child process inheritance of the parent’s sandbox（子プロセスへのサンドボックス属性の継承）
- Outgoing network socket for connecting to other machines（他のマシンへの接続）
- Incoming network socket for listening for requests from other machines（他のマシンからの接続）
- Read/write access to contacts in the user’s address book（ユーザーのアドレス帳への読み書きアクセス）
- Read/write access to the user’s calendars（ユーザーのカレンダーへの読み書きアクセス）
- Use of the Core Location framework for determining the computer’s geographical location（コンピュータの地理的な所在地を測定するための位置情報フレームワークの利用）
- Printing（印刷）
パッと見て思うのは、挙がっている機能が非常に限定的なものだということだ。特に「MoviesとかMusicとかPictures以外のディレクトリへのアクセスはできないの？」というのは誰しもが疑問に思うのではないだろうか。この点については、この記事でも「プラグインをロードするのとかはできなくなるよね」とか「NASをマウントして使う場合には毎回Open/Saveダイアログが表示されるの？」ということが指摘されている。後者についてはWindowsのUAC以上の煩わしさが伴うことになるだろう。
「App Storeのアプリだけが対象だからパッケージを別途インストールすればいいんじゃね？」と思うかも知れないが、Forbesの記事で
“The next step,” says one, “is that end users will only be able to install things through the App Store.”
（筆者訳：次のステップはユーザーがアプリをApp Storeからしかインストールできないようにすることだ、と消息筋（笑）は語っている。）
と紹介されているように、そのような抜け道（？）も塞がれることになるようだ。とりあえず、全てのアプリをApp Storeからしかインストールできないようにするなら、サンドボックスで許可されるアクセス権限は緩和されるべきだろう。でなければ、iStat Menuesといった便利なツールや、ファイル管理ソフト、日本語入力ソフトというような、生産性を高めるソフトが尽く制限されてしまうからだ。アップルはユーザーがゲームしかApp Storeでダウンロードしないとでも考えているのだろうか。
このような「不便さ」という問題点はあるにせよ、セキュリティが高まることによってデメリットは相殺されると言うかもしれない。中島氏は
Windowsのようにアンチウィルス・ソフトウェアをインストールしないと安心して使えないパソコンなんてどう考えても時代遅れだ。
とまで言っている。これは裏を返せば「サンドボックスさえあればアンチウィルス・ソフトウェアは不要」と言わんばかりであるが、果たして本当だろうか？引き続き検証してみよう・・・というかサンドボックスの問題点を指摘していこう。
サンドボックス内でも攻撃が可能
プログラムがサンドボックスの限られたリソースしか利用できないからと言って、攻撃が全くできないわけではない。例えばインターネットへのアクセスとアドレス帳の読み取りが可能ならば、連絡先を全て抽出して悪意ある第三者へ送信することが可能だ。従って、そのような権限を要求するアプリのインストールには慎重にならねばならない。OSの脆弱性がなくなるわけではない
OSそのものに脆弱性がある場合、例えサンドボックス内で実行されているプログラムであったとしても、システムを乗っ取ったり変更を加えることが可能になってしまう。例えば「ｉＰｈｏｎｅ、ｉＰａｄのウイルス感染対策」というページでは次のようなPDF閲覧による攻撃の事例が紹介されている。するとｉＰｈｏｎｅ４が外部から操作されるようになってしまった。犯人が使うと想定したパソコンからアクセスすると、ｉＰｈｏｎｅ４に保存されたデータがすべて読めてしまう。デモではｉＰｈｏｎｅ４に保存されたメールを表示できるほか、撮影した写真もパソコンで読み取れた。さらに外部からのリモートコントロールで、電話をかけることができた。パソコンからコマンド操作で電話できるのだ。
PDFを開いただけでこのような操作が可能であれば、サンドボックスがあれども油断はできない。（注：iOSにはサンドボックスがある。）また、JailBrakeMeの存在についても言及されているが、JailBrakeMeはウェブページを経由してOSの脆弱性をついてシステムに重大な変更を加える操作である。JailBrakeのようなユーザーが望む効果をもたらすのなら害はないと言えるが、同じ脆弱性を付けばシステムにユーザーが望まない変更を加えることだって可能だ。ウェブページにアクセスするだけで攻撃が成立してしまうようでは、まったく油断はならないといえよう。
サンドボックス外で動作するプログラム
PDFの脆弱性やJailBrakeMe（Safariの脆弱性）から、ひとつの可能性が推測される。それは、プリインストールされているソフトウェアがサンドボックス外で動作している可能性があるということだ。アップル製のソフトウェアがサンドボックス外で実行されるなら、そこには以前と変わらないセキュリティの脅威が存在することになる。如何にサードパーティ製のアプリをサンドボックス内に閉じ込めて安全性を高めようとも、アップル自身のソフトウェアがサンドボックス外で実行されていては元の木阿弥であり、ウィルス感染のリスクは依然として残ることになる。もしアップル製のソフトウェアがサンドボックス外で実行されている、またはサンドボックス内だが特別な権限が付与されているという場合には、公平性という問題が浮上する。マイクロソフトはかつて自社製品において公開されていないAPIを使用しているということで申し立てをされたことがあるが、もしアップルが自社製品内だけに対してサンドボックス外で実行するという優遇措置をとれば同じような倫理的問題に発展することになるだろう。
ちなみに、サンドボックス外でプログラムが実行されるかも知れないという推測は、サンドボックス内でプログラムが許可される機能が非常に限定的なものだからだ。システムソフトウェアを実行するには全然足りない。本来は、Linuxで利用可能なサンドボックスのように全てのコマンドに平等に適用可能な実装が望ましいが、アクセスが許可されるリソースのリストを見る限りでは、そのような包括的なサンドボックスの実装ではないように思える。もしそうならサンドボックスとしては不完全なものであり、サンドボックスとしてのコンセプトが破綻しているとすら言える。
サンドボックス自身の脆弱性
筆者が本エントリを綴っている間に、次のようなニュースが飛び込んできた。動画：iOS に非署名コードを動かす脆弱性、発見者はApp Storeから除名
初代 iPhone 以来ほとんどのアップル製品に深刻な脆弱性を発見してきた「アップル 0-DAY 男」こと Charlie Miller 氏がまたやらかしました。今回ミラー氏が実演したのは、App Store で配布される一見無害なアプリを通じて外部から非署名のコードをダウンロード＆実行させ、任意ファイルの外部送信、マイクやスピーカーの利用など、iPhoneの全機能を操作可能にする内容。
サンドボックスも人が実装したものである以上脆弱性は存在する。サンドボックスがない場合よりは防御力は向上するかも知れないが、絶対安心というわけではないのだ。
審査はザルではないが不完全
さらに先ほどのニュースからの引用であるが、Charlie Miller氏は次のようなことを語っているらしい。隠し機能アプリはアップルとの契約で明確に禁止されているため当然ではありますが、当人いわく、実証アプリを実際に登録して見せた理由は、脆弱性について机上だけで発表しても、「まず隠し機能を持つアプリが審査を通らないから実現不可能だ」と言われることが予測されたため。
アップルによる審査は、隠し機能発見装置にはならない。この点は非常に重要である。「アップルが審査した≠安全」なのである。上記は開発者自身が攻撃の実証アプリを登録したものであるが、開発者が意図せずアップロード前にアプリがウィルスに感染してしまう可能性も考えられる。このような状況で審査を通過したアプリを信用してしまって良いのだろうか？
プロプライエタリソフトウェアだから検査し切れないのはある意味当然のことなのだが。
App Storeの脆弱性
さらに追い打ちをかけるように次のような情報も飛び込んできた。知らないうちにiPhoneにアプリが6個もダウンロードされてるんだが
2ch由来の情報なので真偽のほどは不明であるが、iTunes Store/App Storeとて人が作って人が運営しているものであるから完璧ではない。このような可能性は当然考えられる。（サイトがクラックされたり、運営者の中に不正を働く輩がいたり、パスワードが漏えいするといったリスクは当然ながら存在する。）
ちなみに、App Storeがクラックされてしまうと、登録されたアプリにウィルスを仕込んだり、悪意あるアプリがダウンロード可能な状態にするということも可能である。いくらアプリのインストールをApp Storeに限定したとしても、App Storeがクラックされてしまう可能性がある以上、「アンチウィルスソフトウェアなんてイラネ！」などと断言することはできない。
そうそう。App Storeのアプリにサンドボックス化を義務付け、さらにアプリのインストールをApp Store経由に限定してしまうと、皮肉にも「アンチウィルスソフトウェア」というのは開発することはできない。iPhone用にはVirusBarrierのようなアンチウィルスソフトウェアもあるようだが、これはメールの添付ファイルなどをスキャンするという限定的なもののようである。OSXでもサンドボックス化の義務付けが徹底されると、OSX用アンチウィルスソフトウェアの開発ができない（または限定的な機能しか提供できない）ようになる公算は高い。
Windowsの場合
中島氏が次のように発言しているので、Windowsについても少し調べてみた。マイクロソフトも同じような仕組みを Windows8 に導入するようだし、私としては大歓迎だ。
結論からいうと、新しいImmersive UI用アプリでは、iPhoneのようにApp Storeからしかアプリをインストールすることができなくなり、かつApp Storeのアプリはサンドボックス化が義務付けられる。ソースは次のページあたり。
既存のUIを使ったモードでは、サンドボックス化は要求されない。これは後方互換性を重要視するマイクロソフトらしい落とし所ではないだろうかと思う。
そして、既存のUIのアプリがサンドボックス化が必要ないなら、その部分については以前とウィルスに対する脅威は何ら変わらないことになり、中島氏の主張は成立しない。（一体何を歓迎しているのだろうか。）
余談ではあるが、Windowsにもすでにサンドボックス機能は存在する。MIC（Mandatory Integrity Control）という機能だ。MICではアクセス権が細かく設定されているわけではなく、レベルの低いアクセス権しか持たないプロセスが、より高いレベルのアクセス権を持ったオブジェクトへのアクセスが制限されるという実装になっているようだ。ちなみに、MICはVistaから搭載されており、Mandatory integrity control in Windows Vistaなどの解説が詳しいので興味があれば参照するといいだろう。
MICを適用したアプリとしては、Internet Explorer Protected Mode (IEPM)などが知られている。IEをIEPMで動作させれば、IEがクラックされても被害は限定的になるという寸法だ。果たしてiOSのSafariとIEPMではどちらが安全だと言えるだろうか。
（追記：ちなみに、MICとWindows 8のImmersive UI用アプリに適用されるサンドボックスは別物である。後者はLowBoxという名前の機能。）
Androidの場合
さて、中島氏のエントリで最後に槍玉に挙げられているAndroidだが、Androidにも当然ながらサンドボックスが存在している。Androidではアプリが要求する機能に対する許可をユーザーが確認するという実装になっているので、サンドボックスの存在はiOSよりもわかりやすいと言えるのではないだろうか。IPAの「Android OSを標的としたウイルスに関する注意喚起」というページでアクセス許可の警告画面が掲載されている。毎度おなじみのあの画面である。
また、当ページでは対策として次のような注意が呼びかけられている。
- 信頼できる場所からの正規版アプリの入手
- 「提供元不明のアプリ」設定のチェックを外しておく
- 「アクセス許可」に注意
- セキュリティ対策ソフトの導入
詳細は省略するが、Androidを利用している人はぜひ確認しておこう。
Androidは、サンドボックスの有無で言えばすでにOSXよりも先んじている。これからサンドボックスを搭載するOSXがセキュアになるというのならば、既にサンドボックスが搭載され運用されているAndroidだってセキュアであると言えるのではないか。しかしながら、なぜか中島氏によると
このままグーグルが何もしないと、来年あたりにはこのセキュリティの問題がAndroid陣営にとって最大の悩みの種に発展してしまう可能性が高いと思う。
ということになってしまうらしい。つじつまが合わないと思うのは筆者だけだろうか。
まとめ
以上、「Sandboxでウィルススキャンは不要になるか？」というテーマで技術的な検証を行ってきた。本エントリをここまで読んでくださった読者の方なら、答えはもう既にわかっていらっしゃるだろう。「No!!」である。その根拠として、本エントリで行った主張をまとめると次のようになる。
- サンドボックス外で実行されているプログラムには依然として攻撃の対象となり得る。
- サンドボックス自身にも脆弱性が存在する。
- 悪意を持ったソフトウェアがアップルの審査を通過してしまう可能性がある。
- App Storeにも脆弱性が存在する。
すなわち、サンドボックスはセキュリティを高めるのに貢献するが完全ではないので過信は禁物ということだ。というわけで、OSXにも当然ながらアンチウィルス・ソフトウェアは必要ではないかと筆者は思うのであるが、先に述べたように全てのサードパーティ製アプリにサンドボックス化を義務付けるとアンチウィルス・ソフトウェアの開発・販売ができなくなってしまう。この点についてアップルはどうするつもりなのだろうか。もしアンチウィルス・ソフトウェアの開発・販売ができない状態が継続するなら、安全神話が囁かれるOSXこそ最も危険なOSになる可能性が高いだろう。安全神話の盲信は禁物であり、原発の安全神話を盛んに追及する中島氏だからこそ、OSXの安全神話についてもフェアな立場で検証して頂きたいと願うばかりである。
最後に余談であるが、App Storeの審査は、登録されるアプリがプロプライエタリ・ソフトウェアである以上、安全性の検証、すなわち隠し機能が存在しないかどうかということの確認には限界があり、真の安全性は提供されないように思う。真の安全はソースコードが提供されるフリー（自由な）ソフトウェアによってのみもたらされるということを主張して、本エントリを締めくくろうと思う。
0 件のコメント:
コメントを投稿