さらば、Stagefright 脆弱性

Tsukasa OI
a4lg.com
2015-09-09
日本 Android の会 | 2015年 9月定例会
さらば、Stagefright 脆弱性
結局この脆弱性は何だったのか / 混乱と騒動の中から見出すべきものは?
[JAPANESE : version 1.1]

注意点 (日本語版)
• このプレゼンは日本向けに書かれています
• 後述するように、日本固有のキャリア事情や
報道などに強く依存しています
• そのため、日本国外ではこのスライド内の
情報の一部が適用できないことがあります
• このプレゼンの対象者は、
主に非セキュリティ分野の情報技術者です
• 技術的すぎる部分はほとんどスライドから外しています

この資料について (version 1.1)
• 9月9日の “日本 Android の会定例会” にて
用いた version 1.0 の拡張版です
• 一部情報の追加、(スピーチには入れなかったが)
訂正、構成上の順番の変更などを含みます

自己紹介 (1 of 2)
• 大居司 (Tsukasa OI; @a4lg)
• 現在無所属のセキュリティ研究者
• Black Hat Abu Dhabi 2011 / USA 2012 スピーカー
• 本来の専門は低レイヤーのアーキテクチャ
• モバイル OS 研究においては主に低レイヤーにおいて
どのようにシステムが構築され、それにどのような
セキュリティの問題があるかを扱っていた
• ただし必要に応じて高レイヤーの問題も扱う
(というか……扱いすぎた?)

自己紹介 (2 of 2)
• 大居司 (Tsukasa OI; @a4lg)
• 現在無所属のセキュリティ研究者
• Black Hat Abu Dhabi 2011 / USA 2012 スピーカー
• FFRI にてモバイル OS 研究などに従事 (-2014)
• Android
• “Inside Android Security” などのAndroid セキュリティに
関する基礎的なドキュメントを執筆
• Android 4.0 の ASLR が完全でないことを暫定パッチとともに
Google に指摘し (ただし内部的には既に問題を把握していた模様)
Android 4.1 の修正時に世界で初めて詳細な記事を公表1
• Windows Phone 7.x
• Windows Phone 7 の脆弱性攻撃への耐性と
構造的な一部問題点についてある程度体系的にまとめる
(Microsoft の宣伝において “第三者機関の調査” として紹介2)
1. https://ja-jp.facebook.com/notes/455931517757936
2. https://www.microsoft.com/ja-jp/windowsphone/products/merit/security/default.aspx

今回のセッションでは……
• 騒動の全体を振り返る
• Stagefright 脆弱性とは
なんだったのか、技術的観点から整理する
• 騒動の問題点を振り返る
• 反省点と課題を見出す

振り返り編
結局何があったのか
(そしてこの発表の中でどう見ていくのか)

脆弱性振り返り (1 of 5)
• 2015年 7月 27日、Zimperium (zLabs) の
Joshua J. Drake (@jduck) 氏が
4月と5月に報告した脆弱性の概要が公表される 1
• Android 共通コンポーネントの脆弱性
• 脆弱なコンポーネント “Stagefright” と
同名の “Stagefright” と命名される(要曖昧さ回避)
1. https://blog.zimperium.com/experts-found-a-unicorn-in-the-heart-of-android/

• 脆弱性の “深刻さ” を物語る報道が次々と現れる
• Android 2.2-5.1 に影響
• リモートからアプリ権限での任意コード実行
• 悪意ある MMS を送るだけで感染させることが可能
• MMS 受信の無効化が対策になる
• Android 端末の 90% 以上が影響を受ける
• 最大規模のアップデートとなりうる
• が、問題ある報道も多数
(赤字はすべて [程度の差はあれ] 問題のある報道)
• 大人気ないが、あんまりだった記事の例 (後述):
95％のAndroid端末にMMSを受信するだけで端末を乗っ取ら
れる脆弱性が発覚、対策はこれ – GIGAZINE 1
• また報道ではほとんど語られなかった “問題” も……
1. http://gigazine.net/news/20150728-android-hack-stagefright/

• Zimperium (zLabs) による実証動画
(8月 5日投稿) も混乱を一部もたらす
• MMS 送信によってリバースシェルを取るだけではなく
root 化まで実施してしまう
• 予備知識がないと誤ったメッセージを
受け取ってしまう危険性がある
• 少なくとも、専門家以外が見る場合に
注意するべき点が幾つか……
• Google と Samsung が OTA において
毎月セキュリティアップデートを配信へ
• 良さそう (だけど追従できるのか?)

• 8月17日前後 (Black Hat USA より遅れて)
Drake 氏のスライドがオンライン公開される
• 報道でカバーされていない点も含めて、
技術的には非常に誠実に書かれている
• Stagefright 経由の攻撃に関して私の独自発見だと
思っていた部分も、大半は Drake 氏によって既に指摘されていた
• しかし、日本の報道のほとんどでは
その重要な多くが省略されてしまっていた
• そもそも事前の予告だけ記事にして
Black Hat USA の発表をベースにした記事が出てない例も……
1. https://www.blackhat.com/docs/us-15/materials/us-15-Drake-Stagefright-Scary-Code-In-The-Heart-Of-Android.pdf

• 9月 9日 (日本時間 10日)、
Drake 氏による攻撃コードが公開される
• CVE-2015-1538 #1 (‘stsc’ chunk)
• Android 4.0 においては
完全な ASLR バイパスを行っている
• これから第三者による分析がさらに進むだろう!

今回まとめておきたいこと
• Stagefright の立ち位置
• Stagefright 脆弱性の技術的要素
• 何がマズいのか
• 考えられる攻撃ルート
• 考えられる影響
• 混乱した情報の整理
• 報道のどこがマズかったのか
• MMS は日本において本当に深刻なものなのか
• その他 (数トピック)
• Android のアップデート問題
• 今後どうするべきか? (他社から見えてくる例)

基礎編
Stagefright とメディア処理 (Stagefright の立ち位置)

Stagefright とは??
• Stage fright (不可算名詞)
→ 舞台負け / アガり
• Stage flight と勘違いしやすいとか?
• ……について聞きたいわけではないですよね。

Stagefright とは? (1 of 3)
• Android 中でメディア (音声/動画) を扱うための
共通インタフェースを定義するフレームワーク
(libstagefright および周辺のいろいろ)
• Android 2.2-2.3* において従来のメディア処理
フレームワーク (OpenCore) に代わる形で登場
(既存ソフトウェアを取り込んだわけではない)
• OpenMAX (OMX) IL コンポーネントによる拡張
• デフォルトのソフトウェアデコーダやエンコーダも
OpenMAX IL コンポーネントとして実装されている
• 共通化されたインターフェースの提供
(エンコーダ、デコーダ、メディア情報取得)
* Android 2.0 でソースコード上は登場していたが、Android 2.2 でメディアフレームワークの選択肢に上がり、
デフォルトで有効化されたのは Android 2.3 から

