Stagefright: Android を変えたエクスプロイト

アンドロイドNov 09, 2023

Stagefright は、Android が最近目撃した最悪のエクスプロイトの 1 つです。 クリックして詳細を確認し、身を守る方法を確認してください。

Android の最も強力な点の 1 つは、主にオープン ソースの性質であり、関係者が特定のニーズに合った方法で OS をフォーク、変更、再配布できるようになります。 しかし、オープンソースであることのまさにこの利点は、マルウェアとセキュリティの問題に関しては両刃の剣のように機能します。 ソースコードが無料で利用できるプロジェクトに有能な貢献者がたくさんいると、欠陥を見つけて修正するのが簡単になります。 ただし、ソース レベルで問題を解決しても、最終消費者の手で問題が解決されることにはなりません。 そのため、データに敏感な企業のニーズに合わせて OS を選択する場合、Android は第一の選択肢ではありません。

Google I/O 2014 で、Google は、より安全で企業向けのエコシステムを目指して最初の取り組みを開始しました。 Android For Work プログラム. Android For Work は、企業のニーズに合わせてツイン プロファイル アプローチを採用し、IT 管理者が 従業員ごとに異なるユーザー プロファイル - 1 つは仕事に焦点を当て、他のプロファイルは従業員の個人的なものに残します 使用。 ハードウェアベースの暗号化と管理者が管理するポリシーの使用により、仕事と個人のデータは区別され安全に保たれました。 その後、Android For Work は後半にはさらに注目を集めるようになり、マルウェアに対するデバイスのセキュリティに重点が置かれました。 Googleも計画していた すべてのデバイスの完全なデバイス暗号化を有効にする これは Android Lollipop とともにリリースされる予定でしたが、OEM の実装がオプションになったことによるパフォーマンスの問題により廃止されました。

安全な Android の推進は完全に Google の仕事というわけではありません。Samsung は、この点でかなり重要な役割を果たしています。 KNOX の AOSP への貢献、最終的には Android For Workの強化. ただし、Android の最近のセキュリティ悪用と脆弱性は、企業での普及に関して困難な課題を示しています。 その好例は、最近の Stagefright の脆弱性です。

コンテンツ：

  • ステージ恐怖症とは何ですか？
  • Stagefright はどれくらい深刻ですか?
  • Stagefright は他の「大規模な脆弱性」と何が違うのでしょうか?
  • アップデートのジレンマ
  • アンドロイド、ポストステージフライト
  • 終わりのメモ

ステージ恐怖症とは何ですか？

簡単に言えば、Stagefright は、Android でのメディア再生用のコード ライブラリを利用するエクスプロイトです。 リブステージ恐怖. libstagefright エンジンは、MMS 経由で悪意のあるビデオの形式で受信したコードを実行するために使用されるため、攻撃を成功させるには被害者の携帯電話番号だけが必要です。

私たちは社内エキスパート、XDA 上級認定開発者、および開発者管理者に連絡を取りました。 パルサー_g2 より詳細な説明を提供します。

"私がこれを書いている時点では、[Stagefright] エクスプロイトは BlackHat で説明される予定でした [リンク] ですが、スライドやホワイトペーパーの詳細はまだありません。

したがって、私はこの説明を、完全な正確性などを備えた非常に詳細な説明としてではなく、何が起こっているかの大まかなアイデアとして提供しています。

Stagefright を構成するさまざまなバグが多数あり、これらには独自の CVE があります [一般的な脆弱性とその危険性] 追跡用の番号:

  • CVE-2015-1538
  • CVE-2015-1539
  • CVE-2015-3824
  • CVE-2015-3826
  • CVE-2015-3827
  • CVE-2015-3828
  • CVE-2015-3829

残念ながら、利用可能なパッチは各 CVE に直接リンクされていないため (当然のことですが)、これを説明するのは少し面倒になります。

1. [CVE-2015-1538]

