セキュリティに関するソフトウェア「OpenSSL」が、
最近Hearbleedによる非常に重大なセキュリティホールを抱えていることが暴露され、
それらが大量のウェブサイトに波及していることが判明し、
業界内を震撼させたのは記憶に新しい。
しかしAppleのiOSやOS XシステムやAppleのサービスは全て影響を受けていないという。
これはどのような方法を使ってそのHeartbleedの毒牙から逃れたのだろうか?
米国のテクノロジーブログ、
4月18日のApple Insiderの記事がその背景にある秘密の物語について述べている。
以下は要約に一部私の解説を足したものだ(にしてもちょっと長いのでお時間がある方はどうぞ)。
2011年、Appleは既にOpenSSLの使用を中止していた
2011年、Appleはデベロッパー向けに、
Apple自身がOpenSSLが入っているOS Xの共用データセキュリティのフレーム(以下CDSAと表記)の使用を中止すると伝えていた。
AppleはOpenSSLを既に時代遅れのものとみなしていたのだ。
果たしてその3年後、つまり今年になって、
OpenSSL内に有名な「Heartbleed」をはじめとする多くの重大なセキュリティホールが発見され、
大量のサービスプロバイダやユーザが影響を受けている中、
Appleだけは平穏無事を保っているというわけだ。
Appleは2011年6月にOpenSSLの使用中止する計画を宣言した時、
当然Heartbleedセキュリティホール問題については把握していなかった。
なぜならまだHeartbleedは当時出現していなかったからだ。
しかしAppleは既にOpenSSL(libcrypto)にその他の問題があることは知っていた。
Appleは10年以上前にCDSA内でこのセキュリティツールボックスを使用していたからだ。
Appleがかつて使用していたCDSAとは
AppleはOS Xの研究開発の初期段階で、
CDSAとOpenSSLのサポートをしていた。
2004年、AppleはMac関連のデベロッパーにCDSAの採用を勧め、
CDSAを「他のフレームとの関連性や、暗号化データベースの数量を減らすことができ、
システムの全体の性能のアップに繋がる」と紹介していた。
Appleは更に10年前のMacのセキュリティに関する文書の中で、
「CDSAはOpen Group組織が採用しているオープンソースによるセキュリティフレームで、
技術標準にも適合している」とCDSAについて説明しており、
更に自身でCDSAのオープンソースバージョンを開発し、
それをAppleのオープンソースサイト上で公開していた。
このAPIが提供するセキュリティサービスには、
細かいアクセス権限や、ユーザID認証、暗号化とセキュリティデータの保存が含まれていた。
Apple自社のセキュリティフレーム
しかしその後、少なくとも2006年には、
Appleは全く新しい暗号化APIの開発を進めており、
その開発の目的はより少ないコードによって実行速度を速め、
更に多くのコアを搭載したCPUで同時に使用できる機能をサポートするためだった。
これらの特性はAppleのその後のMacだけではなく、
結果的にiOS搭載デバイスにとっても非常に重要な要素となった。
Appleが精密で簡単な、そして最も現代的なセキュリティフレームを開発したもう1つの理由は、
彼らが連邦情報処理基準(FIPS)に適合しないと、
米国政府機関に対してデバイスの販売ができなかったからだ。
iPhoneやiPad等iOSデバイスの売上が凄まじい勢いで増加するに従い、
Appleは強靱なセキュリティシステムを時代遅れのCDSAに代わって導入することが早急に求められていたこともあった。
まず始めにAppleはCommon Cryptoの開発に着手した。
これはコアの暗号化計算法の低消費レベルCのフレームで、
Appleはまず2007年にこれをOS X 10.5 Leopard、
そしてその後の2011年にはiOS5に適用した。
CDSAとOpenSSLの破棄
2011年、AppleはCDSAの使用中止準備が整った。
AppleはWWDC2011上でデベロッパー向けに、
CDSAはOpen Group標準に基づくものであり、
Apple以外ではサポートしている会社も滅多になく、
またこの機能の多くは誰も使っていないとしていた。
これはAppleが大量の複雑な外部問題を処理しなければならないことを指し、
またクロスプラットフォームの長所を得られないものだった。
「CDSAは自身の標準プログラムポートを持っていて、とても複雑だったため、
Appleが基準としているプログラム慣例に不適合だった」と、
AppleはMacセキュリティ文書の中でデベロッパーに対して明かし、
「iOSにはCDSAは導入しておらず、
OS XとiOSの両方とも自身に、以前よりも全く複雑ではないハイレベルの安全なAPIを搭載している」
とも書いている。
自身のセキュリティソフトを開発することは、
Appleとそのデベロッパー(=OS X、iOSデベロッパー)が、
外部開発やOpenSSLリソースプロジェクトに関する問題の影響を受けることがなくなったことを意味する。
業界内でどれだけ重要な位置を占めようとも、
またどれだけ広く使われているとしても、
OpenSSLは寄付に頼って支えられ運営されているもので、
これを開発している人は実は4人のコアデベロッパーだけなのだ。
「OpenSSLはオープンソースの世界では非常によく使われているソフトだ」
とAppleは上記の文書で述べている。更に、
「OpenSSLはバージョンとバージョンの間で互換性のある安定したAPIを提供できていない。
そんなわけで、OS XはOpenSSLデータベースは提供しているが、
使用はお勧めしない。
またOpen SSLはiOSに入れていない。
我々はアプリケーションがOS XのOpenSSLデータベースを利用することに猛烈に反対する。」
「もしあなたのアプリがOpenSSLに依頼しているのであれば、
あなたは自らOpenSSLを編集し、
静的アドレスが既知のOpenSSLバージョンとあなたのアプリを接続するようにしなければならない。
OS XとiOS上でOpenSSLを使用することはOKだ。
しかしそれはあなたが現在のオープンソースプロジェクトの元コードと互換性を維持したいときのみで、
そうでなければあなたは違うAPIを使うべきだ」
とも述べている。
AppleはOpenSSLが安定性のあるAPIを欠く原因として、
OpenSSLがオープンソースアプリを更新したり、
セキュリティホール問題の対策を追加したりするときに面倒なことになり、
旧版のOpenSSLに接続するサードパーティーアプリに影響するからだという。
そしてOpenSSLを捨て自社開発のソフトに切り替えるということは、
Appleが自社のプラットフォームを管理する際にもっと大きなコントロール権限を持つことになる。
AppleのOS Xソフトウェアの各種セキュリティホールは、
実際はAppleがバンドルしている外部ソフトウェアと関係していることが多く、
外部ソフトウェアにはオープンソースソフトウェアパックや、
Adobe Flashのようなサードパーティ用のコマーシャルTweakも含まれる。
OpenSSLにHeartbleedが進入
Appleが上記のようにOpenSSLを捨てたのは、
頗る幸運であったというほかない。
Appleが正式にOpenSSLの破棄を決めた半年後、
Heartbleedセキュリティホールは不注意のままOpenSSLに組み込まれのだが、
具体的にはセキュリティ接続を維持するHeartBeatの特性を通じて進入したとされている。
セキュリティホールが存在するheartbeatの特性は、
2012年3月にプッシュされたOpenSSLバージョンにも埋め込まれており、
しかもデフォルトで起動する仕様となっている。
Appleはこのセキュリティホールが導入される前に、
MacやiOSのデベロッパーに向けてOpenSSLではないセキュリティソフトを使うように積極的に提案していたちょうどその頃、
業界他社は相変わらずずっと無料で支給されていたOpenSSLの最新バージョンを採用していた。
その2年後(つまり今年)、Googleの一人の研究者が、
OpenSSLのHeartbeat機能にセキュリティホールがあることを発見し、
それが個人のプライバシー流出に繋がるだろうとし、「Heartbleed」と名付けた。
Heartbleedの影響を受けたクライアントアプリケーションは、
悪意を持ったサーバにコントロールされてしまうという危険性を孕んでいる。
米国では4月1日にこのセキュリティホールが大衆の前に晒され、
Googleはこの問題を内部的に解決するとしており、米国政府の誰にも通知していなかった。
「The Sydney Morning Herald」によると、
その後1週間ほどかけて、
全てのテクノロジー開発関連企業が自社製品にHeartbleedの漏洩がないかを競って公表し、
セキュリティ会社は今回のチャンスを使用して自らの知名度を高めようとし、
影響を受けた会社は徹夜も惜しまずこのセキュリティホール問題を解決し、
このHeartbleedの存在を知った悪意のある第三者からの攻撃を避けようと躍起になっているのは、
皆さんも周知の通りだ。
Apple自社開発のコードのセキュリティホール
上記のこともあってAppleのMacとiOSデバイスはHeartbleedの影響を受けなかった。
しかし実は数週間前、
Apple自身も自社で開発したコードにセキュリティ問題を抱えていたのは記憶に新しい。
このセキュリティホールはSSLのセキュリティ証明書に関するもので、
「GoToFail」と呼ばれている。
AppleのコードはOpenSSLと同様オープンソースだったが、
それでもこのセキュリティホールの出現を防げなかった。
この「GoToFail」はコードを書いた人の本当にごく単純なケアレスミスにより引き起こされたもので、
一部では「Apple史上最悪のセキュリティホール」とも呼ばれているが、
Appleはメディアを抑え込んだのか、Heartbleedほど大げさな問題になっていない。
またAppleはこのGoToFailが公にされる前にiOSのマイナーアップデートを支給したが、
OS Xに関しては公にされた後3日後にリリースされたため、
その3日間にOS X Mavericks 10.9.1を搭載していたデバイスは3日間危険に晒されていたことになり、
このことについてはAppleもメディアに随分と槍玉に挙げられた。
つまりAppleもHeartbleed問題は避けられたものの、
完璧ではないということがわかるだろう。
Heartbleedの公表問題
しかしそれに比べてHeartbleed騒動はもっとお粗末だ。
多くの関係者はこのHeartbleedの存在を知ってから、
1週間もかけてセキュリティホールの公開について同意に至った形となった。
Facebookをはじめとしたいくつかの会社は、
Heartbleedが公開される前にこのセキュリティホールの情報をキャッチしており、
すぐにその問題に対処することができた。
しかしCisco、Dropbox、Juniper、Twitter、Ubuntu、Yahoo等の世界的に著名な企業は、
我々一般人と同様数日後にそのことを知ったとされている。
実に情けない話だ。
実はAndroidのWebViewにも、
1年4ヶ月ほど前に似たようなネットに関するセキュリティホールが発見されている。
このセキュリティホールは前出のHeartbleedやGoToFailに比べて非常に深刻で、
ハッカーがデバイスをリモートコントロールできてしまい、
とあるツールを使えば全てのデバイスが攻撃者となり得てしまうものだった。
このセキュリティホールに関しては75%のAndroidデバイスが影響を受けなかったと発表されているが、
既にiOSをとっくに抜いて世界最大のスマートフォンOSとして普及しているAndroidを搭載したデバイスの、
実に25%(4分の1)が影響を受ける可能性があったということは驚愕に値する。
いずれにせよ、現在スマートフォンやタブレット型デバイスが、
MacやPCを超えて一般に普及する中、
セキュリティ問題はますます重要になり、
いったん発覚するとその影響力は非常に大きくなっている。
当ブログでもセキュリティ問題には今後も注目していきたい。
何事にも絶対というものはないが、
AppleのOSやそれを搭載したデバイスは、
基本的に問題が起こった場合すぐにOSのアップデートによって対策がなされるため、
比較的安全であるということがわかってもらえただろうか。
そんなわけで、
Appleのデバイスは、できるだけ最新のOSにアップデートするようにしておけば安全だ。
iOSを脱獄している人にはiOSアップデートはできない相談かもしれないが、
Cydiaにてパッチが出ることもあるので、
最低限それによって対処はしておきたいものだ。
記事は以上。