- WhatsApp は、30億人以上のユーザーを抱えるサービスとして、Rustベースのセキュリティ層を導入し、マルウェア脅威への防御力を強化した
- メディア整合性ライブラリを Rustで再実装 し、数十億台のデバイスとブラウザに展開して、グローバル規模での実運用検証を完了した
- 既存の C++ コード16万行を Rust 9万行 に置き換え、性能とメモリ効率の両方が改善された
- 2015年の Stagefright脆弱性 以降、メディアファイル処理の安全性を高めるため、Rustのような メモリ安全言語 の導入を進めてきた
- この変化は、WhatsApp・Messenger・Instagram全体のセキュリティ戦略において、メモリ安全言語の比重を拡大する転換点となる
WhatsAppのメディア処理戦略
- WhatsAppは、30億人以上が利用する エンドツーエンド暗号化メッセージングサービス であり、継続的なセキュリティ脅威への対応のために戦略を進化させてきた
- ユーザーが画像・動画などのメディアを共有する際、マルウェアが含まれている可能性がある
- 一部のファイルは、OSやアプリの 未修正の脆弱性 を悪用できる可能性がある
- これを防ぐため、メディア共有機能に Rust言語 を導入し、メモリ安全性を確保した
- これは世界的に見ても最大規模の Rustベースのライブラリ展開事例 とされる
2015年のAndroid Stagefright脆弱性と対応
- 2015年の Android の Stagefright脆弱性 は、OSレベルのメディア処理ライブラリに存在しており、アプリ側では修正できなかった
- WhatsAppは自社の C++ ライブラリ 「wamedia」 を修正し、MP4標準に従わないファイルを検出 できるよう改善した
- これにより、OSアップデートがなくてもユーザーを保護できた
- しかし、wamedia が 信頼できない入力を自動処理 するという性質から、メモリ安全言語への移行の必要性が提起された
Rustへの移行: 大規模な再実装と成果
- WhatsAppは、既存の C++ 版と並行して Rust版の wamedia を開発した
- 差分ファジング(differential fuzzing)、統合テスト、単体テストによって、両実装間の互換性を検証した
- 当初は Rust 標準ライブラリによる バイナリサイズの増加 や ビルドシステムとの互換性 の問題があったが、長期的な支援体制を構築した
- 結果として C++ 16万行 → Rust 9万行 に置き換えられ、性能とメモリ使用効率の両方が改善された
- Android、iOS、Mac、Web、ウェアラブルなど すべてのプラットフォームで Rust版の完全展開 を完了した
- その後 「Kaleidoscope」システム を導入し、PDF、実行ファイルなどの危険なファイル種別を検出し、拡張子の偽装や MIME スプーフィングを識別している
WhatsAppのセキュリティアプローチ
- WhatsAppは エンドツーエンド暗号化、暗号化バックアップ、鍵の透明性、通話保護機能 など、多様なセキュリティ層を運用している
- CVE公開、社内外のセキュリティ監査、ファジングと静的解析、サプライチェーン管理、攻撃面分析 を通じてリスクを特定している
- Bug Bountyプログラム を拡張し、研究者が WhatsApp のネットワークプロトコルを分析できる Research Proxy を提供している
- 主要な脆弱性の多くが C/C++ のメモリ安全性の問題 に起因することを確認し、3つの戦略を並行して進めている
- 不要な攻撃面の最小化
- 残存する C/C++ コードのセキュリティ保証を強化
- 新規コードの基本言語を メモリ安全言語 に切り替え
Rust導入の加速と今後の方向性
- Rustは、WhatsAppの 高性能・クロスプラットフォームなセキュリティライブラリ 開発を可能にした
- この変化は、ユーザーには見えない追加のセキュリティ層 を提供するものであり、多層防御(defense-in-depth) 戦略の一環である
- WhatsAppとMetaのセキュリティチームは、Rustの高効果な適用領域 を拡大しており、今後 Rust採用を加速 する計画だ
1件のコメント
Hacker Newsのコメント
WhatsAppは1日あたり30億人が使うメッセンジャー
米国ではあまり使われていないが、世界的には基本的なコミュニケーションインフラとして定着している
グローバル市場向けに製品を作りたいなら、こうしたユーザーの考え方や習慣を理解する必要がある
こういう独立した人間はまだ数十人はいる
どうかWhatsAppをさらに避けられないものにすることには加担しないでほしい
ほとんどの人はメールをほぼ確認しない
開発者コミュニティを運営しているが、グループ人数制限（1024人）にしょっちゅう引っかかる
DiscordやSlackへ移そうとしても、結局またWhatsAppに戻ってしまう
通信キャリアのデータバンドルのおかげで、WhatsAppが事実上無料だからだ
企業メッセージのスパムに関する記事がTechCrunchに何度も載っているが、実際にはほとんど何も変わっていない
コミュニティ機能のUXも今ひとつだ
結局、Facebookエコシステムへの依存が深まるのが問題だと思う
私は10年間WhatsAppを使っておらず、友人や家族の大半もSignalへ移った
ヨーロッパでは今でもViberが使われている地域もある
Rustで書かれたライブラリの中で最大規模のデプロイだと言っていたが、実際にはFontationsのほうが大きいかもしれない
Chromiumに含まれており、その依存関係まで見ると、インストールベースはより広い可能性がある
引用文を見る限り、WhatsAppはlibsignalを直接使っていないようだ
例: image-png, CrabbyAvif, qr_code, icu4x
コードが16万行から9万行に減ったのも良いが、並行ロールアウト戦略のほうがさらに興味深い
Rust版とC++版を同時に動かし、differential fuzzingで等価性を検証した点が現実的だ
モバイルクライアントではバイナリサイズが重要だが、ビルドツール群に投資した点も印象的だ
nightlyビルドでしかできない最適化かもしれない
この手のリライトで最も難しい部分は、Rust実装そのものよりも既存パーサーのバグ互換性を維持することだ
実際のメディアファイルはフォーマットが壊れていることも多く、厳密に解析しすぎるとユーザーデータが壊れる
differential fuzzingは事実上唯一の実用的アプローチだ
WhatsAppがRustで最大のデプロイをしたというのは、Windows 11より多くの端末で動いているからだろう
ただしWhatsAppがlibsignalを直接使っているのかは疑問だ
Android自体がすでにRustベースのコードを多く含んでおり、組み込み機器でも広く使われている
Windowsは依然としてC/C++中心だ
Rust標準ライブラリの導入でバイナリサイズの増加があったと言うが、どう解決したのかは明記されていない
関連コミット: commit1, commit2
問題はサイズそのものより重複したRust依存関係だ
C++とRustが混在するビルドでは、それぞれがlibstdを含むため、Bazelのような統合ビルドシステムが必要になる
当初は約200KiBのオーバーヘッドを受け入れていたが、Buck2への移行でサイズとビルド時間の両方を削減した
最新のclang最適化とLTO改善のおかげだ
Signalも似た試みをしているのか気になる
libsignalはRustで実装されているが、それ以外の部分はよく分からない
「30億人にデフォルトでエンドツーエンド暗号化を提供する」という文言があったが、実際にはメッセージを読めるというニュースもあった
Skypeもデフォルトでは暗号化されていたが、サーバー設定次第で無効化できた
Metaがデータを覗き見しないと信頼できるかが問題だ
Metaはフィッシングやプリペイドカード詐欺は止めないのに、別のことには熱心なのが皮肉だ
Rust導入でバグが大幅に減った点が印象的だ
C++には無数の未定義動作(UB) が存在するが、Rustはそれを構造的に防ぐ
強力な型システムのおかげで信頼性が大きく向上する