世界を動かす技術を、日本語で。

スケールでのRust: WhatsAppのための追加のセキュリティ層

概要

  • WhatsAppが Rust製の新しいセキュリティレイヤー を導入
  • メディア一貫性ライブラリ をRustでグローバル展開
  • Stagefright脆弱性 を契機に独自防御策を強化
  • Kaleidoscope による多層的なファイル検査・防御
  • 今後も Rust採用拡大 とセキュリティ強化を推進

WhatsAppにおけるRust導入によるセキュリティ強化

  • WhatsAppは 30億人超 のユーザーに デフォルトでエンドツーエンド暗号化 を提供
  • サイバー脅威に対抗するため、 防御戦略の継続的な進化 を実施
  • ユーザーが 画像・動画・ドキュメント を共有する機能に潜むリスクへの対策
  • 一見無害なファイルに隠された 高度なマルウェア への警告と検出
  • OSやアプリの 未修正の脆弱性 を突く攻撃への対抗策

Stagefright脆弱性とメディアファイル保護の転機

  • 2015年、Androidの Stagefright脆弱性 が発覚
  • OS提供のメディアライブラリに依存していたためアプリ側でのパッチが困難
  • ユーザーのOSアップデートが遅れるリスクを回避する必要性
  • WhatsApp独自の wamedia(C++製) ライブラリを活用し、MP4標準外ファイルの検出機能を追加
  • OSアップデート不要で 迅速なユーザー保護 を実現

Rustによる大規模なメディア処理ライブラリ再構築

  • C++からRustへの並行開発 を選択し、互換性担保のため 差分ファジング・テスト を徹底
  • Rust標準ライブラリ導入による バイナリサイズ増加 や多様なプラットフォーム対応の課題
  • 16万行のC++コード9万行のRustコード に置き換え、パフォーマンス・メモリ効率も向上
  • Android、iOS、Mac、Web、ウェアラブルなど 多様なプラットフォームに展開
  • Rustによる メモリ安全性とセキュリティ向上 を実現

多層的なファイル検査システム「Kaleidoscope」

  • ファイル構造の 非準拠チェック で下流ライブラリの脆弱性悪用を防止
  • PDF内の埋め込みファイルやスクリプト の検出など、リスク指標で追加チェック
  • 拡張子やMIMEタイプ偽装 の検知
  • 実行ファイルなど危険度の高いファイル をUIで特別扱い
  • Kaleidoscopeにより 非公式クライアントや悪質な添付ファイル からユーザー保護

Rust導入による運用と今後の展望

  • 毎月、 数十億台の端末・ブラウザ にRust製ライブラリを配布
  • 世界最大規模の Rustコード展開事例
  • Rustは クライアントサイドの本番運用に耐えうる言語 であることを実証

WhatsAppのアプリセキュリティ全体戦略とRustの役割

  • エンドツーエンド暗号化やバックアップ暗号化キー透明性技術 など多層的なセキュリティ
  • CVE報告 やバグバウンティ、外部監査、ファジング、静的解析など多角的なリスク特定
  • C/C++由来のメモリ安全性問題 が高リスクの主因であることを分析
  • 攻撃対象領域の最小化、C/C++コードのセキュリティ保証、 新規コードはメモリ安全言語(Rust等)を標準採用
  • CFI、メモリアロケータ強化、安全API など追加防御策
  • C/C++開発者への 専門セキュリティトレーニング や自動解析、厳格な修正SLA

Rust採用拡大と今後のセキュリティ強化

  • Rustにより 高性能・高安全なクロスプラットフォームライブラリ を構築
  • 防御層のさらなる強化と 裏側でのユーザー保護 を推進
  • WhatsAppおよびMetaのセキュリティチームが Rust導入の機会を積極的に推進
  • 今後も Rust採用の加速 とセキュリティ強化に注力

Hackerたちの意見

すごいね!Signalも似たようなことやってるのかな?libsignalはRustで実装されてるけど、他の部分はどうなんだろう。

「私たちは、これはRustで書かれたライブラリの中で、世界的に見ても最大の展開だと信じています。」たぶんこれが真実だと思う。WhatsAppを使ってる電話の数は、Windows 11のPCよりも多いからね。WhatsAppがlibsignalを使ってることを考えると、彼らがRustライブラリを直接使ってないって考えてもいいのかな?

