=head1 НАЗВА

guestfs-security - захист libguestfs

=head1 ОПИС

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

=head1 ЗВІТУВАННЯ ЩОДО ПРОБЛЕМ ІЗ БЕЗПЕКОЮ

Якщо ви хочете конфіденційно повідомити про ваду захисту, будь ласка,
скористайтеся безпечною процедурою Red Hat, описаною тут:
L<https://access.redhat.com/security/team/contact>

Якщо проблема захисту не така серйозна, ви можете просто створити
повідомлення про ваду (див. розділ L</ВАДИ> нижче) або надіслати
повідомлення електронною поштою до нашого списку листування
(L<https://www.redhat.com/mailman/listinfo/libguestfs>). Можете не
підписуватися на список листування, якщо не хочете. Втім, для непідписаних
користувачів повідомлення з'являються у списку із затримкою, потрібною на
модерацію.

=head1 ЗАГАЛЬНІ ВАДИ

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

Ніколи не монтуйте файлову систему ненадійної гостьової системи
безпосередньо до ядра вашої основної системи (наприклад, за допомогою
петльового пристрою або kpartx).

Коли ви монтуєте файлову систему, помилки у реалізації файлової системи у
ядрі (VFS) можуть призвести до експлуатації зловмисниками шляхом створення
відповідної файлової системи. Такі вразливості є дуже серйозними з двох
причин. По-перше, у ядрі дуже багато драйверів файлових систем, багато з них
використовуються нерегулярно, вони не часто привертають увагу
розробників. Простір користувача Linux допомагає потенційним зловмисникам
виявленням типу файлової системи і автоматичним вибором правильного драйвера
VFS, навіть якщо тип файлової системи є неочікуваним. По-друге, вразливість
на рівні ядра — це локальна вразливість із правами доступу адміністратора
(що є ще гіршою у певному сенсі), яка надає негайний і повний доступ до
системи, аж до рівня обладнання.

Ці вразливості могли бути присутніми у ядрі доволі довго
(L<https://lwn.net/Articles/538898/>).

У libguestfs реалізовано багатошаровний підхід до захисту вашої системи від
експлоїтів:

   ненадійна файлова система
 --------------------------------------
   ядро базової системи
 --------------------------------------
   процес qemu, запущений не від імені root
 --------------------------------------
   sVirt [якщо використано libvirt + SELinux]
 --------------------------------------
   ядро основної системи

Ми запускаємо ядро Linux всередині віртуальної машини qemu, зазвичай від
імені непривілейованого користувача. Зловмиснику доведеться написати файлову
систему, яка спочатку експлуатуватиме вразливість у ядрі, а потім
експлуатуватиме вразливість або у віртуалізації qemu (наприклад, у
неякісному драйвері qemu), або у протоколі libguestfs, і нарешті, щоб
отримати результат, еквівалентний до вразливості у ядрі, доведеться якось
отримати права доступу адміністратора (root). Крім того, якщо ви
використовуєте модуль обробки libvirt та SELinux, для обмеження прав доступу
qemu використовується sVirt. Тому таке розширення доступу, яке має
виконуватися за допомогою статичного коду, можна вважати надзвичайно важким
завданням, хоча ми ніколи не кажемо «ніколи» щодо вразливостей у захисті.

Функції виклику також можуть значно звузити можливості нападу, якщо
примусово вказуватимуть тип файлової системи при монтуванні
(використовуватимуть L<guestfs(3)/guestfs_mount_vfs>).

=head2 Загальні зауваження щодо захисту

Будьте обережні із будь-якими файлами або даними, які ви отримуєте із
гостьової системи (під терміном «отримуєте» ми маємо на увазі не лише
виконання команди L<guestfs(3)/guestfs_download>, але і виконання будь-якої
команди, яка читає файли, назви файлів, каталоги або будь-які інші дані з
образу диска). Зловмисник може змінити дані так, щоб змусити вашу програму
виконати якісь потрібні йому дії. Слід зважати на такі можливі випадки:

=over 4

=item *

даних (файла чи чогось іншого) немає

=item *

дані є, але вони порожні

=item *

даних набагато більше, ніж звичайно

=item *

дані є довільними 8-бітовими значеннями

=item *

дані представлено у неочікуваному кодуванні

=item *

назви даних містять гомогліфи.

=back

=head2 Захист протоколу

Протокол розроблено із врахуванням питань безпеки, засновано на RFC 4506
(XDR) із визначеною верхньою межею розміру повідомлення. Втім, програмам, у
яких використано libguestfs, також слід вживати певних заходів
захисту. Наприклад, ви можете написати програму, яка отримує виконуваний
файл із образу диска і виконує його у локальній системі. Ніякий захист у
протоколі не вбереже вашу систему від небезпечних наслідків виконання
шкідливої програми.

=head2 Інспектування захисту

Елементи програмного інтерфейсу інспектування
(див. L<guestfs(3)/ІНСПЕКТУВАННЯ>) повертають довільні рядки безпосередньо з
гостьової системи. Повернуті рядки можуть містити довільні 8-бітові дані. У
функціях, які викликають такі елементи програмного інтерфейсу, слід подбати
про екранування даних до виведення їх до структурованого файла (наприклад,
екранування коду HTML, якщо створюється вебсторінка).

Налаштування гостьової системи може бути змінено у незвичний спосіб
адміністратором віртуальної машини. Дані у файлах налаштувань можуть бути
неактуальними (особливо у ненадійних або активно шкідливих гостьових
системах). Наприклад, ми отримуємо назву вузла із файлів налаштувань,
наприклад F</etc/sysconfig/network>, які зберігаються у гостьовій системі,
але адміністратор гостьової системи може легко внести зміни до цих файлів
так, щоб надавати неправильну назву вузла.

Програмний інтерфейс інспектування обробляє налаштування гостьових систем за
допомогою двох зовнішніх бібліотек: Augeas (налаштування Linux) та hivex
(реєстр Windows). Розробники обох бібліотек подбали про стійкість коду до
шкідливих даних, але атаки з метою викликати відмову в обслуговуванні усе ще
можливі. Наприклад, для цього можна скористатися файлами налаштувань
величезних розмірів.

=head2 Запуск незахищених команд гостьової системи

Будьте дуже обережні із запуском програм з гостьової системи. Запускаючи
програму з гостьової системи, ви надаєте процесорний час виконуваному файлу,
який ви не контролюєте, для того самого облікового запису, від імені якого
працює бібліотека, хоча і замкненому у віртуальному просторі
qemu. Докладніший опис варіантів запуску можна знайти у розділі
L<guestfs(3)/ВИКОНАННЯ КОМАНД>.

=head1 ІСТОРИЧНО ВІДОМІ ВАДИ ЗАХИСТУ У LIBGUESTFS

=head2 CVE-2010-3851

L<https://bugzilla.redhat.com/642934>

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

Простий (raw) образ диска — це просто набір байтів без заголовка. У інших
форматах образів дисків, зокрема qcow2, міститься спеціальний
заголовок. Qemu шукає у образі один із відомих заголовків і, якщо такого
заголовка не буде знайдено, вважає образ диска простим.

Це надає змогу гостьовій системі, якій надано простий образ диска, записати
до нього якийсь інший заголовок. Під час наступного завантаження (або
доступу до образу диска за допомогою libguestfs) qemu має виконати
автовизначення і на основі заголовка від гостьової системи визначити, що
форматом образу диска є, скажімо» qcow2.

Сама процедура встановлення заголовків не є проблемною. Проблема полягає у
тому, що у формат qcow2 передбачено багато можливостей, одна з яких надає
змогу образу диска посилатися на інший образ (який називається «резервним
диском»). Реалізується ця можливість шляхом запису адреси резервного диска
до заголовка qcow2. Ця адреса не перевіряється і може вказувати на будь-який
файл у основній системі (наприклад, «/etc/passwd»). Далі, доступ до даних
резервного диска надається через «дірки» у образі диска qcow2, який,
звичайно ж, може потрапити під повний контроль зловмисника.

У libguestfs скористатися цією вразливістю доволі складно, окрім двох
випадків:

=over 4

=item 1.

Вами увімкнено мережу або відкрито диск у режимі запису.

=item 2.

Ви також запускаєте ненадійний код з гостьової системи
(див. L<guestfs(3)/ЗАПУСК КОМАНД>).

=back

Цих проблем можна уникнути, вказавши очікуваний формат диска під час
додавання дисків (необов'язковий параметр C<format> у
L<guestfs(3)/guestfs_add_drive_opts>). Вам завжди варто вказувати формат,
якщо дані диска зберігаються у простому форматі (raw). У інших випадках цим
теж не варто нехтувати. (Див. також L<guestfs(3)/ФОРМАТИ ОБРАЗІВ ДИСКІВ>).

Для дисків, які додаються з libvirt за допомогою викликів, подібних до
L<guestfs(3)/guestfs_add_domain>, дані щодо формату отримуються від libvirt
і передаються далі ланцюжком обробки.

Для засобів libguestfs використовувати параметр командного рядка I<--format>
у належний спосіб.

=head2 CVE-2011-4127

L<https://bugzilla.redhat.com/752375>

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

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

=head2 CVE-2012-2690

L<https://bugzilla.redhat.com/831117>

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

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

=head2 CVE-2013-2124

L<https://bugzilla.redhat.com/968306>

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

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

=head2 CVE-2013-4419

L<https://bugzilla.redhat.com/1016960>

Якщо використано параметр L<guestfish(1)> I<--remote> або guestfish
I<--listen>, guestfish має створити сокет у відомому місці
(F</tmp/.guestfish-$UID/socket-$PID>).

Місце має бути наперед відомим, щоб за його допомогою обидва боки каналу
зв'язку могли обмінюватися даними. Втім, не виконується перевірки, чи
належить відповідний каталог (F</tmp/.guestfish-$UID>) користувачеві. Тому
цей каталог може бути створено іншим користувачем, який, потенційно, може
перехопити сокети клієнта або сервера guestfish.

Достатньо оновити libguestfs до версії, у якій вразливість усунено:
libguestfs E<ge> 1.20.12, E<ge> 1.22.7 або E<ge> 1.24.

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

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

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

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

=head2 CVE-2014-0191

У попередніх версіях libguestfs використовувала незахищені програмні
інтерфейси libxml2 для обробки XML libvirt. Ці програмні інтерфейси типово
надавали доступ до встановлення з'єднань мережі, якщо передавалися документи
XML певного вмісту. За допомогою спеціально сформованого документа XML також
можна було вичерпати можливості комп'ютера за процесорним часом, пам'яттю
або дескрипторами файлів.

Оскільки XML libvirt надходить із надійного джерела (фонової служби
libvirt), ми вважаємо, що цією вразливістю неможливо було скористатися.

Вразливість виправлено у libguestfs E<ge> 1.27.9, виправлення було зворотно
портовано до стабільних версій E<ge> 1.26.2, E<ge> 1.24.9, E<ge> 1.22.10 та
E<ge> 1.20.13.

=head2 Shellshock (bash CVE-2014-6271)

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

=head2 CVE-2014-8484

=head2 CVE-2014-8485

Ці дві вади є вадами програми із комплекту binutils GNU L<strings(1)>. Через
них вразливими стали інтерфейси L<guestfs(3)/guestfs_strings> та
L<guestfs(3)/guestfs_strings_e> у libguestfs. Обробка за допомогою strings
відповідно сформованого файла могла призвести до виконання довільного коду
(область виконання обмежено базовою системою libguestfs).

У libguestfs E<ge> 1.29.5 та E<ge> 1.28.3 використано параметр C<strings>
I<-a> для того, щоб уникнути обробки файлів за допомогою BFD.

=head2 CVE-2015-5745

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

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

=over 4

=item *

ваша програма libguestfs запускає ненадійні програми з гостьової системи (за
допомогою L<guestfs(3)/guestfs_sh> тощо) або

=item *

у коді файлових систем ядра буде виявлено іншу властивість (наприклад), яка
надає змогу відповідним чином створеній файловій системі захопити контроль
над базовою системою.

=back

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

=head2 Права доступу до F<.ssh> і F<.ssh/authorized_keys>

L<https://bugzilla.redhat.com/1260778>

У програмах L<virt-customize(1)>, L<virt-sysprep(1)> та L<virt-builder(1)>
передбачено параметр I<--ssh-inject> для вставляння ключа SSH до образів
дисків віртуальної машини. Для виконання цього завдання програми можуть
створювати каталог F<~user/.ssh> і файл F<~user/.ssh/authorized_keys> у
гостьовій системі.

У libguestfs E<lt> 1.31.5 та libguestfs E<lt> 1.30.2 для нового каталогу і
файла вибираються режими доступу C<0755> і C<0644>, відповідно. Втім, такі
права доступу (особливо до F<~user/.ssh>) є ширшими за ті, які використовує
OpenSSH. У поточних версіях libguestfs каталог і файл створюються із режимом
доступу C<0700> і C<0600>, відповідно.

=head2 CVE-2015-8869

L<https://bugzilla.redhat.com/CVE-2015-8869>

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

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

Вразливості у програмі L<wrestool(1)> з пакунка C<icoutils> може бути
використано для локального виконання коду у основній системі.

Коли засіб інспектування libguestfs (див. L</Inspection security> вище)
виявляє гостьову систему Windows XP або Windows 7 і отримує запит щодо
пошуку пов'язаної піктограми гостьової системи, засіб інспектування отримує
файл, який не є безпечним, з гостьової системи і запускає C<wrestool -x> для
цього файла. Це може призвести до виконання коду у основній
системі. Зловмисники можуть створити образ диска або гостьову систему, яка
виглядатиме як гостьова система Windows для засобу інспектування libguestfs,
тому те, що у вас немає гостьових систем Windows, не допоможе вберегтися від
вразливості.

Потенційно вразливими є усі програми, які викликають програмний інтерфейс
libguestfs C<guestfs_inspect_get_icon>. Такими програмами, зокрема, є
L<virt-inspector(1)> та L<virt-manager(1)>.

Усунути проблему можна, оновивши icoutils до невразливої версії (принаймні
до 0.31.1).

=head2 CVE-2017-7244, CVE-2017-7245, CVE-2017-7246

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

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

=head2 CVE-2018-11806

Вразливості у засобах обробки роботи користувача qemu у мережі (SLIRP)
надають змогу за допомогою спеціально сформованого образу файлової системи
перебрати контроль над qemu і за її допомогою атакувати основну систему.

Це впливає на роботу libguestfs, якщо встановлено модуль обробки C<direct>
I<і> увімкнено роботу у мережі.

Модуль direct є типовим для програми із основної гілки розробки, але не у
дистрибутивах Linux, які використовують qemu, зокрема у Fedora, Red Hat
Enterprise Linux та CentOS. Цей модуль може бути також вибрано за допомогою
значення змінної середовища C<LIBGUESTFS_BACKEND=direct> або виклику
S<C<guestfs_set_backend (g, "direct")>>.

Робота у мережі автоматично вмикається деякими програмами (наприклад
L<virt-builder(1)>) або під час виклику у коді S<C<guestfs_set_network (g,
1)>> (нетипові параметри функції).

Модуль обробки libvirt є невразливим.

Усунути проблему можна оновленням qemu до виправленої версії
(див.
L<https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg01012.html>).

=head1 ТАКОЖ ПЕРЕГЛЯНЬТЕ

L<guestfs(3)>, L<guestfs-internals(1)>, L<guestfs-release-notes(1)>,
L<guestfs-testing(1)>, L<http://libguestfs.org/>.

=head1 АВТОРИ

Richard W.M. Jones (C<rjones at redhat dot com>)

=head1 АВТОРСЬКІ ПРАВА

Copyright (C) 2009-2020 Red Hat Inc.