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

"В гипервизоре Xen устранено 12 уязвимостей, потенциально позволяющие обойти изоляцию гостевой системы"	+/–
Сообщение от opennews (??), 29-Июл-26, 09:52
Опубликованы патчи с устранением в гипервизоре Xen 20 уязвимостей, из которых 12 не исключают возможность эксплуатации для нарушения изоляции гостевой системы и выполнения кода на стороне хост-окружения. Остальные проблемы дают возможность инициировать отказ в обслуживании или приводят к утечке памяти. Наиболее серьёзные проблемы:... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65995
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 29-Июл-26, 09:52	+/–
Вопрос к тем, кто этим пользуется: почему Xen?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #4, #6

2. Сообщение от Аноним (-), 29-Июл-26, 10:13	+2 +/–
Потому что это открытый гипервизор 1-го типа. У него поверхность атаки гораздо ниже, чем у того же KVM. QubesOS (а его прямая альтернатива на KVM, SpectrumOS, ещё очень незрелая) работает поверх Xen. И Xen широко используется в automotive/embedded. Среди активных контрибьюторов в Xen есть Ford, Honda, Renesas, EPAM и Boeing.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Аноним (3), 29-Июл-26, 10:17	–1 +/–
Пять  ̶у̶я̶з̶в̶и̶м̶о̶с̶т̶е̶й̶ бекдоров из-за "переполнения буфера в библиотеке libfsimage, возникающие при обработке специально оформленных образов". Плюс еще один по причине "отсутствие проверки корректности запрашиваемых буферов в реализации гипервызова" Три состояния гонки. СИшка, итоги (с)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #9

4. Сообщение от Хейтер (?), 29-Июл-26, 10:23	+1 +/–
>почему Xen - а почему нет? Стабильный, менее ресурсоемкий (по субъективным ощущениям), разные уровни виртуализации (PVM/HVM). И у него всё это было до того как у других не было. Зачем с него уходить? Обоснуйте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

5. Сообщение от Аноним (-), 29-Июл-26, 10:26	+/–
Особенно опасны: XSA-500 / CVE-2026-62428 XSA-501 / CVE-2026-62435 и CVE-2026-62436 XSA-505 / CVE-2026-62432 — это скорее DoS для HVM/PVM, а для PV это потенциальный escape (для HVM/PVM тоже, но для этого нужно эксплуатировать stub domain сначала) XSA-507 / CVE-2026-62434 — это тоже скорее DoS XSA-502 / CVE-2026-62429 — эту уязвимость можно использовать только из stub domain (обычно, QEMU), сначала нужно эксплуатировать его XSA-497 / ISO9660 переполнения в libfsimage — эксплуатируемся только если pygrub находится в привелигированном режиме (по умолчанию, вроде, используются непривелигированный)
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 29-Июл-26, 10:30	+/–
А какие есть альтернативы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

7. Сообщение от Аноним (6), 29-Июл-26, 10:31    Скрыто ботом-модератором	+3 +/–
Ешь растишку, подрасти, потом поймёшь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #8

8. Сообщение от Аноним (8), 29-Июл-26, 10:41    Скрыто ботом-модератором	–1 +/–
> Ешь растишку, подрасти, потом поймёшь Ты что головой стукнулся? При чем тут "растишка"?! Есть тот же С++, который позволяет писать супер сложные приложения, типа компилятора. Да, компилятор GCC который компилирует СИшку, написан на плюсах. По причине "на убогой СИшке нормальный оптимизирующий компилятор написать не реально". Про ada/spark я не вспоминаю, так как слишком они сложные для типичного овнокодера. Хотя по надежности уделают и плюсы, и раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

9. Сообщение от localhostadmin (ok), 29-Июл-26, 10:53	+/–
> отсутствие проверки корректности запрашиваемых буферов в реализации гипервызова С каких пор отсутствие валидации и состояние гонки стали проблемой сишки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #10

10. Сообщение от Аноним (10), 29-Июл-26, 11:38	+/–
> С каких пор отсутствие валидации и состояние гонки стали проблемой сишки? Возможно в культуре программирования, а точне её полного отстутствия? (судя по качествіу кода в ядре). А может в отсутствии нормальных механизмов. В том же С++ есть RAII, Atomicʼи и Futures. В ада Protected Objects и Task Rendezvous (а SPARK добавляет static verification и контракты) - по сути система владения. Даже, упомянутый не к месту аноном выше, rust позволяет избегать состояния гонки в сейф коде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

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

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