WhatsAppはlibsignalを使ってないし、AndroidはもうかなりRustが使われてるよ。WhatsAppよりも世界中に展開されてるし(スマホだけじゃなくて、カスタムAndroidで動いてる「組み込み」用途もたくさんある)。

「MicrosoftはRustに慣れてきている:成功と課題のレビュー」を見ると、全体の取り組みはAzure側に偏ってるみたいだね。GDI領域みたいな控えめな採用はあるけど、Windows側でのRustの採用はあまり進んでない。まだまだCとC++の対立が続いてる感じ。

こういうリライトの一番難しいところは、実際のRustの実装よりも、レガシーパーサーとのバグ互換性を維持することだね。現実のメディアファイルはほとんどが何らかの形で不正だから、C++のコードが暗黙的に処理してた部分がある。厳密なパーサーを書くと、正しいユーザーデータを壊しちゃうことになる。差分ファジングが、その挙動を手動で何百万ものエッジケースをレビューせずにマッピングする唯一の実用的な方法みたいだね。

この「wamedia」のデザイン目標は、メディアプレイヤーとのバグ互換性を_維持しない_ことみたいだね。

AIの返信?

かなり印象的だね。こんなに多くのバグがメモリアクセスに起因してるとは知らなかった。

公平に言うと、Rustのコードの信頼性がC++よりも高いのは、メモリエラー(境界外アクセス、解放後使用、型混乱など)だけが理由じゃないよ。他にもいろいろあるんだ。* 未定義動作がない(unsafeの外では、これはかなり避けやすい)。C++には、メモリエラーとは直接関係ない未定義動作の原因がたくさんある、例えば符号付き整数のオーバーフローや関数からのreturnを忘れることとか。* より強力な型システム。これら二つの要素は、信頼性にかなり大きな影響を与えるんだ。

「初期のバイナリサイズの増加は、Rust標準ライブラリを取り入れたことによるものでした。」彼らはこれについて何をしたか言ってないよね?ただ受け入れたのかな?

記事全体がちょっと薄っぺらい感じがするから、技術的なプレゼンテーションというよりPRとして読んだよ。

たぶんそうだね。バイナリごとに約300KBで、一度きりのコストだよ。標準ライブラリを無効にすれば完全に回避できるけど、それは不便だから、通常は組み込みデバイス向けに書くときだけだね。問題はサイズそのものじゃなくて、C++とRustが混在するコードベースでのRust依存関係の重複なんだ。ビルドシステムのサンドイッチ(C++ => Rust => C++ => Rustみたいなライブラリ依存関係があるとき)になっちゃうと、各Rust/Cargoビルドがlibstdやクレートのコピーをバンドルしちゃう。だから、リンカーがそれを整理できるようにするか、Cargoの代わりにBazelを使ってRustとC++の依存関係を一つの依存関係ツリーの一部として扱う必要があるんだ。

何をしたのかは分からないけど、できることはいろいろあるよね。https://github.com/johnthagen/min-sized-rust

たぶん、適用できるときはno_stdを使ってるんじゃないかな。https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee... https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba... コンパイラとリンカーの操作をしっかり管理すれば、バイナリサイズを最適化する方法はたくさんあるみたいだね。

この数字を下げるために、システム最適化にかなり投資したけど、最初はstdlibのサイズオーバーヘッドとして約200KiBを受け入れたんだ。最初はGradle + CMake + Cargoを使って、stdlibを静的リンクして基本的なリンカー最適化を行った。WhatsApp AndroidをBuck2に移行したことで、LTOの改善や最新のclangツールチェーンの最適化が進んで、サイズを大幅に減らすのに役立ったよ。Buck2はビルド時間も大幅に改善したしね。

GoogleのRust-in-Androidブログと同じように、これもPR記事っぽい(Facebookの場合はリクルート的な要素もあるけど)で、技術的な言葉がちょっと散りばめられてる感じ。全体的なコミュニケーションの質は、ランダムなスタートアップの「私たちがやったこと」みたいな投稿と同じレベルだね。供給チェーン攻撃からの防御方法や、C++コードとRustコードを多くのプラットフォームでどう統合したのかといった興味深い点は、謎のままだ。AI駆動の開発がどれくらい使われたのかも聞いてみたいな。AIがRustに本当に強くなって、面倒な構文に直接触れなくて済むようになるといいな。

