OracleVM 3.2：xen（OVMSA-2017-0178）

high Nessus プラグイン ID 105251

Language:

概要

リモートのOracleVMホストに1つ以上のセキュリティ更新プログラムがありません。

説明

リモートのOracleVMシステムには、重大なセキュリティ更新に対処するために必要なパッチがありません：- 2a99aa99fc84a45f505f84802af56b006d14c52e 2001年9月17日月曜日00:00:00以降送信者：Andrew Cooper 日付：2016年8月19日金曜日15:08:10 +0100 件名： [PATCH] xen/physmap：ゲストが自分のためにPoDページを配置することを許可しない PoDはゲストに対し完全に透過的であると想定されていますが、このインターフェイスは長時間曝されたままでした。PoDを使用するには、toolstackによるXENMEM_[get,set]_pod_targetハイパーコールおよびxenstoreバルーンターゲットとの注意深い連携が必要です。ゲストがtoolstackの連携をクラッシュさせずにできる最善策です。さらに、toolstackが明示的に禁じられるような失敗の組み合わせ（たとえばc/s c63868ff 「libxl：PoDが有効時にHVMゲストへのPCIデバイス割り当てを許可しない」）があります（この場合は、両者が単に組み合わせで機能しないため）。そのような場合、ゲストはtoolstackが選択した構成を覆すことはできません。競合：xen/common/memory.c - 履歴のパフォーマンス上の理由で、以前のOVM製品のPoD機能は無効化されることになりました。maxmem>memoryとなるようには設定しないでください XSA-246、XSA-247 [bug 27120669]（CVE-2017-17044, CVE-2017-17045）- x86/shadow：sh_guess_wrmapでのSH_LINEARマッピング検出を修正 XSA-243/CVE-2017-15592（c/s bf2b4eadcf379）の修正によりsh_guest_wrmapの挙動に変化が導入され、シャドウ線形マッピングがない場合にも対処する必要がありました。その名が示唆するように、guest_vtableはゲストのpagetableのマッピングで、Xenのpagetableのマッピングではありません。つまり、シャドウ線形スロットインのチェックをする必要があるのはpagetableではありません。実際的な結論は、4レベルページングモードに切り替わり、XenのSH_LINEAR_PT_VIRT_STARTをエイリアスするマッピングを含むL4 pagetableを持つシャドウHVMは、SHADOW_LINEARマッピングがあるかどうかを調べる安全チェックをだます、ということです。チェックが行われない場合（失敗した場合）、Xenは次に示すようなpagefaultを持つ欠落しているマッピングで停止します：（XEN） ffff8140a0503880から外れるページテーブル：（XEN）L4[0x102] = 000000046c218063 ffffffffffffffff（XEN）L3[0x102] = 000000046c218063 ffffffffffffffff（XEN）L2[0x102] = 000000046c218063 ffffffffffffffff（XEN）L1[0x103] = 0000000000000000 ffffffffffffffff これはXSA-243の一部です。（CVE-2017-15592）- dpci：MSI割り込みのバインド解除の間の競合状態を修正 hvm_irq_dpci->マッピングおよびフラグの読み取りのチェックは同じ重要領域では保護されないため、MSI割り込みのバインド解除により両者の間での傍受を引き起こす可能性があります。たとえば次の状況です：CPU0 CPU1 ---- ---- hvm_do_IRQ_dpci !test_bit(mirq, dpci->mapping)) return 0 spin_lock(&d->event_lock) hvm_irq_dpci->mirq[machine_gsi].flags = 0 clear_bit(machine_gsi, hvm_irq_dpci->mapping) spin_unlock(&d->event_lock) <SoftIRQ> hvm_dirq_assist spin_lock(&d->event_lock) if ( pt_irq_need_timer(hvm_irq_dpci->mirq[pirq].flags)) set_timer spin_unlock(&d->event_lock) その後、初期化されていないタイマー構造にアクセスするset_timerが誤って呼び出されます。次にページフォルトが発生し、以下のようなバックトレースが生じます： (XEN) Xen call trace: (XEN) [<ffff82c480124c92>] set_timer+0x92/0x170 (XEN) [<ffff82c48013bb03>] hvm_dirq_assist+0x1c3/0x1e0 (XEN) [<ffff82c4801235ff>] do_tasklet_work_percpu+0x7f/0x120 (XEN) [<ffff82c480121915>] __do_softirq+0x65/0x90 (XEN) [<ffff82c4801f7fb6>] process_softirqs+0x6/0x10 (XEN) (XEN) Pagetable walk from 0000000000000008: (XEN) L4[0x000] = 0000002104cc1067 0000000000289430 (XEN) L3[0x000] = 000000212ecd8067 00000000002b3447 (XEN) L2[0x000] = 0000000000000000 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 41: (XEN) FATAL PAGE FAULT (XEN) [error_code=0002] (XEN) Faulting linear address: 0000000000000008 (XEN) **************************************** OVM3.3以降ではpt_pirq_iterateにおいて既に同様の修正があるため、この問題はOVM3.2のみです。