Захист змонтованих файлових систем

Ніколи не монтуйте файлову систему ненадійної гостьової системи безпосередньо до ядра вашої основної системи (наприклад, за допомогою петльового пристрою або 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).

CVE-2010-3851

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 у належний спосіб.

CVE-2011-4127

https://bugzilla.redhat.com/752375

Це вада у ядрі, яка надавала змогу гостьовим системам перезаписувати частини дисків основної системи, до яких вони за звичайних умов не повинні були мати доступу.

Достатньо оновити libguestfs до будь-якої версії ≥ 1.16, яка містить зміну, що усуває проблему.

CVE-2012-2690

https://bugzilla.redhat.com/831117

У старих версіях програми virt-edit та команди команди "edit" guestfish створювався новий файл, у якому зберігалися зміни, але не встановлювалися права доступу та інші параметри так, щоб вони збігалися із параметрами старого редагованого файла. У результаті після редагування конфіденційного файла, зокрема /etc/shadow, він ставав доступним для сторонніх користувачів.

Достатньо оновити libguestfs до будь-якої версії ≥ 1.16.

CVE-2013-2124

https://bugzilla.redhat.com/968306

Ця вада захисту була «діркою» у засобі інспектування, пов'язаною з тим, що відповідним чином створена гостьова система за допомогою приготованого файла, що у ній зберігався, могла призвести до подвійного вивільнення пам'яті у бібліотеці мовою C (спричинити відмову в обслуговуванні).

Достатньо оновити libguestfs до версії, у якій вразливість усунено: libguestfs ≥ 1.20.8, ≥ 1.22.2 або ≥ 1.23.2.

CVE-2013-4419

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.

Відмова у обслуговуванні при інспектуванні образів дисків із пошкодженими томами btrfs

Можна було спричинити аварійне завершення роботи libguestfs (та програм, які використовують libguestfs як бібліотеку) передаванням їм образу диска, на якому містився пошкоджений том btrfs.

Причиною було розіменування нульового вказівника, яке спричиняло відмову в обслуговуванні. Ми вважаємо, що ширше використання цієї вразливості неможливе.

Див. внесок d70ceb4cbea165c960710576efac5a5716055486 із виправленням. Це виправлено включено до стабільних гілок libguestfs ≥ 1.26.0, ≥ 1.24.6 та ≥ 1.22.8, а також до RHEL ≥ 7.0. Старіші версії libguestfs не є вразливими.

CVE-2014-0191

У попередніх версіях 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.

Shellshock (bash CVE-2014-6271)

Вада у bash опосередковано торкнулася libguestfs. Докладніша інформація: https://www.redhat.com/archives/libguestfs/2014-September/msg00252.html

CVE-2014-8484

CVE-2014-8485

Ці дві вади є вадами програми із комплекту 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.

CVE-2015-5745

https://bugzilla.redhat.com/show_bug.cgi?id=1251157

Це не вразливість у libguestfs, але оскільки ми завжди надаємо порт virtio-serial для кожної гостьової системи (оскільки так здійснюється обмін даними між гостьовою і основною системами), можливе проникнення з базової системи до процесу qemu основної системи. Це може стосуватися таких випадків:

• ваша програма libguestfs запускає ненадійні програми з гостьової системи (за допомогою "guestfs_sh" in guestfs(3) тощо) або
• у коді файлових систем ядра буде виявлено іншу властивість (наприклад), яка надає змогу відповідним чином створеній файловій системі захопити контроль над базовою системою.

Якщо ви використовуєте sVirt для обмеження qemu, це може запобігти деяким нападам.

Права доступу до .ssh і .ssh/authorized_keys

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, відповідно.

CVE-2015-8869

https://bugzilla.redhat.com/CVE-2015-8869

Ця вразливість у OCaml може стосуватися усіх інструментів віртуалізації, які написано мовою програмування OCaml. Вона стосується лише 64-бітових платформ. Оскільки ця вада стосується створення коду, важко визначити точний перелік вражених програм, тому рекомендують повторно зібрати libguestfs за допомогою версії компілятора OCaml, де цю ваду виправлено (або попросити розробників вашого дистрибутива Linux зробити це для вас).

CVE-2017-5208, CVE-2017-5331, CVE-2017-5332, CVE-2017-5333, CVE-2017-6009, CVE-2017-6010, CVE-2017-6011

Вразливості у програмі 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).

CVE-2017-7244, CVE-2017-7245, CVE-2017-7246

Вразливостями у PCRE можна скористатися для спричинення аварійного завершення роботи libguestfs (тобто, спричинити відмову в обслуговуванні) під час виконання інспектування віртуальної машини, до якої можуть мати доступ зловмисники.

Усунути проблему можна, оновивши PCRE до версії, де вади виправлено (основної версії ≥ 8.41).

CVE-2018-11806

Вразливості у засобах обробки роботи користувача 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).