MPEG4 処理コードでは、3GPP メタデータ (ビデオが 3GPP 形式の場合に、形式やその他の追加情報を説明するもの) 処理コードにバグがあります。 データが大きすぎる場合でもメタデータは拒否されず、小さすぎるかどうかだけがチェックされました。 これは、攻撃者が本来よりも長いメタデータ部分を持つ「変更された」または「破損した」ファイルを作成する可能性があることを意味しました。

「信頼できない」データ (つまり、ユーザーから、またはコードの外部のその他の種類の場所からのもの) を処理するコードを作成する際の大きな課題の 1 つは、可変長データを処理することです。 動画はその好例です。 ソフトウェアは、何が起こっているかに応じて動的にメモリを割り当てる必要があります。

この場合、バッファはメモリへのポインタとして作成されますが、バッファが指す配列の長さが 1 要素短すぎます。 次に、メタデータがこの配列に読み取られ、この配列の最後のエントリが「null」（またはゼロ）にならない可能性がありました。 配列の最後の項目がゼロであることが重要です。これは、ソフトウェアが配列の終了を示す方法だからです。 最後の値をゼロ以外にできることにより (配列の 1 つの要素が小さすぎる可能性があるため)、悪意のあるコードがコードの別の部分によって読み取られ、大量のデータが読み込まれる可能性があります。 この値の終わりで停止するのではなく、読み取るべきではない他のデータを読み取り続ける可能性があります。

(参照: OmniROM ゲリット)

2. [CVE-2015-1539]

メタデータは UTF-16 文字列であるため、メタデータの最小の「サイズ」は 6 バイトである必要があります。 コードは整数値のサイズを取得し、そこから 6 を減算します。 この値が 6 未満の場合、減算が「アンダーフロー」して回り込み、非常に大きな数値が得られます。 たとえば、0 から 65535 までしか数えられない場合を想像してください。 数字の 4 から 6 を引くと、ゼロを下回ることはできません。 したがって、65535 に戻り、そこから数えます。 それがここで起こっていることなのです！

6 未満の長さを受信した場合、フレームが正しくデコードされない可能性があります。 byteswap プロセスは変数 len16 を使用し、その値は次の計算から取得されます。 (サイズ-6)。 これにより、意図したよりもはるかに大規模なスワップ操作が発生し、フレーム データの値が予期しない方法で変更される可能性があります。

(参照: OmniROM ゲリット)

3. [CVE-2015-3824]

大したことだ！ こいつは厄介だ。 この最後の問題とは正反対の、整数が「大きすぎる」可能性がある整数オーバーフローがあります。 (たとえば) 65535 に達し、それ以上数えられない場合は、ぐるぐる回って、次は 0 に進みます。

これに基づいてメモリを割り当てている場合 (Stagefright が行っていることです!)、配列に割り当てられるメモリが少なすぎることになります。 これにデータが入力されると、無関係なデータが悪意のあるファイル作成者が制御するデータで上書きされる可能性があります。

(参照: OmniROM ゲリット)

4. [CVE-2015-3826]

もう一つ厄介なものが！ 最後のものとよく似ていますが、別の整数オーバーフローでは、配列 (バッファーとして使用される) が小さくなりすぎます。 これにより、無関係なメモリが上書きされる可能性があり、これもまた問題です。 メモリにデータを書き込むことができる人は、関係のない他のデータを破壊する可能性があり、これを利用して、自分が制御するコードを携帯電話で実行させる可能性があります。

(参照: OmniROM ゲリット)

5. [CVE-2015-3827]

これらの最後のものと非常によく似ています。 変数はメモリの一部をスキップするときに使用され、これは減算中に負の値になる可能性があります (上記と同様)。 これにより、「スキップ」の長さが非常に長くなり、バッファがオーバーフローし、アクセスすべきでないメモリにアクセスしてしまう可能性があります。

(参照: OmniROM ゲリット)

[Android] 5.1 にも組み込まれたと思われる (潜在的に) 関連する修正がいくつかあります。

(参照: OmniROM ゲリット)

これにより、過去のセキュリティ修正による問題を阻止するためのチェックが追加され、境界チェックが追加されますが、それ自体がオーバーフローする可能性があります。 C では、signed int として表現できる数値は signed int として格納されます。 それ以外の場合は、操作中に変更されないままになります。 これらのチェックでは、一部の整数が (符号なしではなく) 符号付きになっている可能性があり、これにより後で最大値が減り、オーバーフローが発生する可能性があります。

(参照: OmniROM ゲリット)

さらにいくつかの整数アンダーフロー (数値が低すぎる場合、それらの数値に対して減算が実行され、数値が負になる可能性があります)。 これもまた、小さい値ではなく大きい値になり、上記と同じ問題が発生します。

(参照: OmniROM ゲリット)

そして最後に、別の整数オーバーフローが発生します。 前と同じように、他の場所で使用されようとしているので、オーバーフローする可能性があります。

(参照: OmniROM ゲリット)"

Stagefright はどれくらい深刻ですか?

に従って、 ブログ投稿 親研究会社である Zimperium Research Labs によって公開された Stagefright エクスプロイトにより、次のことが暴露される可能性があります。 Android 2.2 および 2.2 を実行しているデバイスに影響を与えるため、Android デバイスの 95% (約 9 億 5,000 万台) がこの脆弱性の影響を受けます。 上。 さらに悪いことに、Jelly Bean 4.3 より前のデバイスには、このエクスプロイトに対する適切な緩和策が含まれていないため、「最悪のリスク」にさらされています。

Stagefright が与える可能性のあるダメージについて、pulser_g2 は次のように述べています。

[blockquote author="pulser_g2"]「それ自体では、Stagefright は電話でシステム ユーザーにアクセスを許可します。 ただし、実際に ASLR (アドレス空間レイアウトのランダム化) を悪用するには、ASLR (アドレス空間レイアウトのランダム化) をバイパスする必要があります。 これが達成されたかどうかは現時点では不明です。 このエクスプロイトにより、システムまたはメディア ユーザーとしてデバイス上で「任意のコード」を実行できるようになります。 これらはデバイス上のオーディオとカメラにアクセスでき、システム ユーザーは root エクスプロイトを開始するのに最適な場所です。 携帯電話をルート化するために使用した素晴らしいルートエクスプロイトを覚えていますか?

これらは、デバイス上で root を取得するためにサイレントに使用される可能性があります。 root を持っている人が電話を所有します。 SELinux をバイパスする必要がありますが、TowelRoot はそれを成功させ、PingPong もそれを成功させました。 彼らがrootを取得すると、あなたの携帯電話上のすべてが彼らに公開されます。 メッセージ、キーなど。」[/blockquote]最悪のシナリオについて言えば、コードを配信してこのエクスプロイトをトリガーするには MMS のみが必要です。 ユーザー メッセージを開く必要さえありません 多くのメッセージング アプリは、ユーザーが MMS を操作する前に MMS を前処理するためです。 これはスピア フィッシング攻撃とは異なります。ユーザーは攻撃の成功にまったく気付かず、携帯電話内の現在および将来のすべてのデータが危険にさらされる可能性があります。

Stagefright は他の「大規模な脆弱性」と何が違うのでしょうか?

「すべての脆弱性はユーザーに何らかのリスクをもたらします。 これは、誰かがリモートから攻撃する方法を見つけた場合（つまり、 ASLR を回避する方法が見つかった場合は可能です)、自分が危険にさらされていることに気づく前に、ASLR が引き起こされる可能性があります。 攻撃"

