guestfs-security - захист libguestfs
Цю
сторінку
підручника
присвячено
обговоренню
питань
щодо
безпеки у
користуванні
libguestfs, зокрема
проблемам
ненадійних
або
шкідливих
гостьових
систем або
образів
дисків.
Якщо ви
хочете
конфіденційно
повідомити
про ваду
захисту,
будь ласка,
скористайтеся
безпечною
процедурою
Red Hat, описаною
тут:
https://access.redhat.com/security/team/contact
Якщо
проблема
захисту не
така
серйозна,
ви можете
просто
створити
повідомлення
про ваду
(див. розділ
"ВАДИ"
нижче) або
надіслати
повідомлення
електронною
поштою до
нашого
списку
листування
(
https://www.redhat.com/mailman/listinfo/libguestfs).
Можете не
підписуватися
на список
листування,
якщо не
хочете.
Втім, для
непідписаних
користувачів
повідомлення
з'являються
у списку із
затримкою,
потрібною
на
модерацію.
Ніколи не
монтуйте
файлову
систему
ненадійної
гостьової
системи
безпосередньо
до ядра
вашої
основної
системи
(наприклад,
за
допомогою
петльового
пристрою
або kpartx).
Коли ви
монтуєте
файлову
систему,
помилки у
реалізації
файлової
системи у
ядрі (VFS)
можуть
призвести
до
експлуатації
зловмисниками
шляхом
створення
відповідної
файлової
системи.
Такі
вразливості
є дуже
серйозними
з двох
причин.
По-перше, у
ядрі дуже
багато
драйверів
файлових
систем,
багато з
них
використовуються
нерегулярно,
вони не
часто
привертають
увагу
розробників.
Простір
користувача
Linux допомагає
потенційним
зловмисникам
виявленням
типу
файлової
системи і
автоматичним
вибором
правильного
драйвера VFS,
навіть
якщо тип
файлової
системи є
неочікуваним.
По-друге,
вразливість
на рівні
ядра — це
локальна
вразливість
із правами
доступу
адміністратора
(що є ще
гіршою у
певному
сенсі), яка
надає
негайний і
повний
доступ до
системи, аж
до рівня
обладнання.
Ці
вразливості
могли бути
присутніми
у ядрі
доволі
довго (
https://lwn.net/Articles/538898/).
У libguestfs
реалізовано
багатошаровний
підхід до
захисту
вашої
системи
від
експлоїтів:
ненадійна файлова система
--------------------------------------
ядро базової системи
--------------------------------------
процес qemu, запущений не від імені root
--------------------------------------
sVirt [якщо використано libvirt + SELinux]
--------------------------------------
ядро основної системи
Ми
запускаємо
ядро Linux
всередині
віртуальної
машини qemu,
зазвичай
від імені
непривілейованого
користувача.
Зловмиснику
доведеться
написати
файлову
систему,
яка
спочатку
експлуатуватиме
вразливість
у ядрі, а
потім
експлуатуватиме
вразливість
або у
віртуалізації
qemu
(наприклад,
у
неякісному
драйвері qemu),
або у
протоколі
libguestfs, і нарешті,
щоб
отримати
результат,
еквівалентний
до
вразливості
у ядрі,
доведеться
якось
отримати
права
доступу
адміністратора
(root). Крім того,
якщо ви
використовуєте
модуль
обробки libvirt
та SELinux, для
обмеження
прав
доступу qemu
використовується
sVirt. Тому таке
розширення
доступу,
яке має
виконуватися
за
допомогою
статичного
коду, можна
вважати
надзвичайно
важким
завданням,
хоча ми
ніколи не
кажемо
«ніколи»
щодо
вразливостей
у захисті.
Функції
виклику
також
можуть
значно
звузити
можливості
нападу,
якщо
примусово
вказуватимуть
тип
файлової
системи
при
монтуванні
(використовуватимуть
"guestfs_mount_vfs" in
guestfs(3)).
Будьте
обережні
із
будь-якими
файлами
або даними,
які ви
отримуєте
із
гостьової
системи
(під
терміном
«отримуєте»
ми маємо на
увазі не
лише
виконання
команди
"guestfs_download" in
guestfs(3), але
і
виконання
будь-якої
команди,
яка читає
файли,
назви
файлів,
каталоги
або
будь-які
інші дані з
образу
диска).
Зловмисник
може
змінити
дані так,
щоб
змусити
вашу
програму
виконати
якісь
потрібні
йому дії.
Слід
зважати на
такі
можливі
випадки:
- •
- даних
(файла чи
чогось
іншого)
немає
- •
- дані є,
але вони
порожні
- •
- даних
набагато
більше, ніж
звичайно
- •
- дані є
довільними
8-бітовими
значеннями
- •
- дані
представлено
у
неочікуваному
кодуванні
- •
- назви
даних
містять
гомогліфи.
Протокол
розроблено
із
врахуванням
питань
безпеки,
засновано
на RFC 4506 (XDR) із
визначеною
верхньою
межею
розміру
повідомлення.
Втім,
програмам,
у яких
використано
libguestfs, також
слід
вживати
певних
заходів
захисту.
Наприклад,
ви можете
написати
програму,
яка
отримує
виконуваний
файл із
образу
диска і
виконує
його у
локальній
системі.
Ніякий
захист у
протоколі
не вбереже
вашу
систему
від
небезпечних
наслідків
виконання
шкідливої
програми.
Елементи
програмного
інтерфейсу
інспектування
(див.
"ІНСПЕКТУВАННЯ"
in
guestfs(3))
повертають
довільні
рядки
безпосередньо
з
гостьової
системи.
Повернуті
рядки
можуть
містити
довільні
8-бітові
дані. У
функціях,
які
викликають
такі
елементи
програмного
інтерфейсу,
слід
подбати
про
екранування
даних до
виведення
їх до
структурованого
файла
(наприклад,
екранування
коду HTML, якщо
створюється
вебсторінка).
Налаштування
гостьової
системи
може бути
змінено у
незвичний
спосіб
адміністратором
віртуальної
машини.
Дані у
файлах
налаштувань
можуть
бути
неактуальними
(особливо у
ненадійних
або
активно
шкідливих
гостьових
системах).
Наприклад,
ми
отримуємо
назву
вузла із
файлів
налаштувань,
наприклад
/etc/sysconfig/network, які
зберігаються
у
гостьовій
системі,
але
адміністратор
гостьової
системи
може легко
внести
зміни до
цих файлів
так, щоб
надавати
неправильну
назву
вузла.
Програмний
інтерфейс
інспектування
обробляє
налаштування
гостьових
систем за
допомогою
двох
зовнішніх
бібліотек:
Augeas
(налаштування
Linux) та hivex
(реєстр Windows).
Розробники
обох
бібліотек
подбали
про
стійкість
коду до
шкідливих
даних, але
атаки з
метою
викликати
відмову в
обслуговуванні
усе ще
можливі.
Наприклад,
для цього
можна
скористатися
файлами
налаштувань
величезних
розмірів.
Будьте
дуже
обережні
із
запуском
програм з
гостьової
системи.
Запускаючи
програму з
гостьової
системи, ви
надаєте
процесорний
час
виконуваному
файлу, який
ви не
контролюєте,
для того
самого
облікового
запису, від
імені
якого
працює
бібліотека,
хоча і
замкненому
у
віртуальному
просторі qemu.
Докладніший
опис
варіантів
запуску
можна
знайти у
розділі
"ВИКОНАННЯ
КОМАНД" in
guestfs(3).
https://bugzilla.redhat.com/642934
Ця вада у
захисті
стосується
автоматичного
визначення
формату
диска, яке qemu
виконує
для
образів
дисків.
Простий (raw)
образ
диска — це
просто
набір
байтів без
заголовка.
У інших
форматах
образів
дисків,
зокрема qcow2,
міститься
спеціальний
заголовок. Qemu
шукає у
образі
один із
відомих
заголовків
і, якщо
такого
заголовка
не буде
знайдено,
вважає
образ
диска
простим.
Це надає
змогу
гостьовій
системі,
якій
надано
простий
образ
диска,
записати
до нього
якийсь
інший
заголовок.
Під час
наступного
завантаження
(або
доступу до
образу
диска за
допомогою
libguestfs) qemu має
виконати
автовизначення
і на основі
заголовка
від
гостьової
системи
визначити,
що
форматом
образу
диска є,
скажімо» qcow2.
Сама
процедура
встановлення
заголовків
не є
проблемною.
Проблема
полягає у
тому, що у
формат qcow2
передбачено
багато
можливостей,
одна з яких
надає
змогу
образу
диска
посилатися
на інший
образ (який
називається
«резервним
диском»).
Реалізується
ця
можливість
шляхом
запису
адреси
резервного
диска до
заголовка
qcow2. Ця адреса
не
перевіряється
і може
вказувати
на
будь-який
файл у
основній
системі
(наприклад,
«/etc/passwd»). Далі,
доступ до
даних
резервного
диска
надається
через
«дірки» у
образі
диска qcow2,
який,
звичайно ж,
може
потрапити
під повний
контроль
зловмисника.
У libguestfs
скористатися
цією
вразливістю
доволі
складно,
окрім двох
випадків:
- 1.
- Вами
увімкнено
мережу або
відкрито
диск у
режимі
запису.
- 2.
- Ви також
запускаєте
ненадійний
код з
гостьової
системи
(див.
"ЗАПУСК
КОМАНД" in
guestfs(3)).
Цих
проблем
можна
уникнути,
вказавши
очікуваний
формат
диска під
час
додавання
дисків
(необов'язковий
параметр
"format" у "guestfs_add_drive_opts" in
guestfs(3)). Вам
завжди
варто
вказувати
формат,
якщо дані
диска
зберігаються
у простому
форматі (raw). У
інших
випадках
цим теж не
варто
нехтувати.
(Див. також
"ФОРМАТИ
ОБРАЗІВ
ДИСКІВ" in
guestfs(3)).
Для дисків,
які
додаються
з libvirt за
допомогою
викликів,
подібних
до "guestfs_add_domain" in
guestfs(3),
дані щодо
формату
отримуються
від libvirt і
передаються
далі
ланцюжком
обробки.
Для
засобів libguestfs
використовувати
параметр
командного
рядка
--format у
належний
спосіб.
https://bugzilla.redhat.com/752375
Це вада у
ядрі, яка
надавала
змогу
гостьовим
системам
перезаписувати
частини
дисків
основної
системи, до
яких вони
за
звичайних
умов не
повинні
були мати
доступу.
Достатньо
оновити libguestfs
до
будь-якої
версії ≥ 1.16,
яка
містить
зміну, що
усуває
проблему.
https://bugzilla.redhat.com/831117
У старих
версіях
програми virt-edit
та команди
"edit" guestfish
створювався
новий файл,
у якому
зберігалися
зміни, але
не
встановлювалися
права
доступу та
інші
параметри
так, щоб
вони
збігалися
із
параметрами
старого
редагованого
файла. У
результаті
після
редагування
конфіденційного
файла,
зокрема
/etc/shadow,
він ставав
доступним
для
сторонніх
користувачів.
Достатньо
оновити libguestfs
до
будь-якої
версії ≥ 1.16.
https://bugzilla.redhat.com/968306
Ця вада
захисту
була
«діркою» у
засобі
інспектування,
пов'язаною
з тим, що
відповідним
чином
створена
гостьова
система за
допомогою
приготованого
файла, що у
ній
зберігався,
могла
призвести
до
подвійного
вивільнення
пам'яті у
бібліотеці
мовою C
(спричинити
відмову в
обслуговуванні).
Достатньо
оновити libguestfs
до версії, у
якій
вразливість
усунено: libguestfs ≥
1.20.8, ≥ 1.22.2 або ≥ 1.23.2.
https://bugzilla.redhat.com/1016960
Якщо
використано
параметр
guestfish(1) --remote або guestfish
--listen, guestfish має
створити
сокет у
відомому
місці (
/tmp/.guestfish-$UID/socket-$PID).
Місце має
бути
наперед
відомим,
щоб за його
допомогою
обидва
боки
каналу
зв'язку
могли
обмінюватися
даними.
Втім, не
виконується
перевірки,
чи
належить
відповідний
каталог (
/tmp/.guestfish-$UID)
користувачеві.
Тому цей
каталог
може бути
створено
іншим
користувачем,
який,
потенційно,
може
перехопити
сокети
клієнта
або
сервера guestfish.
Достатньо
оновити libguestfs
до версії, у
якій
вразливість
усунено: libguestfs ≥
1.20.12, ≥ 1.22.7 або ≥ 1.24.
Можна було
спричинити
аварійне
завершення
роботи libguestfs (та
програм,
які
використовують
libguestfs як
бібліотеку)
передаванням
їм образу
диска, на
якому
містився
пошкоджений
том btrfs.
Причиною
було
розіменування
нульового
вказівника,
яке
спричиняло
відмову в
обслуговуванні.
Ми
вважаємо,
що ширше
використання
цієї
вразливості
неможливе.
Див. внесок
d70ceb4cbea165c960710576efac5a5716055486 із
виправленням.
Це
виправлено
включено
до
стабільних
гілок libguestfs ≥ 1.26.0,
≥ 1.24.6 та ≥ 1.22.8, а
також до RHEL
≥ 7.0. Старіші
версії libguestfs не
є
вразливими.
У
попередніх
версіях libguestfs
використовувала
незахищені
програмні
інтерфейси
libxml2 для
обробки XML libvirt.
Ці
програмні
інтерфейси
типово
надавали
доступ до
встановлення
з'єднань
мережі,
якщо
передавалися
документи XML
певного
вмісту. За
допомогою
спеціально
сформованого
документа XML
також
можна було
вичерпати
можливості
комп'ютера
за
процесорним
часом,
пам'яттю
або
дескрипторами
файлів.
Оскільки XML libvirt
надходить
із
надійного
джерела
(фонової
служби libvirt), ми
вважаємо,
що цією
вразливістю
неможливо
було
скористатися.
Вразливість
виправлено
у libguestfs ≥ 1.27.9,
виправлення
було
зворотно
портовано
до
стабільних
версій ≥ 1.26.2, ≥
1.24.9, ≥ 1.22.10 та ≥ 1.20.13.
Вада у bash
опосередковано
торкнулася
libguestfs.
Докладніша
інформація:
https://www.redhat.com/archives/libguestfs/2014-September/msg00252.html
Ці дві вади
є вадами
програми
із
комплекту
binutils GNU
strings(1). Через
них
вразливими
стали
інтерфейси
"guestfs_strings" in
guestfs(3) та
"guestfs_strings_e" in
guestfs(3) у libguestfs.
Обробка за
допомогою
strings
відповідно
сформованого
файла
могла
призвести
до
виконання
довільного
коду
(область
виконання
обмежено
базовою
системою libguestfs).
У libguestfs ≥ 1.29.5 та ≥ 1.28.3
використано
параметр
"strings"
-a для
того, щоб
уникнути
обробки
файлів за
допомогою BFD.
https://bugzilla.redhat.com/show_bug.cgi?id=1251157
Це не
вразливість
у libguestfs, але
оскільки
ми завжди
надаємо
порт virtio-serial для
кожної
гостьової
системи
(оскільки
так
здійснюється
обмін
даними між
гостьовою
і основною
системами),
можливе
проникнення
з базової
системи до
процесу qemu
основної
системи. Це
може
стосуватися
таких
випадків:
- •
- ваша
програма
libguestfs
запускає
ненадійні
програми з
гостьової
системи (за
допомогою
"guestfs_sh" in guestfs(3)
тощо) або
- •
- у коді
файлових
систем
ядра буде
виявлено
іншу
властивість
(наприклад),
яка надає
змогу
відповідним
чином
створеній
файловій
системі
захопити
контроль
над
базовою
системою.
Якщо ви
використовуєте
sVirt для
обмеження qemu,
це може
запобігти
деяким
нападам.
https://bugzilla.redhat.com/1260778
У
програмах
virt-customize(1),
virt-sysprep(1) та
virt-builder(1)
передбачено
параметр
--ssh-inject для
вставляння
ключа SSH до
образів
дисків
віртуальної
машини. Для
виконання
цього
завдання
програми
можуть
створювати
каталог
~user/.ssh
і файл
~user/.ssh/authorized_keys
у
гостьовій
системі.
У libguestfs < 1.31.5 та libguestfs < 1.30.2
для нового
каталогу і
файла
вибираються
режими
доступу 0755 і 0644,
відповідно.
Втім, такі
права
доступу
(особливо
до
~user/.ssh) є
ширшими за
ті, які
використовує
OpenSSH. У
поточних
версіях libguestfs
каталог і
файл
створюються
із режимом
доступу 0700 і 0600,
відповідно.
https://bugzilla.redhat.com/CVE-2015-8869
Ця
вразливість
у OCaml може
стосуватися
усіх
інструментів
віртуалізації,
які
написано
мовою
програмування
OCaml. Вона
стосується
лише
64-бітових
платформ.
Оскільки
ця вада
стосується
створення
коду, важко
визначити
точний
перелік
вражених
програм,
тому
рекомендують
повторно
зібрати libguestfs
за
допомогою
версії
компілятора
OCaml, де цю ваду
виправлено
(або
попросити
розробників
вашого
дистрибутива
Linux зробити
це для вас).
Вразливості
у програмі
wrestool(1) з
пакунка "icoutils"
може бути
використано
для
локального
виконання
коду у
основній
системі.
Коли засіб
інспектування
libguestfs (див. "Inspection security"
вище)
виявляє
гостьову
систему Windows XP
або Windows 7 і
отримує
запит щодо
пошуку
пов'язаної
піктограми
гостьової
системи,
засіб
інспектування
отримує
файл, який
не є
безпечним,
з
гостьової
системи і
запускає
"wrestool -x" для
цього
файла. Це
може
призвести
до
виконання
коду у
основній
системі.
Зловмисники
можуть
створити
образ
диска або
гостьову
систему,
яка
виглядатиме
як
гостьова
система Windows
для засобу
інспектування
libguestfs, тому те,
що у вас
немає
гостьових
систем Windows, не
допоможе
вберегтися
від
вразливості.
Потенційно
вразливими
є усі
програми,
які
викликають
програмний
інтерфейс
libguestfs "guestfs_inspect_get_icon".
Такими
програмами,
зокрема, є
virt-inspector(1) та
virt-manager(1).
Усунути
проблему
можна,
оновивши icoutils
до
невразливої
версії
(принаймні
до 0.31.1).
Вразливостями
у PCRE можна
скористатися
для
спричинення
аварійного
завершення
роботи libguestfs
(тобто,
спричинити
відмову в
обслуговуванні)
під час
виконання
інспектування
віртуальної
машини, до
якої
можуть
мати
доступ
зловмисники.
Усунути
проблему
можна,
оновивши PCRE
до версії,
де вади
виправлено
(основної
версії ≥ 8.41).
Вразливості
у засобах
обробки
роботи
користувача
qemu у мережі (SLIRP)
надають
змогу за
допомогою
спеціально
сформованого
образу
файлової
системи
перебрати
контроль
над qemu і за її
допомогою
атакувати
основну
систему.
Це впливає
на роботу libguestfs,
якщо
встановлено
модуль
обробки "direct"
і
увімкнено
роботу у
мережі.
Модуль direct є
типовим
для
програми
із
основної
гілки
розробки,
але не у
дистрибутивах
Linux, які
використовують
qemu, зокрема у
Fedora, Red Hat Enterprise Linux та CentOS.
Цей модуль
може бути
також
вибрано за
допомогою
значення
змінної
середовища
"LIBGUESTFS_BACKEND=direct" або
виклику
"guestfs_set_backend (g, "direct")".
Робота у
мережі
автоматично
вмикається
деякими
програмами
(наприклад
virt-builder(1)) або під
час
виклику у
коді
"guestfs_set_network (g, 1)"
(нетипові
параметри
функції).
Модуль
обробки libvirt є
невразливим.
Усунути
проблему
можна
оновленням
qemu до
виправленої
версії (див.
https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html).
https://bugzilla.redhat.com/CVE-2022-2211
The "get_keys" function in
libguestfs-common/options/keys.c
collects those
--key options from the command line into a new array
that match a particular block device that's being decrypted for inspection.
The function intends to size the result array such that potentially all
--key options, plus a terminating "NULL" element, fit into
it. The code mistakenly uses the "MIN" macro instead of
"MAX", and therefore only one element is allocated before the
"NULL" terminator.
Passing precisely two
--key ID:... options on the command line for the
encrypted block device "ID" causes "get_keys" to overwrite
the terminating "NULL", leading to an out-of-bounds read in
"decrypt_mountables", file
libguestfs-common/options/decrypt.c.
Passing more than two
--key ID:... options on the command line for the
encrypted block device "ID" causes "get_keys" itself to
perform out-of-bounds writes. The most common symptom is a crash with
"SIGSEGV" later on.
This issue affects -- broadly speaking -- all libguestfs-based utilities that
accept
--key, namely: "guestfish", "guestmount",
"virt-cat", "virt-customize", "virt-diff",
"virt-edit", "virt-get-kernel",
"virt-inspector", "virt-log", "virt-ls",
"virt-sparsify", "virt-sysprep", "virt-tail",
"virt-v2v".
guestfs(3),
guestfs-internals(1),
guestfs-release-notes(1),
guestfs-testing(1),
http://libguestfs.org/.
Richard W.M. Jones ("rjones at redhat dot com")
© Red Hat Inc., 2009–2020
To get a list of bugs against libguestfs, use this link:
https://bugzilla.redhat.com/buglist.cgi?component=libguestfs&product=Virtualization+Tools
To report a new bug against libguestfs, use this link:
https://bugzilla.redhat.com/enter_bug.cgi?component=libguestfs&product=Virtualization+Tools
When reporting a bug, please supply:
- •
- The version of libguestfs.
- •
- Where you got libguestfs (eg. which Linux distro, compiled
from source, etc)
- •
- Describe the bug accurately and give a way to reproduce
it.
- •
- Run libguestfs-test-tool(1) and paste the
complete, unedited output into the bug report.