• Android 中でメディア (音声/動画) を扱うための
共通インタフェースを定義するフレームワーク
(libstagefright および周辺のいろいろ)
• 実際の処理の多くは副ライブラリか外部に丸投げ
• ソフトウェア処理の例: FLAC [libFLAC]
• ハードウェア処理 (カスタム OMX コンポーネント)
• Stagefright ライブラリの中心的実装においては
主に基本的なメタデータ等のパースや
下位のデータ構造との橋渡しを行う
• Android で使用されている
• ……だけかと思いきや……!

• Mozilla Firefox (PC 版含む!) においても
メディア処理に使用されている!
• 当然のように、同じ脆弱性を共有してしまった
• ただし、Android そのものの Stagefright から
独自で手を加えているらしい
• そのため修正はやや混乱した状況にある
• 重要な部分に関しては Firefox 38.0 で修正
• 一部は時期的に Drake 氏の発見とは
独立に修正されたものとみられる
• 任意コード実行に発展しない可能性が高い
一部の脆弱性 (クラッシュにはつながる) は未修正*
• 今回のセッションでは主に Android を扱う
* Zimperium 公開の PoC (任意コード実行ではなくクラッシュのデモ) を Firefox 40.0.3 で再生させると、
そのうちひとつのファイルにてクラッシュが発生する。

Android におけるメディア処理 (1 of 3)
例: MediaPlayer クラスを使用して音楽再生を行う場合
libstagefright.so (共通インターフェース)
3rd party OMX
VPU 等の HW
Stagefright 副ライブラリ
外部 libs (libvorbis 等)
外部 libs
(libFLAC 等)
Stagefright があるが
実はこの “外” が重要

• Android の多くの “特権” 処理は
分離されたプロセス内のサービスで行われる
• メディア処理は “mediaserver” プロセス
(MediaPlayerService) によって行われる
• Binder を介した IPC (プロセス間通信)
• “mediaserver” は “media” ユーザーで動作
(その他 GID 割り当て等に関しては後述)
• 脆弱性の誤解:
攻撃に成功すると、アプリの権限を得る
• 今回の攻撃の場合、アプリから分離された
“mediaserver” プロセス内でバッファオーバーフローが発生
• 結果、当プロセス (“media” ユーザなど) の権限を得る

例: MediaPlayer クラスを使用して音楽再生を行う場合
(おおむねコールスタック逆順)
app_process (アプリケーションプロセス)
アプリケーション実装
…
android.media.MediaPlayer クラス
libmedia.so (Media Library)
mediaserver (メディア処理サービス)
…
libmediaplayerservice.so (Media Player Service)
…
libstagefright.so (共通インターフェース)
3rd party OMX
VPU 等の HW
Stagefright 副ライブラリ
外部 libs (libvorbis 等)
外部 libs
(libFLAC 等)
* Media Player Service による “Render” 処理の後、基本的には同一プロセス内の AudioFlinger (オーディオミックスなど) や
別プロセスの SurfaceFlinger (描画結果の調停) によって最終的なメディア再生が行われる (ここでは省略)
Binder
(IPC)
脆弱性!

技術編 (1 of 2)
Drake 氏が発見した脆弱性とはどのようなものだったのか?

パッチを調べてみよう (1 of 2)
• Drake 氏による 12 個のパッチ
パッチ脆弱性の (主要な) 種別あり得る結果の例原因
1 NULL ポインタアクセスクラッシュ状態管理の不備
2 NULL ポインタアクセスクラッシュ状態管理の不備
3 0 除算クラッシュ値の検証不足など (分類困難)
4 バッファオーバーフローメモリ破壊* 整数オーバーフロー
5 C++ 例外の不適切な発生クラッシュ例外を投げうる new の使用
7 バッファオーバーフロークラッシュ / 情報漏洩? 整数オーバーフロー
9 バッファオーバーフロークラッシュ / 情報漏洩文字列の null 終端忘れ
* “メモリ破壊” と記したものは、任意コードが実行できる可能性がある。攻撃者による破壊の (精密な) コントロールが
困難である場合がある一方で、Stagefright 関連コンポーネントの一部はマルチスレッド動作することに注意。
* “情報漏洩” は必ずしも “秘匿” したいデータの漏洩に限らない (防御突破のための有効なポインタアドレス取得など)

パッチを調べてみよう (2 of 2)
• 特に重大な結果をもたらしうる脆弱性は
どれも整数オーバーフロー起因であるようだ
• それ以外の修正もかなりあるが、どれも
直接の任意コード実行には発展させにくい
(一部はそもそも発展が不可能)
• 整数オーバーフローがもたらす
バッファオーバーフローとは?
• 事前注意 : 符号の有無に関わらず発生しうる
(今回は [偶然にも] すべて符号無し整数型が関与するが)

整数オーバーフローと脆弱性 (1 of 3)
• 整数演算の結果、結果がその整数型の範囲内に
収まらなくなった際に発生する現象を見る
• C/C++ の場合 (符号付き 8-bit 整数型 [-128〜127*]):
• 具体的な挙動は未定義!
(-128 が得られるかもしれないが、それは単なる偶然)
• 他の言語では具体的挙動が定義される場合がある
0 1111111127
0 00000011
+ 128 1 0000000 (-128) ?
表現可能範囲を超える
?
結果や挙動は未定義
* 内部表現が 2 の補数である場合を例として示したが、どの内部表現でも未定義であることには変わらない
(余談: C++ では内部表現の具体的規定は無く、C では 2 の補数、1 の補数ないし符号付き絶対値のいずれか、という規定がある)

• 整数演算の結果、結果がその整数型の範囲内に
収まらなくなった際に発生する現象を見る
• C/C++ の場合 (符号無し 8-bit 整数型 [0〜255]):
• 桁あふれされたビットが切り捨てられる
(例えば 8-bit の場合、2^
8 = 256 のモジュロに等しい)
• 結果は明確に定義されている (ただそれが “安全” かは別)
11111111255
000000011
+ 1 00000000 (256)
00000000 0
桁あふれが発生
あふれたビットを切り捨て

