Meltdown＆Spectre-パッチを適用していないハイパーバイザーのゲストカーネルにパッチを適用すると、仮想マシン間のメモリリークが防止されますか？

12

脆弱性の大規模なリリースの24時間後、RackspaceはSpectreとMeltdownについて沈黙しています。Xenハイパーバイザーのすべてにパッチを適用する計画はありません。新しいプラットフォームサーバーはすべてHVMサーバーであり、脆弱性があります。古いPVサーバーは脆弱ではありません。

HVMゲストのLinuxカーネルを更新しましたが、Rackspaceはハイパーバイザーを更新していません。パッチを適用していないハイパーバイザーでゲストカーネルを更新すると、「悪意のある」VMがパッチを適用したホストからリークしたメモリにアクセスできなくなりますか？

— ダニー・F
ソース

1

security.stackexchange.com/q/176709/11291

— マイケル・ハンプトン

12

脆弱性について私が理解していることから、いや-投機的キャッシング攻撃は、任意のアドレスからメモリを取得するプロセスに対するCPUの保護をすべてバイパスします。

これには、ハイパーバイザーのカーネルメモリスペースだけでなく、近隣のVM（攻撃自体から保護するためにパッチを適用したものも含む）が含まれると考えています-しかし、直接的なメモリ開示から保護するものがなくても、潜在的な可能性もあります攻撃者はカーネルメモリへのアクセスを使用して、ハイパーバイザーへのより完全なアクセスを取得できる可能性があります。

実行されているすべてのVMを信頼していない場合、パッチを適用していないハイパーバイザー上で機密ワークロードを実行するリスクは絶対に避けた方がよいでしょう。

— シェーン・マッデン
ソース

6

簡単に言うと、パッチを適用したゲストカーネルがあると、 VMがハイパーバイザーや他のVMにアクセスできなくなる可能性がありますが、他のVMがアクセスすることはできません！

— マイケルハンプトン

こんにちはシェーン、それも私の信念です。それをバックアップするドキュメントはありますか？特に、同じハードウェア上の他のゲストに対して脆弱なパッチを適用したゲストのメモリに関するポイント。ありがとう。

— ダニーF

2

@DannyFこれに対する最も直接的な参照は、メルトダウンペーパーにありました -「他のプロセス、カーネル、およびカーネル共有サンドボックスソリューション（Docker、LXCなど）または準仮想化モードのXenの物理メモリ、カーネル（またはハイパーバイザー）のメモリ、および他の同じ場所に配置されたインスタンス」

— シェーンマデン

-4

スペクターとメルトダウン。

どこから始めますか？悪い、私はあなたのコンピューター、ワークステーション、サーバーまたはクラウド内のサーバーに影響を与える可能性のある何かの非常に悪いプレスリリースを意味します。はい、完全にそうですが、PCや携帯電話などのCPUにローカルアクセスする必要があります。Appleは例になっていますが、ARM CPUを考えてみましょう。 / microcode Exposure / OS / etc / etcからCPUを制御しすぎる

アプリケーションはデバイスのCPUで実行する必要があるため、コンソールアクセス、または少なくともシステムにアクセスするリモートユーザーは、デバイスアクセスを入力すると思います。

現時点では、これらの脆弱性を悪用する唯一の既知の方法は、ローカル/ CPUに直接アクセスすることです（SSH / VNCなどを取得したら、リモートにすることもできます）

以下は、私がこれまでに見つけたパッチです。

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

今、これは現在の問題に対する最善の対応でなければなりません

BSDの友人は何と言いましたか？

悪いグーグル;（

同じのためのPowershellチェック;）

Linux Kernel OK

この投稿を編集する場合があります。私は、問題ではない（野生になるまで）が本当の問題ではないことを確信しています。グーグルはここで公開のリリース日を本当に守っていたはずです！Googleの場合は-1

— アンドリュー・スモーリー
ソース

「Amazon Linux（AMI）」はAmazonのLinuxディストリビューションであり、他のすべてのゲストオペレーティングシステムと同じように影響を受けます。このコンテキストでは、EC2の発表（仮想化プラットフォーム）のaws.amazon.com/de/security/security-bulletins/AWS-2018-013（最初のセクション）に関連性があります。仮想化ソリューションをリストしようとしているようです。

— ホーカンLindqvist

1

これを読んで、もう一度読んで、私はそれが実際に質問に対処するとは思わない？それはほとんど開示プロセスについての暴言ですか？

— ホーカンLindqvist

編集と修正のリンクに感謝しますが、この答えは誤解を招くか、少なくとも混乱を招きます。これは、説明したシナリオではxenserverハイパーバイザーへのローカルアクセスが必要であることを示していると思いますが、これは正しくありません。唯一の要件は、被害者のVMと同じハイパーバイザー上に独自のVMを持つ悪者です。

— ダニーF