The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..., opennews (??), 23-Фев-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


66. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/–
Сообщение от Аноним (65), 23-Фев-20, 19:42 
Видимо, кто-то не понимает, что публичные багрепорты так не делаются.
Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +2 +/–
Сообщение от Аноним (-), 23-Фев-20, 20:07 
> Видимо, кто-то не понимает, что публичные багрепорты так не делаются.

Багрепорт как багрепорт. Просто кодеры из опенки по сравнению с Максом детвора детворой. Зато визгу от openbsd и хайпа на весь мир. Хотя последние несколько месяцев какая-то контора показала, что баги в нутрях опёнка довольно примитивные. NetBSD и то будет защищённее (даже согласно статам на cvedetails).

Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/–
Сообщение от Аноним (-), 23-Фев-20, 21:03 
> последние несколько месяцев какая-то контора показала, что баги в нутрях опёнка
> довольно примитивные. NetBSD и то будет защищённее (даже согласно статам на cvedetails).

У более приличных проектов их, видите ли, instrumentation отлавливает нынче. Но навернуть тесты и fuzzing канительнее чем песенки про всяких лохов сочинять.

Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +9 +/–
Сообщение от Аноним (-), 23-Фев-20, 20:23 
Просто тут видно невооруженным глазом разницу в уровне профессионализма между Maxime Villard'ом (из NetBSD) и детворой из OpenBSD.

In vmm_update_pvclock():


6868    pvclock_gpa = vcpu->vc_pvclock_system_gpa & 0xFFFFFFFFFFFFFFF0;  <-- controlled by the guest
6869    if (!pmap_extract(vm->vm_map->pmap, pvclock_gpa, &pvclock_hpa))
6870        return (EINVAL);
6871    pvclock_ti = (void*) PMAP_DIRECT_MAP(pvclock_hpa);
6872
6873    /* START next cycle (must be odd) */
6874    pvclock_ti->ti_version =
6875        (++vcpu->vc_pvclock_version << 1) | 0x1;

Three things are wrong:

  1) The RO protections are not enforced, so the guest could have data be
     written to a GPA it can only access as RO.

  2) If 'pvclock_ti' crosses a page, its second half could point to an HPA
     that doesn't belong to the guest. The guest can therefore, to some
     limited extent, overwrite host kernel memory.

  3) The pmap is not locked, so if the GPA gets unmapped and its
     corresponding HPA recycled, there is a small window where the (new)
     content of the HPA can get overwritten.

There is, in fact, a fourth case. Watch closely. On AMD CPUs the NPTs are
a regular pmap. The higher half of the GPA space is therefore mapped to
host kernel memory as KVA. Given that there is no check on PG_u here, the
guest can just put a host KVA in pvclock_gpa, and have its content be
overwritten. This gives write-where ability for the guest.

The OpenBSD kernel does not perform full ASLR, in that the PTE space and
direct map are at static addresses (contrary to eg NetBSD where everything
is randomized). These addresses are known. The guest can therefore use the
static address of the direct map for example to write at whatever HPA by
issuing the following instruction:

    wrmsr(KVM_MSR_SYSTEM_TIME, PMAP_DIRECT_MAP(hpa) | 1);

This means the guest can overwrite whatever host kernel memory, and can
control *where* to write. I have tested this, and it works.

The guest can also choose *what* to write, because it just so happens that
'vc_pvclock_version' is the number of VMEXITs that occurred with pvclock
enabled, and the guest can reliably craft this value. So this is not just
a write-where, this is a full guest-to-host write-what-where.

Had there been proper ASLR, it still could have been somewhat bypassable,
because VMD does a pass-through of RDMSR on AMD CPUs (??), which can leak
HPAs such as HSAVE_PA.

(Speaking about direct map, notice how an alignment bug in locore0.S
causes the first 2MB of .text to be writable on Intel CPUs. So there is a
static address that maps the kernel .text as writable.)

There are additional assorted bugs and vulns that could be used to some
degree:

  - On AMD CPUs the CPL check on XSETBV VMEXITs must be performed by
    software. VMD forgot to do that, so from guest-userland, we can control
    the XCR0 that guest-kernel will use.

  - This XSETBV issue actually has an additional ramification. Right now
    OpenBSD doesn't check that the guest XCR0 is a subset of the host XCR0,
    which means that the guest can use more FPU states than the host allows.
    It looks like this check was lost when fixing another bug I reported one
    year ago which could cause guest-to-host DoS.

  - The TLB handling of guest pages is broken, in that the INVEPT
    instructions in the host could be issued on the wrong CPUs. This means
    that if UVM decides to swap out a guest page, the guest could still
    access it via stale TLB entries. On AMD CPUs, there is no TLB handling
    at all (??).

  - vmx_load_pdptes is broken.

In order to make this whole thing less of a security joke, I would suggest
the following:

  - Fix TLB handling, sanitize the GPAs, lock the pages correctly.
  - Don't pass-through RDMSR.
  - Fix the XSETBV issues.
  - Provide *real* ASLR: randomize the PTE space and the direct map.
  - Fix the alignment bug in the direct map to not map the text as writable.

Maxime Villard

После того как он всё это разжевал, разумеется, что ему было дико нелепо видеть нубский патч от OpenBSD.


>[оверквотинг удален]
> Module name:    src
> Changes by:    mortimer@cvs.openbsd.org    2020/02/15 15:59:55
>
> Modified files:
>     sys/arch/amd64/amd64: vmm.c
>
> Log message:
> Add bounds check on addresses passed from guests in pvclock.
>
> Fixes an issue where a guest can write to host memory by passing bogus addresses.
I'm a bit confused here. It is not because the GPAs are contiguous that the
HPAs are too. If the structure crosses a page, the guest still can write to
host memory.

Вот тебе и ку-ка-ре-ку самая безопасная в мире ОС OpenBSD ку-ка-ре-ку. Добавить тут особенно нечего... Ах, да, Макс уже тонко троллирует ребят из OpenBSD, используя фразы а-ля


In order to make this whole thing less of a security joke

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

89. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/–
Сообщение от Аноним (89), 23-Фев-20, 21:45 
Как "так" не делаются?

Вот репорт:
https://marc.info/?l=openbsd-tech&m=158176939604512&w=2

Я даже не знаю, как тут подробнее разжевать. Начать с алфавита английского языка, что ли?

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

120. "Уязвимость в гипервизоре VMM, развиваемом OpenBSD, оказалась..."  +/–
Сообщение от пох. (?), 24-Фев-20, 12:33 
> Видимо, кто-то не понимает, что публичные багрепорты так не делаются.

угу. На коленях, смерд, подползать должон! Держа в зубах готовый патч, непременно одобренный не меньше чем шестью виликими разработчиками!

Желательно не ранее чем через пятнадцать лет после того как уговоришь этот патч принять.

Публичные багрепорты именно так и делаются - нашел баг - зарепортил публике. Если и дал время на исправление - это твоя добрая воля, и не более того.


Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру