В Snapd була виявлена вразливість що вже описано в (CVE-2019-7304), що дозволяє непривілейованому користувачеві отримати права адміністратора (root) в системі.
Для тих, хто не знайомий із Snapd, ми можемо сказати вам, що це набір інструментів для управління автономними пакетами у форматі snap. Для тестування вразливостей систем було опубліковано два прототипи експлоїту.
- Перший, що дозволяє зловмиснику створити нового користувача в системі.
- Другий дозволяє зловмисникові встановити будь-який миттєвий пакет в системі та запустити код як root (встановивши пакет у режимі "devmode" із вкладеним драйвером, що викликається з правами root при установці пакету).
Що це за подвиги?
Експлойт, створений для використання першої вказаної можливості раніше пропустити перевірки контролю доступу - використовувати обмежену функцію API локальної служби snapd.
Це запитує у системи ім’я користувача та відкритий ключ SSH із вказаної адреси електронної пошти, а потім створює локального користувача на основі цього значення.
Для успішного використання цієї версії потрібне вихідне підключення до Інтернету та служба SSH, доступна через localhost.
Другий подвиг створений скористатися переліченим другим пунктом, на відміну від попереднього описаного подвигу, для цього не потрібна служба SSH.
також він працюватиме на новіших версіях Ubuntu без підключення до Інтернету, роблячи його стійким до змін та ефективним в обмежених умовах.
Цей подвиг Він також повинен бути ефективним для систем, що не належать до Ubuntu, у яких встановлено snapd, але не відповідають API через синтаксис оболонки Linux.
У деяких старих системах Ubuntu (наприклад, версія 16.04) можуть не бути встановлені компоненти snapd, необхідні для завантаження.
Якщо це так, ця версія експлоїту може викликати його для встановлення цих залежностей. Під час такої інсталяції snapd можна оновити до невразливої версії.
Щоб дізнатися трохи більше про них, ви можете отримати більше деталей У наступному посиланні.
З чого складається ця виявлена помилка?
Вразливість обумовлена відсутність належних перевірок у snapd під час обробки зовнішньої адреси сокета в процесі оцінки прав доступу для сокетів Unix.
Під час обробки запитів до API через сокет Unix, перевіряється UID користувача, пов'язаного з підключенням, і на основі цього приймається рішення про доступ.
Користувач може вкласти рядок «; uid = 0; » до імені файлу із сокетом (наприклад, створіть сокет "/ tmp / sock; uid = 0;"), і цей рядок буде оброблений як частина адреси клієнтського сокета.
При аналізі параметрів у snapd, ідентифікатор користувача призначається циклічним пошуком за допомогою маски "; Uid =" у рядку, який також включає ім'я файлу з сокетом (наприклад, при створенні клієнтського сокета "/ tmp / sock; uid = 0;" цей рядок приймає форму "pid = 5275; uid = 1000; socket = / run / snapd.socket; / tmp / sock; uid = 0; «).
Таким чином, якщо є ланцюжок "; Uid = 0;" в назві сокета ідентифікатор буде присвоєний йому, а не регулярному параметру з фактичним UID.
Локальний зловмисник може використовувати цю помилку для доступу до сокета /run/snapd.socket до привілейованого API snapd та отримання привілеїв адміністратора (попередні вразливості використовують API v2 / create-user та / v2 / snaps).
На які версії це впливає і чи вже існує рішення?
Проблема проявляється у версіях snapd з 2.28 до 2.37 і впливає на всі підтримувані гілки Ubuntu (з 14.04 по 18.10), а також у дистрибутивах, похідних від будь-якої із зазначених версій.
Проблема також впливає на дистрибутиви Fedora та Debian, в якому snapd пропонується зі звичайних сховищ.
Уразливість була виправлена у випуску snapd 2.37.1, а також оновлення пакунків для дистрибутивів Ubuntu та Debian.