• 特にバッファサイズの計算などで
不適切な整数オーバーフローが起こると、
バッファオーバーフローの直接的な原因となりうる
• 例えば、こんなコード、書いてませんか?
size_t sz;
if (fread(&sz, sizeof(size_t), 1, fin) < 1) goto error;
int *buf = new int[sz + 4];
// ...
• sz の与え方によって (sz + 4) にてオーバーフローが発生
• sz が SIZE_MAX である場合 (sz + 4) は 3
• 明示的な演算以外の要因 : 型変換など
• 実は、上記のコードには (C++ の規格バージョン等によっては)
足し算以外のオーバーフローもある!*
• 具体的実装によってはかなり深刻な
バッファオーバーフローが発生してしまう!
* 答えはおまけセクションにて

バッファオーバーフロー入門 (1 of 2)
• “メモリの破損” を攻撃者が精密に制御する
ことにより、プログラムの動作を改変する
• 古典的なスタックオーバーフローの例
スタック上の
配列 (バッファ)
決められた範囲からはみ出すと
右側の戻りアドレスなどが
上書きされる
戻り
アドレスその他
呼び出し履歴
サブルーチン
A
サブルーチン
B
攻撃者によって書き換えられる!
スタック上の
戻り
アドレスその他
呼び出し履歴
攻撃者のコード
サブルーチン
B
攻撃によって、“サブルーチン A” から呼び出されていた
はずのフローが “攻撃者のコード” に置き換わっている!

バッファオーバーフロー入門 (2 of 2)
• データ領域の実行防止 (DEP) などを躱すため、
既存の実行可能コードの断片を繋ぎあわせて
必要な攻撃を行う手法なども多く使われる
• 例: 古典的なスタックオーバーフローに DEP 回避の
ROP (Return-Oriented Programming) が用いられた場合
スタック上の
戻り
アドレス攻撃コード
DEP により、書き込まれた
攻撃コードを直接実行できない
スタック上の
戻り
アドレス
戻り
アドレス
戻り
アドレス
戻り
アドレス
正規の
実行
モジュール
正規の実行モジュールのうち
都合の良いアドレスを選択
呼び出し履歴
コード
断片 4
コード
断片 3
コード
断片 2
コード
断片 1
サブルーチン
断片をパズルのように繋ぎあわせて
攻撃コードになるよう組み上げる

脆弱性のひとつを見る (1 of 2)
• ‘tx3g’ チャンクの処理における整数オーバーフロー
• これは字幕などのための MPEG-4 チャンク
• 重要な前提 :
複数の tx3g チャンクが現れたとき、
中身は連結してひとつにする
• 脆弱性を発見してみよう!