Android インストーラー ハイジャック、FakeID などの古いエクスプロイトや、TowelRoot や PingPong などのルート エクスプロイトは、実行するためにある時点でユーザーの操作が必要です。 これらは、悪意を持って使用された場合に多くの害を引き起こす可能性があるという点で「悪用」であることに変わりはありませんが、Stagefright が 理論的には、被害者の携帯電話番号だけで携帯電話をトロイの木馬に変えることができるため、最近非常に注目されています。 日々。

ただし、Android がこのエクスプロイトに完全に翻弄されているわけではありません。 Android セキュリティ担当リード エンジニアの Adrian Ludwig 氏は、次の記事でいくつかの懸念事項に言及しました。 Google+の投稿:

[blockquote author="Adrian Ludwig"]「ソフトウェアのバグはどれもセキュリティエクスプロイトに変わる可能性があるという誤った思い込みがよくあります。 実際、ほとんどのバグは悪用可能ではなく、その可能性を高めるために Android が行ってきたことはたくさんあります...

Ice Cream Sandwich (Android 4.0) 以降に導入されたテクノロジーの一部をリストに示します。 ここ. これらの中で最もよく知られているのは、Address Space Layout Randomization (ASLR) と呼ばれるもので、完全に完成しています。 Android 4.1 では PIE (Position Independent Executables) をサポートしており、現在 Android の 85% 以上に搭載されています。 デバイス。 このテクノロジーにより、攻撃者がエクスプロイトを成功させるために必要なコードの場所を推測することがより困難になります...

私たちは ASLR にとどまらず、NX、FortifySource、Read-Only-Relocations、Stack Canaries なども追加しました。」[/blockquote]

しかし、Stagefright が Android の将来にとって重大な問題であることは依然として否定できず、そのため関係者は真剣に受け止めています。 Stagefright はまた、部屋の中の白い象、つまり断片化の問題と、最終的に消費者に届くアップデートの問題を強調しました。

アップデートのジレンマ

アップデートといえば、多くの OEM が約束したように、ユーザーのセキュリティに責任を負っているのは良いことです。 特に Stagefright のようなエクスプロイトに対するセキュリティ修正とパッチを組み込むための更新プロセスを改善します。

公式声明を発表した最初の企業の中で、Google は次のように約束しました 毎月のセキュリティ更新プログラム （予定されている OS とプラットフォームのアップデートに加えて）ほぼ 3 年前の Nexus 4 を含む、ほとんどの Nexus デバイスに適用されます。 サムスンもこれに続き、通信事業者やパートナーと協力して、 月次セキュリティ更新プログラム しかし、この実装のデバイスとタイムラインの詳細を指定できませんでした。 これは、通信事業者と協力してセキュリティ アップデートに対する「ファスト トラック」アプローチについて言及しているので興味深いものです。 キャリアでのより頻繁なアップデートが期待されます（セキュリティベースではありますが、ファームウェアのアップグレードも加速されることを期待しています） デバイス。

このパックに参加する他の OEM には、LG も含まれます。 毎月のセキュリティ更新プログラム. モトローラも発表しました 更新されるデバイスのリスト Stagefright の修正が加えられており、リストには 2013 年以降に同社が製造したほぼすべてのデバイスが含まれています。 ソニーもそう言ってる そのデバイスには間もなくパッチが適用されます あまりにも。

今回は通信事業者もアップデートを提供する予定です。 スプリントは 声明を発表した 一部のデバイスはすでに Stagefright パッチを受信して​​おり、さらに多くのデバイスがアップデートされる予定です。 AT&Tも追随した 一部のデバイスにパッチを発行することによって。 Verizonもパッチを発行しているが、これはGalaxy S6 EdgeやNote 4などのハイエンドスマートフォンを優先したゆっくりとした展開ではある。 T-Mobile Note 4 も Stagefright パッチ アップデートを受け取りました。