こういう記事の目的は、Rustの採用に対する信頼性を高めることだよね。Rustはまだ業界全体で広く採用されているわけじゃなくて、小さなプレイヤーは大手企業がうまくいくと示した既存の技術しか使わないことが多いから。Rustは避けられないものじゃないし、こういう記事は将来の業界での採用に必要なんだ。

供給チェーン攻撃に対する保護方法などの興味深い側面 これに対処するための標準的な技術があって、言語を問わず適用できるから、そのホイールを再発明する必要はないよ。 > 私の希望は、AIがRustに本当に優れてきて、直接その使いにくい構文と対話しなくても済むようになること。「使いにくい構文」は、新しい言語を学ぶのを抵抗する多くの人の叫びだね。でも、AIはその学習プロセスを手助けできるくらい進化してるよ。

160kから90k LOCの削減はいいけど、並行展開の方がもっと面白い部分だね。C++版と並行してRustを動かして、差分ファジングで同等性をチェックするのは、「書き直して祈る」よりもずっと現実的だよ。古いシステムをバックアップとして使いながら、段階的に検証できるからね。切り替える前にどれくらいの期間両方を動かしてたのか気になるな。クライアント側ではバイナリサイズが本当に重要だし、サーバーではRustの標準ライブラリのオーバーヘッドはあまり問題にならないけど、何十億ものモバイルデバイスに出荷するとなると、毎KBが重要だよね。膨張を受け入れるだけじゃなくて、ビルドツールに投資してるのは良いことだね。

どこかで彼らが何をしたか言ってた?ビルドの一部として標準ライブラリを再構築すると、使う量によってはかなり小さくなるけど、それはまだナイトリー版だけだね。もしかしたら、no_stdにしたか、自分たちのを作ったのかな?

「WhatsAppは30億人以上にデフォルトのエンドツーエンド暗号化を提供しています。」最近、彼らがまだメッセージを読めるってニュースがなかったっけ?

すべての暗号化は、端末やメタデータにこだわらなければエンドツーエンドだよ。Facebook(あ、Metaね)を信じて、メッセージを覗き見しないし、「情報」機関と共有しないと思う?

WhatsAppは端末でメッセージを抜き取ることができるかも。でも、「デフォルト」って言葉にトリックがあると思う。Skypeもエンドツーエンド暗号化がデフォルトだったよね、特定のユーザーのためにサーバーフラグが無効にされていない限り(詳細はあやふやかも)。

私たちは、これはRustで書かれたライブラリの中で世界的に最大の展開だと信じています。今のところその冠は、Chromiumに含まれているhttps://github.com/googlefonts/fontationsにあると思うけど、全プラットフォームにあるかは不明。さらに、Fontationsの翻訳依存関係(https://crates.io/crates/fontations/0.3.0/dependenciesをクリック)も、さらに(少し)大きなインストールベースを持っているはず。追記:引用からも、彼らがhttps://github.com/signalapp/libsignalを使っていないことがわかるね。

Chromiumに搭載した他のRustライブラリもいくつか紹介するね:- https://github.com/image-rs/image-png - https://github.com/webmproject/CrabbyAvif - https://github.com/RCasatta/qr_code - https://github.com/unicode-org/icu4x

参考までに、Wamediaは主要なMetaアプリやiOS、Android、デスクトップ、ウェブプラットフォームで展開されてるよ。

毎日安全にメッセージを送るために30億人以上。WhatsAppは30億人のデイリーアクティブユーザーを持つチャットアプリだよ。アメリカにいる人たち(WhatsAppはあまり使われてないけど)には、これは覚えておく価値がある事実だね。世界の他の地域向けに製品を作りたいなら、そのユーザーたちがどう考えて、どう息をしているのかを知る必要があるよ。30億人の中で、WhatsAppが彼らの会話の手段なんだから。

これについてどうすればいいの?その数字を下げること以外にね。(頑固にインストールを拒否しているヨーロッパ人として聞いてるけど、私たちが何人かいるんだよ。何十人も!)追記:WhatsAppを今以上に避けられない存在にするのはやめてほしいな。

確かに、でもほとんどのことと同じで、NA/EUで実際にお金を生むのはせいぜい2億人くらいかもね。

この説明ってFacebookそのものを指してるんじゃない?アプリもそれに似た感じにすべきなの?だって、全く正反対だと思うけど。