Downfall攻撃
(downfall.page)- 個人用・クラウドコンピュータで広く使われるIntelプロセッサの CVE-2022-40982 脆弱性で、同じコンピュータを共有する別ユーザーのデータを盗むことができる
- 脆弱性の核心は、メモリ最適化の過程で Gather命令 が推測実行中に内部ベクタレジスタファイルの内容を露出させる点にある
- 攻撃は GDS・GVI 手法で実装され、デモではAES鍵、Linux Kernelデータ、表示可能な文字の監視まで、隔離境界を越えた漏えいが示されている
- 影響範囲はIntel Core第6世代Skylakeから第11世代Tiger Lakeまでで、クラウド利用者はIntelデバイスを直接所有していなくても影響を受ける可能性がある
- Intelの マイクロコードアップデート はGatherのtransient結果を遮断するが、一部のワークロードでは緩和策適用後に最大50%のオーバーヘッドが発生しうる
Downfallが狙う脆弱性
- Downfallは、個人用コンピュータやクラウドコンピュータで使われる最新プロセッサの 重大な弱点 を標的とする
- この脆弱性は CVE-2022-40982 として識別されている
- 同じコンピュータを共有する別ユーザーのデータにアクセスして盗むことができる
- アプリストアから入手した悪意あるアプリが、パスワード、暗号鍵、銀行情報、個人メール、メッセージなどの機密情報を奪取できる
- クラウドでは、悪意ある顧客が同じクラウドコンピュータを共有する他の顧客のデータや認証情報を盗むことができる
脆弱性の技術的原因
- Intelプロセッサの メモリ最適化機能 が、内部ハードウェアレジスタをソフトウェアに意図せず露出させる
- 信頼できないソフトウェアが、本来アクセスできないはずの他プログラムのデータにアクセスできる
- メモリ上に散在するデータをより高速に読み取るための Gather命令 が、推測実行中に内部ベクタレジスタファイルの内容を漏えいさせる
- これを悪用する手法として Gather Data Sampling(GDS) と Gather Value Injection(GVI) が使われる
- 技術的詳細は Downfall論文 にまとめられている
デモで確認された漏えい事例
- Downfallのデモは、異なる隔離境界を越えて機密データが漏えいしうることを示している
影響を受けるシステムと攻撃条件
- 影響を受けるデバイスは、Intel Core第6世代 Skylake から第11世代 Tiger Lake までのプロセッサをベースにしたコンピューティングデバイスである
- より包括的な影響対象プロセッサ一覧は、Intelの affected processors一覧 で提供予定である
- 物理的なIntelベースデバイスを持っていなくても、クラウド利用者は影響を受ける可能性がある
- Intelのサーバー市場シェアは70%以上である
- 攻撃者は、パスワードや暗号鍵のような 高価値の認証情報 を狙う可能性がある
- 認証情報の窃取は機密性の侵害にとどまらず、コンピュータの可用性や完全性を損なう他の攻撃につながりうる
- GDSは実際の攻撃として実装しやすい部類である
- OpenSSLから暗号鍵を盗むend-to-end攻撃の開発には2週間かかった
- 攻撃者と被害者が同じ物理プロセッサコアを共有すればよい
- プリエンプティブマルチタスクと同時マルチスレッディングを実装した現代のコンピュータでは、このような共有は頻繁に発生する
隔離境界、SGX、ブラウザへの影響
- Downfallは一般的な隔離境界にも影響する
- 仮想マシン
- プロセス
- ユーザー・カーネル分離
- Intel SGX も影響を受ける
- Intel SGXは、悪意あるソフトウェアからユーザーデータを保護するためのIntel CPUのハードウェアセキュリティ機能である
- Webブラウザ経由のリモート悪用は理論上可能である
- 実際にブラウザで成功する攻撃を示すには、追加の研究とエンジニアリング作業が必要である
露出期間と検知の難しさ
- ユーザーは少なくとも 9年 にわたりこの脆弱性にさらされていた
- 影響を受けるプロセッサは2014年から存在している
- Downfall攻撃は検知が難しい
- 実行形態の大半が通常のアプリケーションのように見える
- 理論上は、ハードウェア性能カウンタを使って過剰なキャッシュミスのような異常挙動を検知するシステムを構築できる
- 一般的な商用アンチウイルスソフトウェアではこの攻撃を検知できない
緩和策と性能オーバーヘッド
- Intelは マイクロコードアップデート を配布している
- このアップデートはGather命令のtransient結果を遮断する
- 攻撃者コードがGatherから得られる推測データを観測できないようにする
- 緩和策のオーバーヘッドは、プログラムの重要な実行パスにGatherがあるかどうかで変わる
- Intelによれば、一部のワークロードでは最大 50%のオーバーヘッド が発生しうる
- ワークロードがGatherを使わないからといって緩和策を無効にするのは安全ではない
- 最新CPUは、メモリコピーやレジスタ内容の切り替えといった一般的な処理の最適化にベクタレジスタを使用する
- この過程で、Gatherを悪用する信頼できないコードにデータが漏えいする可能性がある
公開スケジュールと再現コード
- この脆弱性はほぼ 1年 にわたりエンバーゴ状態だった
- Intelには2022年8月24日に報告された
- Downfallは2023年8月9日の BlackHat USA と、2023年8月11日の USENIX Security Symposium で発表された
- 再現コードは GitHub POC で公開されている
他のプロセッサ設計者が注意すべき点
- 他のプロセッサも、コア内部にハードウェアレジスタファイルやfill bufferのような共有 SRAMメモリ を持つ
- メーカーは、異なるセキュリティドメイン間でデータが漏えいしないよう、共有メモリユニットをより慎重に設計する必要がある
- セキュリティ検証とテストにさらに投資すべきである
名称と関連脆弱性
- Downfallという名前は、コンピュータの基本的なセキュリティ境界の大半を崩すことに由来する
- Downfallは、CPUの過去のデータ漏えい脆弱性である Meltdown と Fallout の後継と見なせる
- この流れの中で、Downfallは従来の緩和策を再び回避する
ベンダー勧告と技術文書
- セキュリティ勧告:
- MITRE: CVE-2022-40982
- Intel: INTEL-SA-00828
- AWS: AWS-2023-007
- GCP: GCP-2023-024
- Debian: CVE-2022-40982
- Ubuntu: CVE-2022-40982
- Red Hat: CVE-2022-40982
- VMware: Gather Data Samplingへの対応
- Intel技術文書:
1件のコメント
Hacker News の意見
初期の Spectre 攻撃の後も、外部の研究者が似たような攻撃を見つけ続け、チップメーカーが後からパッチを当てる流れには奇妙さを感じる
原則としては、チップメーカーこそが投機的実行の専門家であり、チップの挙動を正確に理解し、検証スイート、シミュレーター、機械可読な内部仕様まで持っているのだから、発見には最も有利なはず
外部研究者はブラックボックスを探索し、特許のようなはるかに劣る資料をもとにリバースエンジニアリングしなければならないのに、それでも数年たった今も個人や外部グループがこうした脆弱性を見つけている
Spectre 以前はこの種の攻撃ベクトルを考慮できなかったのかもしれないが、一般的なメカニズムが明らかになった後なら、チップメーカーは最も優秀な人材を集めて「徹底的に調べて、ほかの Spectre 系攻撃を見つけろ」と言うべきだったのではないかと思う
もしかすると、すでにすべて把握しているが、面目と性能低下を避けるため、公開されないことを願って隠しているだけなのかもしれない
何十億人もが使うものなら、作った側よりも多くの問題、欠陥、エクスプロイトを見つけるだろうと思う。そうした問題が存在するという事実だけで、その理由について追加の結論を支持したり反証したりはできない
セキュリティ研究者には、名声を得るために何かを見つけ出す動機がある。現実の攻撃者にはほとんど意味がないにもかかわらず、世界を揺るがすセキュリティ脆弱性のように主張することはよくある
実環境で 投機的実行攻撃が見つかったことはあるのか。おそらくないかもしれない。そうだとすれば、チップベンダーがここに巨額の費用を投じる理由は弱い
実際の顧客は、外部研究者が対策を強制して性能を低下させる新しいマイクロコードを出させる時を除けば、被害を受けない
この種の攻撃の緩和策には常に無効化スイッチが付いている点も注目に値する。セキュリティ修正でよく見られる形ではないが、多くの場合、これらの攻撃はあまり重要ではないからだ
同じ物理コアや同じ物理 CPU 上で動くソフトウェアは信頼レベルが同じか、攻撃を実行できないほど強力にサンドボックス化されている
Intel は疑いなくチップを「可能な限り賢く」作っており、したがって定義上、完全にはデバッグできない
これらはバグではないという点も重要だ。設計は意図どおりに動作している。CPU が以前に実行したコードによって性能が変わることは理解されていたし、代替案のコストが電力、性能、面積の面で大きすぎると判断され、受け入れられていた。それがエンジニアリングであり、代替案を比較衡量して選ぶということだ
この場合、CPU が十分に高速になったことで、反復あたりのごく小さなビット数が攻撃可能な帯域幅になったが、業界がそれを理解するには誰かが実証する必要があった。それがエンジニアリング上の判断を変えた
Intel の論文リンクが切れており、正しいリンクはこちらのようです: https://www.intel.com/content/www/us/en/developer/articles/t...
一般的な注意点として、今でも異なるユーザーのワークロードを同じ物理コア上で動かしているクラウドは多いのでしょうか？ ほとんどは数年前にスケジューラを変更し、ハイパースレッド間のクロスドメイン漏えいを防いだと思っていました。
インターネット上のすべてのユーザーに影響するという主張は、かなり誇張に見えます。ブラウザベースのエクスプロイトも見当たりませんし、仮に存在しても、標的にされたごく少数のユーザーにしか影響しないでしょう。Spectre が出てから何年も経ちますが、実環境で投機的実行攻撃が見つかったことがあったのか疑問です。
もっと興味深いのは、こうした投機的実行バグが引き続きマイクロコードでパッチ可能に見える点です。最初に登場したときは、物理チップを大量に廃棄して交換しなければならないかもしれないという不安がありましたが、実際にそうする必要があったことはあったのでしょうか？
私の知る限り、すべてのバグはソフトウェアとマイクロコード変更の組み合わせで対処可能で、場合によってはいくらかの性能コストを払っただけでした。新しいシリコンが必要だったバグはありませんでした。例外があるとすれば、初期の AMD SEV バージョンのように、実際にパッチ不能な形で脱獄されたケースくらいです。
もちろん AWS の T シリーズのように共有するものもありますし、他のクラウドにも似たものはあるでしょうが、ユーザー間に追加の「フラッシュ」を挟むことで、テナント間の漏えいを防げるはずだと思います。
当然ながら、単一テナント内のプロセス間漏えいはクラウドでもオンプレミスでも問題であり、結局は自分のマシン上のプロセスが悪意あるものに変わらないとどれだけ信じるかを決める必要があります。
異なるセキュリティドメインのコードを同じ物理プロセッサコアで実行することは、きちんとやるのは不可能に見えますし、もうやめるべきだと思います。
よくあるケースは実質的に VM と JavaScript の 2 つだけです。
VM は諦めるべきです。特定のコアを特定の VM、少なくとも特定の顧客専用に割り当てる必要があります。
JavaScript はもう少し難しいです。
いずれにせよ、一般的なケースで性能を犠牲にしてはいけません。
IOPU はシステム内の他のハードウェアを指揮する役割を担い、高性能である必要はありません。
SPU は高速に動く必要があるスカラーコードや分岐の多いコードに最適化します。
SPU は RAM から取得するときに任意のメモリを読めないようにする程度の最小限のセキュリティだけ備えれば十分です。一度に 1 つのプログラムしか実行しないので、投機的実行は問題にならないでしょう。
私のシステムでは多くの処理能力を必要とするプログラムはほとんどなく、必要な場合でも断続的なので、SPU でのタスク切り替えは多くなさそうです。
こうした CPU 攻撃は、ユーザーが任意の機械語コードを実行する安全なタイムシェアリングシステムが、もはや現実的ではないことを示しています。
同じプロジェクトの作業者がビルドマシンを共有するように、互いを信頼している場合のタイムシェアリングは今後も残るでしょう。
コンピューター上で実行される 2 つのプログラムが互いを覗き見できないようにできる、という考えもそのレベルです。
Intel セキュリティ勧告: https://www.intel.com/content/www/us/en/developer/articles/t...
Linux カーネルへのマージ: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
第11世代までしか影響しないということは、この脆弱性がIntelに公開された時点が、第12世代で修正できるほど早かったとは思えない。だとすると、別の何かを直しているうちに偶然解決されたのかなと思う
論文を見ると、「IntelはAlder Lake、Raptor Lake、Sapphire Rapidsのような最新CPUは影響を受けないと述べている。ただし、セキュリティ上の考慮というより、大きく変わったアーキテクチャの副作用のように見える」とある
結局、ランダムに直ったか、少なくともこの特定のエクスプロイトが動作しなくなったということになる
FAQによると、ユーザーは少なくとも9年間この脆弱性にさらされていた。影響を受けるプロセッサが2014年から存在していたため
こうした脆弱性が何年も目立たないままで、誰かがエクスプロイトをコーディングするのには2週間しかかからないという点が驚き
LWNの記事参照: https://lwn.net/Articles/940783/
Linuxでは、更新されたマイクロコードがないCPUについて、この問題の緩和策としてAVXが完全に無効化される。自分の感覚ではかなり厳しく、体感も大きそう。更新されたマイクロコードを受け取れるのか調べたくなってきた
gather_data_sampling=forceを使う場合にのみ適用される。デフォルトはAVXをそのままにして、システムが脆弱だと表示することhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...を見ると:
gather_data_sampling=forceを指定すると、可能な場合はマイクロコードの緩和策を使い、その緩和策が含まれるようにマイクロコードが更新されていない影響対象システムではAVXを無効化するちなみにIntelでLinuxの仕事をしている。人々を混乱させるドキュメントや変更ログを自分が書いたか、手を入れた可能性が高い
[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12Haswellを使っている。どのCPUが更新されたマイクロコードを受け取るのか、一覧はあるのだろうか。残念
GCPがこの問題にパッチを当てた点も参考になる: https://cloud.google.com/support/bulletins#gcp-2023-024
AWSのお客様のデータとインスタンスはこの問題の影響を受けず、お客様が行うべき対応もない
AWSは、この種類の問題に対する保護を備えたインフラを設計・実装している。Lambda、Fargateおよびその他のAWS管理型コンピュート・コンテナサービスを含むAmazon EC2インスタンスは、マイクロコードとソフトウェアベースの緩和策によって、GDSからお客様のデータを保護している
性能への打撃が非常に大きい。最大50%と主張され、最近のIntelプロセッサの70%が影響を受けるという
https://access.redhat.com/solutions/7027704
性能への影響は、Intel Advanced Vector Extensions（AVX2およびAVX-512）が提供するgather命令とCLWB命令を使うアプリケーションに限定される。実際の性能影響は、アプリケーションがそれらの命令をどれだけ多く使うかに依存する
ユーザーが徹底したリスク分析の後に緩和策をオフにすると決めた場合、たとえばシステムがマルチテナントでなく、信頼できないコードを実行しないなら、緩和策を無効化できる
マイクロコードとカーネル更新を適用した後、カーネルコマンドラインに
gather_data_samping=offを追加すれば緩和策をオフにできる。また、GDSを含むすべてのCPU投機的実行緩和策をオフにするにはmitigations=offを使えばよい「最大」という主張は常に疑ってかかるべき
NES には 6502 全体が埋め込まれたチップセットが入っていたし、ピザ1枚分の値段で、ダイ上に混載コアを載せた Rockchip ARM チップを買える。チップメーカーがあらゆるエッジケースを永遠に解決し続ける必要はなく、こうした サイドチャネル攻撃の緩和を、チップを消費する私たちの側に戻してもいいのかもしれない
SMT を全部オンか全部オフかの選択にするのではなく、信頼できないコードは「しょぼいコア」に送り、顧客に SMT のあるコアへ上げてもよいことを「証明」させるのはどうだろう？
誰も、他のものを同じボードに載せられないような超重要な給与計算ジョブを走らせるチップを台無しにしたいわけではない。だが、SMT 上で安全に実行できるものにタグ付けすることを強制され、そうでなければより安全なコアに縛られる、というのは悪くない
こういうものが何なのかまったく知らないインターンが検索して、この攻撃ベクトルの本当の意味を学び、防御計画を立てることもあり得る
私がおかしいのだろうか？
性能コア × 効率コアは可能だ
だが、信頼コア ×「しょぼい」非信頼コアを提案する人にはなりたくないはずだ。利点がどれだけ多くても、「不安をあおっている」という言説の中に埋もれてしまうだろう。人生とはそういうものだ