エンドユーザーとして、攻撃を受ける可能性を減らすために講じることができる予防措置がいくつかあります。 まず、携帯電話にあるメッセージング アプリで MMS メッセージの自動取得を無効にします。 これにより、エクスプロイトが機能するためにユーザーの操作が必要ないケースを制御できるようになります。 この後は、未知または信頼できないソースからの MMS メッセージからメディアをダウンロードしないように注意してください。

XDA パワー ユーザーは、次のこともできます。 ビルドプロップを編集して Stagefright を無効にします. これは Stagefright から身を守る完全かつ確実な方法ではありませんが、古い Android ビルドに行き詰まっている場合は、攻撃が成功する可能性を減らすことができます。 カスタム ROM ソリューションもありますが、そのほとんどは定期的にソースを AOSP と同期するため、Stagefright の修正が組み込まれます。 AOSP ベースの ROM を実行している場合は、Stagefright パッチを組み込んだ新しいリリースの ROM に更新することを強くお勧めします。 使用できます このアプリ 現在の日常ドライバーが Stagefright の影響を受けているかどうかを確認します。

アンドロイド、ポストステージフライト

Stagefright は、Android とその断片化の問題、およびアップデートに対する警鐘に他なりません。 このような重要な修正を多数のデバイスにタイムリーに展開できる明確なメカニズムが存在しないことが浮き彫りになっています。 OEM はデバイス向けのパッチを展開しようとしていますが、厳しい現実として、これらの修正のほとんどは最近の主力製品のみに限定されることになります。 他の主力製品ではないデバイスや古いデバイス、ましてや小規模な OEM 製デバイスは、今後も Stagefright のような脅威にさらされることになります。

この悪用には明るい兆しがある： Android のアップデート プロセスについて再び注目を集め、エンタープライズ用途に Android を採用する将来の多くの企業を惹きつけないような観点からこの問題を売り込みました。 Google は企業への導入拡大に向けて取り組んでおり、アップデート戦略と OEM に許可する制御の範囲を再考する必要に迫られるだろう。

Android M の市場リリースが日に日に近づいており、Google が Play サービス パッケージを優先して AOSP のコンポーネントをどんどん切り離すことを選択したとしても不思議ではありません。 結局のところ、デバイスが Google Play ストアに同梱されるかどうかは、Google が依然として完全に制御できる領域の 1 つです。 これ 独自の欠点があります オープンソースのエリアをクローズソースの壁に置き換える形で。

Android の将来を推測する場合、Google が OEM が AOSP に対して行うことができる変更を制限する可能性も (非常に低いですが) あります。 とともに RRO フレームワーク Android M では機能的な状態で存在するため、Google は OEM が RRO スキンの形式で表面的な変更のみを行うことを制限できる可能性があります。 これにより、より迅速なアップデートの展開が可能になりますが、その代償として、OEM が Android を完全にカスタマイズする機会が拒否されることになります。

考えられる別のルートは、同梱されるすべてのデバイスにこれを義務付けることです。 Google Play ストアは、一定期間 (おそらく 2 回) 保証されたセキュリティ アップデートを受け取ります 年。 Play Services フレームワークは、重要なセキュリティ アップデートやパッチの存在をチェックするために使用でき、準拠していない場合には Play ストアへのアクセスが取り消されます。

終わりのメモ

この問題を解決する洗練された方法がないため、これはまだ推測の域を出ません。 非常に全体主義的なアプローチをとらない限り、修正が届く範囲には常に何らかの欠点が存在します。 世の中には Android デバイスの数が膨大であるため、各デバイスのセキュリティのステータスを追跡することは非常に膨大な作業になります。 現在の必要性は、Android のアップデート方法を再考することです。現在の方法は明らかに最善ではありません。 私たち XDA Developers は、Android が引き続き Google のクローズド ソース計画に沿って作業しながら、オープンソースのルーツに忠実であり続けることを願っています。

あなたの携帯電話は Stagefright に対して脆弱ですか? あなたの携帯電話に Stagefright パッチが適用されることはあると思いますか? 以下のコメント欄でお知らせください。