脆弱性のひとつを見る (2 of 2)
• ‘tx3g’ チャンクの処理における整数オーバーフロー
chunk_size : MPEG-4 チャンクの
(攻撃者が偽装可能な) サイズ
mLastTrack : 処理中の MPEG-4 トラック
case FOURCC('t', 'x', '3', 'g'):
{
uint32_t type;
const void *data;
size_t size = 0;
if (!mLastTrack->meta->findData(
kKeyTextFormatData, &type, &data, &size)) {
size = 0;
}
uint8_t *buffer = new uint8_t[size + chunk_size];
if (size > 0) {
memcpy(buffer, data, size);
}
// ...
処理済み字幕のコピー
(後で新しい字幕を追記)
整数オーバーフロー!
バッファオーバーフロー!
(攻撃者によって制御されたサイズ)
* 本脆弱性においては同じ処理に起因して最大 2 回のバッファオーバーフローが発生しうる (データソースによって異なる) のだが、
ここでは必ず実行される方のバッファオーバーフローのひとつ (バッファ前半) と双方共通の原因になっている前半部分を抜粋。
Android 4.4 (r1) : frameworks/av/media/libstagefright/MPEG4Extractor.cpp より一部抜粋

実証編
一部の人にとってはお楽しみのタイム
一部の人にとっては恐怖のタイム

デモに際して
• 現地でのデモはできません (sorry!)
• デモの payload 配置にて不確定要素が排除できておらず、
最悪の場合 1 時間以上トライし続けることになるため
• そのため、あらかじめ用意した
ムービーを再生する形になります
• “実証編” では、まず攻撃経路を確認してもらう
• 後々も、デモ (で配置した payload) を使って
何ができるかなどを確認してもらう

Demo (1 of 2)
• まずは報道で散々騒がれた、
MMS 経由の攻撃について……見てみよう
• ごめんなさい、キャンセルします
• ソフトバンク回線が実家にて非常に安定せず、
また開発途中の exploit の成功率が低いために
うまく動画を撮れなかった
• ドコモ回線ですらたまに捉まらない場所なのでお察しください……
• Android 4.4 を当初の攻撃対象としたため、
MMS のみの純粋な攻撃ルートではなく、
別の脆弱性を用いて ASLR を回避するものだった

Demo (2 of 2)
• 一方報道でほとんど騒がれなかった、
Web ブラウザの罠ページ経由での
攻略も見てみよう
• 特定のファイルをダウンロードし、
メモリ上で実行 (exec ではない!) してしまう
• Nexus 5 + Android 4.4.0 (r1)
• 後のデモの一部は Android 5.0.0 (r1) でも見せる

技術編 (2 of 2)
Stagefright 脆弱性を使って何ができる/できたのか

攻撃ルート
• Stagefright によるメディア取り扱い
(に伴うメタデータ取得) が絡むなら
なんだって攻撃ルートになってしまう
• 通信路への介入 (通信の最適化)
• Web サイトの不正書き換え
• 罠ページへの誘導
• MMS へのメディア添付
• 悪意あるアプリケーション

影響 (1 of 2)
• “mediaserver” プロセスの権限を奪われる
• アプリ固有のデータには基本的にアクセスできないが……
• 当プロセスは各種メディア処理に関する
数々の特権を持っている!
• GID: inet
インターネット経由で遠隔操作や情報送信が可能
(Zimperium のデモでリモートのシェルが取れた理由)
• GID: audio / camera
マイク / カメラの完全な操作権が得られてしまう
• その他 (Bluetooth 周りなど)

影響 (2 of 2)
• “mediaserver” プロセスの権限を奪われる
• アプリ固有のデータには基本的にアクセスできないが……
• 当プロセスは各種メディア処理に関する
数々の特権を持っている!
• 同プロセスで動くサービス : AudioFlinger
音声出力を全て握られる
• また、関連するデバイスノードに対する直接アクセス権を
持っていることにも注目すべきかもしれない
(端末依存だが、root 化などの危険性が比較的高い)
• 一部端末では他の (さらに危険な)
特権が割り当てられていることがある
• Drake 氏のスライド (英語) 参照

緩衝要素? (1 of 2) : SEAndroid
• NSA などによる SELinux の拡張で、
Android 固有の Binder なども保護対象に
• Android 4.3 で追加
(ただしログは出すが違反を止めない Permissive モード)
• Android 4.4 で違反を阻止する Enforcing モードに
• こちらは権限拡大や一部の攻撃を阻止する
役目があるはずのだが……
• 権限拡大の前の “正当な” 権限が既に十分広い
• (デバイス依存だが) カーネル脆弱性を突かれると
SEAndroid が (SELinux 含め) 突破されてしまう
• Android 4.4 においては、mediaserver 動作ドメインは
事実上 SELinux が無効である! (permissive + unconfined)
• Android 5.0 においてまだマシなポリシーに

SEAndroid@すこしがんばる?
• 必要な権限以外を見ていくと… (Android 5.0)
• 良いところ
• Permissive でも Unconfined でもない (ポリシー制限有効)
• シェルの起動はできない
• 前提条件のうちひとつ、execute 権限がない (target: shell_file)
• その他多くのツール (target: system_file)も execute 権限があったとしても
execute_no_trans 権限* がないために起動できない
• 自身や非特権アプリが書き込めるファイルは実行禁止
• 共有ライブラリとしてのロード (mmap) 含む
• 悪いところ
• 自身に execmem 権限が付与されている*
* execute_no_trans 権限は、ドメイン (権利区分) を移動せずに実行できるか否かを示す権利。
例えば多くのシェル向けツールは実行元と同じ権限で動作した方が良いが、
そのような動作は execute_no_trans によって支配される (ドメイン移動する場合は transition と entrypoint)。
* execmem 権限は自プロセスの書き込み可能だったデータ領域を実行できるようにするか否かを示す権利。
これがないと JIT が使えないが、一方で大きなコードを実行可能にする攻撃の一部が防ぎやすくなる。
なお、領域によっては execstack / execheap (brk 周りの領域のみ) / execmod によっても追加チェックされる。

緩衝要素? (2 of 2) : ASLR
• 今回使用した脆弱性の場合、
ASLR (非専門家向けの喩え: 分身の術) による
攻撃の信頼性低下を図ることができる??
• Android 4.0 にて追加 (+ 開発者サイトにて宣伝) されたが、
その時点では不完全 (2 つの実行可能モジュールが固定)
• Android 4.1 において完全な ASLR が有効に
• 実行ごとにメモリ配置をわざとランダムにする
実行 1
実行 2
実行 3
攻撃者は非常に精密に
メモリを破壊しなければならないが…
特定アドレス (白色) を狙おうとしても
なかなか当たらない

ASLR@(あまり)がんばらない
• しかし、攻撃が不可能ではないことに注意
• (別途) 実行中のポインタ漏洩に関する脆弱性の利用
• mediaserver はクラッシュ後すぐ再起動し、アプリ実装に
よっては何事もなかったかのように継続実行するため……
ASLR などを突破できるまで叩き続けることが可能!
• 先ほど、Web 攻撃が成功した理由
• ASLR は、一度攻撃に失敗すれば次の攻撃が
不可能か、少なくとも不連続になる暗黙の前提がある
• この場合、攻撃失敗が見た目上わかりにくく、
かつすぐに再攻撃を行うことができるため、
ASLR の安全性の根拠が崩壊する

まとめ : 技術的要素
• 攻撃ルートは色々ある
• 影響は単一アプリの範囲を超えてしまう
• カメラ、マイク、スピーカーの完全制御含む
• 緩衝要素も色々ある
• が、ルートによっては攻撃を十分緩衝できない (SE+ASLR)
• 攻撃が成功するとその後の緩衝要素 (SEAndroid) によらず
ある程度実用的な応用が行えてしまう
(今回は Zimperium のデモとは別種のインパクトを!)

混乱編
報道の混乱と、そこから生まれる反省

Stagefright 報道に関する混乱
• 軽重はあれど、数々の報道において
さまざまな混乱が生じてしまった
• 考えられる要因
• 報道記者の知識不足 (全部これのせいなら話は簡単だが…)
• セキュリティ研究者と一般人の本質的な視点の差
• 国などの事情を考慮した “ローカライズ” 不足
• 特に、この脆弱性の
攻撃ルートとして有名となった MMS は、
3 つの要因すべてに基づく混乱を引き起こした
• “混乱編” では特にこれについて詳しく見ていこう
• その前に、問題ある報道が行われた他のトピックを……

問題 (1) : 影響はアプリ権限?
• 要因はおそらく、この種の脆弱性の “一般的な”
影響範囲からくる思い込み
• Engadget Japanese のようなニュースサイト1 でも
間違いが拡散されてしまった
• 恥ずかしながら、私も当初勘違いしていた……
• Stagefright が直接アプリ内で動作するなら、
影響範囲は当初アプリ内に限られる
(それでも攻撃可能なアプリや経路を考えると深刻だが)
• 実際にはプロセス間通信した先がやられるので、
広い範囲に影響が出てしまう可能性がある
• カメラ権限を持たないアプリへの攻撃が
カメラへのアクセスに直接つながるなど
1. http://japanese.engadget.com/2015/07/27/android-95-mms/

問題 (2) : MMS 送信履歴の消去?
• 一部報道において MMS 送信履歴を
バックグラウンドで消去できるという言及がある
• 可能性は否定できないが、少なくともそれは
デバイス依存もしくは複数脆弱性を用いている!
• media ユーザーは root でも system でもないため、
Android システム全体を好きにコントロールすることは
(基本的に) 直接は不可
• しかし、Drake 氏によれば一部の端末においては
mediaserver に system GID が割り当てられている
(system UID と等価ではないがそれに迫る権限)

問題 (3) : MMS 攻撃の権限
• 一部報道において MMS 経由で攻撃すると
“より高い” 権限を得られるという言及がある
• おそらくこれは、Drake 氏によるスライドの
“SILENT, REMOTE, PRIVILEGED” の誤訳 / 誤解釈
• MMS でもそれ以外でも得られる権限は同じ

問題 (4) : MMS 無効化が対策? (1 of 2)
• 結論 (前提):
日本においては MMS 無効化は十分有効な
緩和策と言い切れず、無効化後も攻撃手段が残る
• 問題については、(大人気ないが)
まず私が怒った記事を再度見てもらう
• 95％のAndroid端末にMMSを受信するだけで端末を乗っ取ら
れる脆弱性が発覚、対策はこれ – GIGAZINE 1
• この記事を斜め読みしたり
タイトルで内容を判断した場合、何が起こる?
• 最後から二番目の段落だけは私が GIGAZINE に
抗議した結果 “大幅に修正” されている
• これは不誠実な記事だったが、
誠実な記事でも悲劇は終わらない……
1. http://gigazine.net/news/20150728-android-hack-stagefright/

問題 (4) : MMS 無効化が対策? (2 of 2)
• MMS 無効化が緩和策になるというのは多くの
セキュリティニュースすら書いてしまっている
• ……が、日本においては安定した緩和策になるか微妙
(ローカライズの問題)
• それに限らず、MMS という単なるひとつの
攻撃ルートが、報道によって注目されすぎている
• 確かに、MMS という攻撃ルートは “より深刻” ではある
(セキュリティ技術者と一般人との視点の差の問題)
• だが、報道がそこに偏りすぎると、日本以外においても
攻撃の対象が MMS だけに矮小化されてしまう
(報道記者が伝えるべき部分を外してしまった問題 + α)
• “正確”、“十分” かつ “バランス良く” 記述していた
日本語の主要ソースは 8 月末時点で 1 つ1 のみ!
1. http://blog.trendmicro.co.jp/archives/12060 (速報の後で、正直あまり広まらなかった……)

MMS : そもそも MMS とは?
• SMS の制限 (140 文字) を突破できる
(3GPP/OMA 標準の) 携帯電話用
メッセージングサービス
• SMS と同じような電話番号宛の送受信も、
“メールアドレス” 形式での送受信もサポート
• ただし規格上キャリア間の相互接続方式を厳密に定めておらず、
かつ相互接続はキャリア間の協力によって行われるものであるため、
通信に関わるキャリアの内情によって制限が生じうる
• メディアファイルの添付をサポート
• 含 : MPEG-4 ムービー
• 受信通知は特殊な SMS によって行う
(この SMS の処理方法によって自動/手動受信が決まる)
• この SMS による遠隔コントロール / 遠隔通知は、
MMS に限らず幾つかのプロトコルにて行われる

MMS : 日本における MMS
• Docomo : 非サポート (iOS 含む)
• au (KDDI) : iOS 用回線でのみ? サポート
(粗い端末調査によると MMSC がセットされていない)
(端末デフォルトでは MMS は無効)
• SoftBank : サポート
• SoftBank 回線以外では
いわゆる “緩和策” は何の効果も持たない
• 安定した緩和策とは言い切れない
• MMS 以外の攻撃ルートも丸々残っている
• 日本でこの問題を取り上げられた tripleshot さん1 曰く……
“「だが日本ではMMSを受信可能なAndroidはスマートフォンユーザ全体の
わずか8%である！」とも書けます。(とても恣意的！)”
1. http://tripleshot.hatenablog.com/entry/2015/07/28/222103

MMS : 注目の理由
• ユーザーの入力を全く必要としないから
• 例えば一般的な攻撃ルートでは、ユーザーを騙すなどして
ユーザーに何らかの操作を行わせなければならない
• あるいは、攻撃ができる条件を頑張って整えなければならない
• MMS は勝手に送りつけることができ、
しかも (自動受信が有効なら) 受信段階で攻撃が
発動するため、攻撃者にとって極めて使い勝手が良い
• 脆弱性の深刻度を単純な判定によって
スコア化する CVSS1 の version 3 では、このような
点を “User Interaction” として取り込んでいる
1. https://www.first.org/cvss

MMS : 過剰な注目
• とはいえ攻撃ルートの 1 つでしかないことから、
ここを過度に強調するべきではなかった
• 一般に、脆弱性の対策 / 緩和のためには
直面するあらゆる、少なくとも主要なすべての
攻撃ルートを意識する必要がある
• だが MMS は、日本以外においても
主要なすべての攻撃ルートとはいえない
• 専門家の発表と一般向けであるべきメディアの
間にそれぞれの視点の差があることに注意
• セキュリティ技術者が MMS に対して注目するのは、
ある面では正しいし “普通” なことである
• が、一般人の保護のために必要なのは
専門家によって注目されたその点だけではなかった

MMS : 反省点
• 緩和策として紹介する際は、少なくとも
国などに応じたローカライズを行うべきであった
• “ローカライズ” は単なる “翻訳” に留まらない!
• 報道に際して、特に緩和策の紹介に関しては
日本固有の事情を考慮した上で紹介すべきだった
• 緩和策をした上で残るルートにも注意を払うべきだった
• 常に、“偽の安心感” をもたらす行為を避けるべき
• 攻撃ルートは、ある程度
網羅的に注目するべきであった
• ひとつの攻撃ルートだけが注目されすぎると、
他の攻撃ルートに対する注目が疎かになりがち
• これは、セキュリティ技術者とメディアの双方が
取り組むべき課題だと考える

未来編
これからどうするべきか……
答えを示さずとも (比較的) 良い例は既にある

Android 端末の 90% 以上という脅威
• 決して無視して良いものではない
• しかも、起因が共通部分であることに注意
• Android の “深刻な” 脆弱性の多くは、
Android 起因というよりは (言い切れない)
各種ベンダーによる変更に起因する場合が多かった
• ベンダーサポート用アプリに意図的な
(しかもベンダー以外まで悪用可能な粗雑な造りの) バックドア
• ドライバに初歩の初歩と言わんばかりの
バッファオーバーフローがあったり……
• 端末がアップデートされるのかという懸念
• Android 端末を名乗る上でセキュリティアップデートの
期間は基本的に定められているものではない
• サポート期間の問題は iOS (というか Apple 製品全般) にも

Android : 月例アップデート?
• Google と Samsung が
セキュリティアップデートを毎月 OTA 配信へ1
• しかも一定期間のアップデートを保証するという!
• それ自体はたいへん喜ばしいこと
• サポート期間の明確化
3 OS の中で Windows Phone 以外のそれは不明確だった
• 定期的サポートの確約
機能アップデートにくっつけてセキュリティ
アップデートをするようなことに伴う遅延が避けられる
• ……が、これを多くの製造者が適用しようとすると
ひとつの問題に直面することになる
1. http://jp.techcrunch.com/2015/08/06/
20150805google-and-samsung-will-now-release-monthly-ota-android-security-updates/

Android : Update Hell for OEM
• 前提 : アップデートは主に製造者の役割
• もちろん製造者に責任を求めるのは簡単だが……
• 製造者にかかる責任 / 負担が大きすぎる!
• 製造者は端末に合わせて、Android の
“全て” をコンパイルしなければならない
(共有可能な部分がかなりあるにも関わらず!)
• 例: 各種 ARM 用 Linux ディストリビューション
大きなアーキテクチャ差やハードウェア依存のものを別として
多くのパッケージをバイナリ的に共有することができている
• 製造者の責任にないセキュリティアップデートまで
都度の対応を要求される
• 私は、Google やその他の企業の協力によって問題が
ある程度は (全てではない) 乗り越えることが可能だと考える

共通のユーザーランドの例
• Arch Linux ARM on...
• Raspberry Pi 2 Model B
SoC : Broadcom
• USB Armory
SoC : Freescale

モジュラーアップデート (1 of 4)
• システムのレイヤーを明確に分割
(共通部分と端末固有部分のパッケージ化)
• それぞれを独立してアップデート可能にする
• バグが生じがちなベンダー固有部分の問題は
解消されないが、バグが発生した時広い問題になる
共通部分に関してアップデートの負荷を軽減する
Android 端末
カーネル (Type A)
共通部分 oem.ko 共通
userland
OEM
固有部分
大まかなハードウェア差で
カーネルは分ける必要があるだろう
それぞれパッケージ化し
個別アップデート可能にしていく
* あくまで理想論だが、そうなってくれると嬉しい図

• 例 : Windows Phone (7-8)
• コア部分は Microsoft が完全に権限を握り、
製造者は基本的にその下の OEM 権限のみを得る
• それぞれのアップデートがモジュール化されている
• ただし、アップデートの有無自体は
キャリアが主にコントロールしているらしい
• そのためアップデートを拒否されることもあったとか
(例: Verizon は WP8 の “Cyan” アップデートを継続的に拒否) 1
• 例 : Windows 10 Mobile (発表時点では予定)
• キャリアではなく Microsoft 自身が
ほぼ全てのアップデートをコントロールするようになる1
1. http://www.zdnet.com/article/microsoft-says-its-taking-over-updates-for-windows-10-mobile-devices/

• 例 : Ubuntu Touch
• こちらについては私が詳しく中身を
調べたわけではないが……
• Canonical の Michael Hall 氏曰く……1
• システム全体を複数レイヤーで構成している
• OEM レイヤーに影響を与えずに
ベースシステムのアップデートを行うことが可能である
1. http://news.softpedia.com/news/ubuntu-touch-support-will-be-provided-as-long-as-technically-possible-488449.shtml

• もちろん、欠点もある
• 弱いハードウェアへのロック
例 : Windows Phone (Qualcomm 製ハードウェアへの依存)
• どちらかというと “どう集中させるか” の問題
• おおむね問題ではない……はず
• カスタマイズ性の低下
• Android にはハードコードされた部分はそこそこある
• そのため、現状の設計 “そのまま” ではモジュラー化は難しいかも
• 組み込み系では高速化などのために複数レイヤーのソースコードに
手を入れるカスタマイズテクニックが紹介されている
• 例: 動画再生においてメモリコピーを避けるための
OpenMAX コンポーネントを超えた Android ソースコード自体への手入れ
• ベンダー固有部分はやはりベンダー責任
• カスタマイズに起因する脆弱性もやはり多い
(最近だと Check Point が指摘した Certifi-gate1 など)
1. http://www.itmedia.co.jp/enterprise/articles/1508/07/news064.html

まとめ
混乱を克服し、Stagefright 脆弱性に終止符を打つために

まとめ (1 of 3) : 誤解を解消する
• 攻撃ルートは MMS だけではない
• 矮小化された攻撃者像を是正することが必要
• 攻撃後権限はアプリではない (アプリに留まらない)
• root 化抜きでも、実用的なスパイ行為が、
カメラやマイク権限抜きのアプリからも行える
• Google の主張する ASLR による保護は、
今回の場合不十分かもしれない
• クラッシュによる再起動が見た目には分からない場合、
ASLR の安全性の根拠は事実上崩壊する
• その場合、ASLR を “回避” する必要すらない

まとめ (2 of 3) : 将来につなげていく
• 今回は紛れも無く最大規模の
Android セキュリティ修正となりうる
• (ほぼ) Android 固有
• かつ、Android 間で共通
• 対象バージョンがかなり広い
• 根本的な解決はアップデートのみであるため、
どうユーザーに浸透させるかが直近の課題
• 申し訳ない、今回はうまく触れられなかった!
• 将来的には、Android のアップデートに関して
責任分割と負担軽減の仕組みが必要になるだろう
• 現実にある例 : モジュラーアップデート

まとめ (3 of 3) : “伝わる” 報道のために
• 著しい誤解を生む (特に偽の安心感を生む) 報道は
正しい対処を行う上で極めて有害
• 脆弱性に関する報道について、今回のような
混乱を避けるためには技術者とメディアの協力は
もはや必要不可欠といえる!
• 脆弱性に関して、“過不足なく” 伝わる報道を行うため
• 第三者による独立検証や補助も必要となるだろう
• 今回とは逆に、発見者によって深刻だと宣伝されながら、
実際には深刻な影響がかなり考えにくいケースが複数あった
(e.g. GHOST)
• 国などの状況に沿った情報提供
• 一般人の視点で有益な情報発信をしていこう!

END_OF_TRANSMISSION
ご清聴ありがとうございました!
Special Thanks : Mr. Joshua J. Drake (@jduck)
Presented by : Tsukasa OI (大居司; @a4lg)
http://a4lg.com/
Email (フィードバック) : feedback_2015_stagefright@irq.a4lg.com

おまけ
技術的な情報が少なくて気に入らない人のために
注: 専門家向け

インデックス
• Slide 73
• 算術オーバーフロー (Java / C# の場合)
• Slide 74-78
• Slide 27 : 脆弱な C++ コードの答え合わせ
• Slide 79-82
• ヒープオーバーフローの悪用と ROP
• Slide 83-85
• SEAndroid と mediaserver
• Slide 86-91
• 日本における報道とその分析?

整数オーバーフロー (Java / C#)
• Java / C# いずれにおいても、
整数オーバーフローを検出しない場合の結果は
2 の補数表現で高位ビットを切り捨てた結果
• C# は checked ステートメントの使用により
整数オーバーフローを検出可能である
• 逆に unchecked を用いた場合意図的に検出しない
• Java 8 は java.lang.Math クラスに
整数オーバーフローを検出するメソッドを追加
• addExact / multiplyExact など
• Android では現在使用不可

new の隠れたオーバーフロー (1 of 5)
• new 演算子による配列確保はときに危険である
• ISO/IEC 14882:1998 (C++98) の段階では new 演算子による
配列確保内の整数オーバーフローによって
何が起こるかが規定されていなかった
• (脆弱性含め) ほぼ同じセマンティクス
• int* intarray = new(std::nothrow) int[size];
• int* intarray = (int*)malloc(sizeof(int) * size);
• new 演算子は size_t 引数の
allocation function (確保関数) を呼び出すと規定されている
• 配列を含めて、SIZE_MAX が確保できるオブジェクトの最大サイズ
• これに対して、コンパイラ、C++ 規格
双方で対処が行われている
• 規格で対処が行われているのは非常に興味深いし、
プログラムを安全にする上で役立つこと
明示的な整数オーバーフロー
暗黙の整数オーバーフロー

• gcc 4.8 や Visual C++ 2005 において、
隠された整数オーバーフローに歯止めをかける
独自機能が搭載された
• サイズがオーバーフローしたとき (Visual C++ 2005)
またはオーバーフローしそうなとき (gcc 4.8)、
代わりに SIZE_MAX を確保させようとして
わざとメモリ確保を失敗させる
• Clang 3.0 以降にも同様の機能が搭載される
(機能は Visual C++ 2005 に類似)

• ISO/IEC 14882:2011 (C++11) において、
整数オーバーフロー防止のための規定が追加された
• 5.3.4 [new 演算子] 第7パラグラフより引用、翻訳:
(前略) 確保されるオブジェクトのサイズが実装によって定義された
限界を超えうる場合、(中略) メモリ領域は取得されず、
std::bad_array_new_length 型のハンドラにマッチする例外を
送出することによって new-expression は強制終了される。
• これは new によって呼ばれる allocation function の
例外送出の有無 (nothrow_t) とは無関係に規定されるため、
new(std::nothrow) でも例外が送出される
• C++11 において例外ハンドリングをきちんと行う必要がある場合、
この点については新しく注意する必要がある
• つまり、C++98 において等価だった前述コードは
C++11 においてはもはや等価ではない

• ISO/IEC 14882:2011 (C++11) において、
• しかし、本発表時点で厳密に準拠している
コンパイラは gcc 4.9 以降のみ
• しかも、gcc 4.9 においても Android NDK 版では
この仕様に (なぜか) 準拠していないことを確認
• 厳密に C++11 規格に準拠しないコンパイラは、
std::bad_array_new_length にマッチする例外を送出しない
• 代わりに、allocation function が SIZE_MAX という
事実上の無効値を受け取る可能性がある
• Visual C++ 2015 製品版は非準拠
• Clang 開発版は一時的に準拠したものの、
別の問題があったらしく再び非準拠に戻っている1
1. https://llvm.org/bugs/show_bug.cgi?id=11644

• ISO/IEC 14882:2011 (C++11) において、
• 規定の細部に注意しよう
• 限界を “超える” ときではなく “超えうる” ときであり、
かつ実装依存の限界は SIZE_MAX とは限らない
• gcc 4.8 以降の実装はアドレス空間の約半分
(SIZE_MAX のおよそ半分) を実装依存の限界と定め、かつ
正確な限界ではなく 7-bit 精度の近似整数で比較を行う
• つまり、実際にアドレス空間の半分や全部を占めない場合でも
オーバーフローとみなされる場合がある
(この挙動は直感に反するが、間違いなく C++11 規格に準拠)
• これはおそらく、任意即値の代入が効率的でない
一部のアーキテクチャ (ARM 含む) に合わせたものであろう
• Clang と Visual C++ は SIZE_MAX を “超える” ときに処理

ヒープオーバーフローの悪用 (概要)
• 可能性としては色々あるが……
• 直接書き換え
• ヒープで近い関係にあるデータを直接書き換えて
プログラムのフローを攻撃者の好きに誘導する
• 特にポインタの上書きは直接攻撃にかなり近い
(脆弱性と exploit の性質によって異なるが)
• 間接的な攻撃
• ヒープアロケータ自体を攻撃対象とする (アロケータ依存)
• dlmalloc (Android 4.4 まで)
• jemalloc (Android 5.0 以降)
• 古典的な dlmalloc に対しては複数の上書き手法が知られており、
オーバーフローを用いて任意アドレスに
任意の値を書き込むことが可能な場合がある
• 私のものも Drake 氏のものも直接書き換えベース

ヒープオーバーフローと ROP (1 of 3)
• スタックオーバーフローとの比較
• スタックオーバーフロー:
• canary (SSP) さえ通過していれば ROP に
直接つながる場合が多い
• ヒープオーバーフロー
• スタック書き換えができない場合、直接 ROP に
移ることができない (戻りアドレス書き換えができていないため)
• 定番は関数ポインタの書き換えだが、
単に関数に移るだけでは “任意” コード実行には結びつきにくい
• そのため、スタックポインタを操作するための
stack pivot という手段が用いられるケースが多い
• 9月9日見せたデモ動画では時間の制約上
良い stack pivot が見つかっていない状態で
強引なコード実行を行っていた

• “Android Hacker‘s Handbook” 1 において、
Android 4.0 における有望な stack pivot が
指摘されている
• Drake 氏曰く Georg Wicherski 氏が指摘したものとのこと
• __restore_core_regs (動的リンカー中)
• libgcc の一部で、レジスタの unwind を行う関数
• R0 (第一引数) と PC (関数ポインタ) を操作できる場合、
16 レジスタ中 15 個を任意の値に設定することができる
• R0 はレジスタ書き換えのためのバッファ
• PC は __dl_restore_core_regs またはこれを呼び出す箇所
• SP と PC を適切に書き換えれば ROP 実行可能
• Android 4.0 の動的リンカーは固定であるため、
条件さえ整えば ASLR 回避が容易
1. http://as.wiley.com/WileyCDA/WileyTitle/productCd-111860864X.html (ISBN: 978-1-60864-7)

• ただし、すべてのバージョンにおいて
無条件に使えるわけではない
• Galaxy Nexus のイメージ解析によれば
このガジェットが linker 内にあるのは Android 4.2 まで
• Android 4.1 以降では完全な ASLR が有効であるため
linker 上にあることが特に便利とは言い切れない
• これらの場合でも、条件次第では
代替の stack pivot を検索することが十分可能
• mmap に対する ASLR はベースアドレスの
オフセットを基盤としているため、
条件さえ整えば大量のガジェットを検索可能
• また、__restore_core_regs は
libc 等他のライブラリでも見つけることが可能

SELinux + mediaserver (1 of 3)
• Android 4.4 (r1) のソースコードより全文:
external/sepolicy/mediaserver.te
# mediaserver - multimedia daemon
type mediaserver, domain;
permissive mediaserver;
type mediaserver_exec, exec_type, file_type;
net_domain(mediaserver)
init_daemon_domain(mediaserver)
unconfined_domain(mediaserver)
mediaserver ドメインを
Permissive モードに
mediaserver ドメインに対して
ほぼ? 全ての動作を許可
(unconfined ドメインに設定)
Permissive ドメインの場合、
ポリシー違反が起こると
dmesg にログが出力される

• Android 4.4 (r1) のソースコードより全文:
external/sepolicy/unconfined.te
allow unconfineddomain self:capability_class_set *;
allow unconfineddomain kernel:security ~load_policy;
allow unconfineddomain kernel:system *;
allow unconfineddomain self:memprotect *;
allow unconfineddomain domain:process *;
allow unconfineddomain domain:fd *;
allow unconfineddomain domain:dir r_dir_perms;
allow unconfineddomain domain:lnk_file r_file_perms;
allow unconfineddomain domain:{ fifo_file file } rw_file_perms;
allow unconfineddomain domain:socket_class_set *;
allow unconfineddomain domain:ipc_class_set *;
allow unconfineddomain domain:key *;
allow unconfineddomain fs_type:filesystem *;
allow unconfineddomain {fs_type dev_type file_type}:{ dir blk_file lnk_file sock_file
fifo_file } ~relabelto;
allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file } ~{entrypoint
relabelto};
allow unconfineddomain node_type:node *;
allow unconfineddomain node_type:{ tcp_socket udp_socket rawip_socket } node_bind;
allow unconfineddomain netif_type:netif *;
allow unconfineddomain port_type:socket_class_set name_bind;
allow unconfineddomain port_type:{ tcp_socket dccp_socket } name_connect;
allow unconfineddomain domain:peer recv;
allow unconfineddomain domain:binder { call transfer set_context_mgr };
allow unconfineddomain property_type:property_service set;
unconfined ドメインに対しては
非常に多くの権限が
開放されてしまっている!
(Permissive と違いログすら出ない)

• Android 5.0 以降ではまだマシなポリシーに
• Permissive ドメインでも
unconfined ドメインでもなくなった
• しかし、それを回避することなく
色々できることはデモにおいて示した通り

日本における報道 : 分析 (1 of 2)
• この分析に関する情報
• 一連のスライドの記述およびソースの再確認は
9月11日から12日にかけて行った
• 時系列と記事クオリティの “改善”
• 7 月に書かれたものは、すべて “落第”
• 発表の “翻訳” の鵜呑みや、不十分な “対策” の流布
• 8 月以降の記事は技術的に正確な分析なものが
多くなっている
• しかし、MMS の “バランスの悪い” 強調を
十分に止められているとは私は考えていない
• 9 月には私の挙げる 3 条件を満たす記事も少数登場
• 攻撃ルートに関する、
“正確さ” “十分さ (網羅されているか否か)” “バランスの良さ”

日本における報道 : 分析 (2 of 2)
• 初動の悪さ?
• ソーシャルメディアの投稿を大まかに調べると、
多くの人が MMS 無効化を対策として信じる
様子が見受けられる (8 月以降の記事に言及した場合含む)
• ソーシャルメディアの一部において、MMS の無効化が
“対策” になるという空気が醸成されてしまっていた
• 8 月以降の記事 (の一部) の良さを考えると、
初動 (速報) の悪さが尾を引いてしまっている可能性がある
• 改めてソースを分析
• そこまで “悪くない” 報道も多数
• しかし、ソーシャルメディアにおいて醸成された
空気を入れ替えるには至っていない
• 次スライドから良くも悪くも目立った主要ソースを紹介

日本の主要ソース分析 (1 of 4)
• GIGAZINE
• 言及 (2 記事):
• 95％のAndroid端末にMMSを受信するだけで端末を
乗っ取られる脆弱性が発覚、対策はこれ
• 95％ものAndroidがTwitterのリンクをクリック
するだけ・動画再生するだけで乗っ取られる
「Stagefright」攻撃への対応が始まる
• 良いところ
• 情報ソースの選定自体は適切に見える
• 特に後者のソースは攻撃ルートに対する十分かつ正確な言及を含む
• 悪いところ
• 前者における、いわゆる “タイトル釣り”
• しかも、前者には “偽の安心感を生みかねない言及” を含む
• 私にこの資料を書かせたきっかけ (1 of 2)
• 前者の記事についての言及を Twitter で見たのが全ての始まり

• Security Next
• 言及 (1 記事):
• Androidに深刻な脆弱性、MMSで攻撃受けるおそれ
• 良いところ
• 発表に忠実
• 悪いところ
• 発表に忠実
• この速報記事以外を出していない
• 私にこの資料を書かせたきっかけ (2 of 2)
• この言及だけで済ませてしまうことは明らかにマズい
(一般人の保護に十分役立たない)
• この記事以降にフォローアップがあれば良かったが、
情報セキュリティニュースサイトであるにも関わらずそれが無かった

• ASCII.jp + McAfee Blog
• 言及 (1 記事):
• メッセージだけで感染!? 95%のAndroidユーザーに影響する脆弱性
• 良いところ
• MMS 以外の “攻撃” を十分に示せていないものの、
攻撃ルートについては示唆できている
• 悪いところ
• 不十分な “ローカライズ” (翻訳の鵜呑み)
• 日本においては有効に機能しない可能性のある “ヒント” についての言及を含む
• 技術的に十分な対策ができていない製品の宣伝
• McAfee Mobile Security の動作原理上、
当該製品は十分に有効な対策は取れていない (かつ、取れない)

• マイナビニュース
• 言及 (5 記事):
• 「MMSに気をつけろ」って
どういうこと? - いまさら聞けないAndroidのなぜ
• Androidの脆弱性、
応急処置は「MMSメッセージの自動取得無効化」 - Lookout
• 良いところ
• 技術的な分析に関する記述はほぼ正確
• Lookout の記事をソースにするものは
攻撃ルートに関する正確かつ十分な言及を含む
• 悪いところ
• MMS という攻撃ベクトルの “不適切な” 強調
• MMS 以外の攻撃ベクトルに関する記述は MMS に比べて目立たない

さらば、Stagefright 脆弱性

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to さらば、Stagefright 脆弱性

Similar to さらば、Stagefright 脆弱性 (20)

Recently uploaded

Recently uploaded (10)

さらば、Stagefright 脆弱性