macOS SIP
Основна інформація
Захист цілісності системи (SIP) в macOS є механізмом, призначеним для запобігання навіть найбільш привілейованим користувачам вносити несанкціоновані зміни до ключових системних папок. Ця функція відіграє важливу роль у підтримці цілісності системи, обмежуючи дії, такі як додавання, модифікація або видалення файлів у захищених зонах. Основні папки, захищені SIP, включають:
/System
/bin
/sbin
/usr
Правила, які регулюють поведінку SIP, визначені в конфігураційному файлі, розташованому за адресою /System/Library/Sandbox/rootless.conf
. У цьому файлі шляхи, які починаються з зірочки (*), позначаються як винятки з інакше суворих обмежень SIP.
Розгляньте наведену нижче ілюстрацію:
Цей фрагмент вказує на те, що хоча SIP зазвичай захищає /usr
директорію, є специфічні підкаталоги (/usr/libexec/cups
, /usr/local
, і /usr/share/man
), де зміни дозволені, як вказано зірочкою (*) перед їхніми шляхами.
Щоб перевірити, чи директорія або файл захищені SIP, ви можете використовувати команду ls -lOd
для перевірки наявності прапорця restricted
або sunlnk
. Наприклад:
У цьому випадку прапорець sunlnk
означає, що каталог /usr/libexec/cups
сам по собі не може бути видалений, хоча файли в ньому можуть бути створені, змінені або видалені.
З іншого боку:
Тут restricted
прапорець вказує на те, що директорія /usr/libexec
захищена SIP. У директорії, захищеній SIP, файли не можуть бути створені, змінені або видалені.
Більше того, якщо файл містить атрибут com.apple.rootless
розширений атрибут, цей файл також буде захищений SIP.
Зверніть увагу, що Sandbox хук hook_vnode_check_setextattr
запобігає будь-яким спробам змінити розширений атрибут com.apple.rootless
.
SIP також обмежує інші дії root, такі як:
Завантаження ненадійних розширень ядра
Отримання task-ports для процесів, підписаних Apple
Зміна змінних NVRAM
Дозвіл налагодження ядра
Опції зберігаються у змінній nvram як бітовий прапорець (csr-active-config
на Intel і lp-sip0
читається з завантаженого Device Tree для ARM). Ви можете знайти прапорці в вихідному коді XNU у csr.sh
:
Статус SIP
Ви можете перевірити, чи увімкнено SIP на вашій системі, за допомогою наступної команди:
Якщо вам потрібно вимкнути SIP, ви повинні перезавантажити комп'ютер у режимі відновлення (натискаючи Command+R під час запуску), а потім виконати наступну команду:
Якщо ви хочете зберегти SIP увімкненим, але видалити захист від налагодження, ви можете зробити це за допомогою:
Інші обмеження
Забороняє завантаження непідписаних розширень ядра (kexts), забезпечуючи, що лише перевірені розширення взаємодіють з ядром системи.
Запобігає налагодженню процесів системи macOS, захищаючи основні компоненти системи від несанкціонованого доступу та модифікації.
Гальмує інструменти на кшталт dtrace від перевірки системних процесів, ще більше захищаючи цілісність роботи системи.
Дізнайтеся більше про інформацію SIP у цій доповіді.
Права, пов'язані з SIP
com.apple.rootless.xpc.bootstrap
: Контроль launchdcom.apple.rootless.install[.heritable]
: Доступ до файлової системиcom.apple.rootless.kext-management
:kext_request
com.apple.rootless.datavault.controller
: Керування UF_DATAVAULTcom.apple.rootless.xpc.bootstrap
: Можливості налаштування XPCcom.apple.rootless.xpc.effective-root
: Root через launchd XPCcom.apple.rootless.restricted-block-devices
: Доступ до сирих блочних пристроївcom.apple.rootless.internal.installer-equivalent
: Безперешкодний доступ до файлової системиcom.apple.rootless.restricted-nvram-variables[.heritable]
: Повний доступ до NVRAMcom.apple.rootless.storage.label
: Модифікувати файли, обмежені com.apple.rootless xattr з відповідною міткоюcom.apple.rootless.volume.VM.label
: Підтримувати обмін VM на томі
Обхід SIP
Обхід SIP дозволяє зловмиснику:
Доступ до даних користувача: Читати чутливі дані користувача, такі як електронна пошта, повідомлення та історія Safari з усіх облікових записів користувачів.
Обхід TCC: Прямо маніпулювати базою даних TCC (Прозорість, Згода та Контроль), щоб надати несанкціонований доступ до веб-камери, мікрофона та інших ресурсів.
Встановити постійність: Розмістити шкідливе ПЗ в захищених SIP місцях, роблячи його стійким до видалення, навіть з правами root. Це також включає потенціал для підробки Інструменту видалення шкідливого ПЗ (MRT).
Завантажувати розширення ядра: Хоча є додаткові запобіжники, обхід SIP спрощує процес завантаження непідписаних розширень ядра.
Пакети установника
Пакети установника, підписані сертифікатом Apple, можуть обійти його захист. Це означає, що навіть пакети, підписані стандартними розробниками, будуть заблоковані, якщо вони намагатимуться змінити каталоги, захищені SIP.
Невідомий файл SIP
Однією з потенційних лазівок є те, що якщо файл вказано в rootless.conf
, але наразі не існує, його можна створити. Шкідливе ПЗ може скористатися цим, щоб встановити постійність в системі. Наприклад, шкідлива програма може створити файл .plist у /System/Library/LaunchDaemons
, якщо він вказаний у rootless.conf
, але не присутній.
com.apple.rootless.install.heritable
Права com.apple.rootless.install.heritable
дозволяють обійти SIP
Було виявлено, що можливо поміняти пакет установника після того, як система перевірила його код підпису, і тоді система встановить шкідливий пакет замість оригінального. Оскільки ці дії виконувалися system_installd
, це дозволяло обійти SIP.
Якщо пакет було встановлено з змонтованого образу або зовнішнього диска, установник виконував двійковий файл з цієї файлової системи (замість SIP-захищеного місця), змушуючи system_installd
виконувати довільний двійковий файл.
CVE-2021-30892 - Shrootless
Дослідники з цього блогу виявили вразливість у механізмі захисту цілісності системи (SIP) macOS, відому як вразливість 'Shrootless'. Ця вразливість зосереджена навколо демона system_installd
, який має право com.apple.rootless.install.heritable
, що дозволяє будь-якому з його дочірніх процесів обходити обмеження файлової системи SIP.
Демон system_installd
буде встановлювати пакети, які були підписані Apple.
Дослідники виявили, що під час встановлення пакета, підписаного Apple (.pkg файл), system_installd
виконує будь-які скрипти після установки, включені в пакет. Ці скрипти виконуються за допомогою стандартної оболонки, zsh
, яка автоматично виконує команди з файлу /etc/zshenv
, якщо він існує, навіть у неінтерактивному режимі. Цю поведінку можна використовувати зловмисниками: створивши шкідливий файл /etc/zshenv
і чекаючи, поки system_installd
викличе zsh
, вони можуть виконувати довільні операції на пристрої.
Більше того, було виявлено, що /etc/zshenv
може використовуватися як загальна техніка атаки, не лише для обходу SIP. Кожен профіль користувача має файл ~/.zshenv
, який поводиться так само, як /etc/zshenv
, але не вимагає прав root. Цей файл може використовуватися як механізм постійності, спрацьовуючи щоразу, коли запускається zsh
, або як механізм підвищення привілеїв. Якщо адміністратор підвищує привілеї до root, використовуючи sudo -s
або sudo <command>
, файл ~/.zshenv
буде спрацьовувати, ефективно підвищуючи привілеї до root.
У CVE-2022-22583 було виявлено, що той же процес system_installd
все ще можна зловживати, оскільки він поміщав скрипт після установки в папку з випадковою назвою, захищену SIP у /tmp
. Справа в тому, що /tmp
сам по собі не захищений SIP, тому було можливим змонтувати віртуальний образ на ньому, потім установник помістив би туди скрипт після установки, зняв би віртуальний образ, відтворив би всі папки та додав би скрипт після установки з payload для виконання.
Виявлено вразливість, при якій fsck_cs
був введений в оману, що призвело до пошкодження важливого файлу, через його здатність слідувати символічним посиланням. Зокрема, зловмисники створили посилання з /dev/diskX
на файл /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist
. Виконання fsck_cs
на /dev/diskX
призвело до пошкодження Info.plist
. Цілісність цього файлу є важливою для SIP (Захист цілісності системи) операційної системи, яка контролює завантаження розширень ядра. Після пошкодження здатність SIP керувати виключеннями ядра порушується.
Команди для використання цієї вразливості:
The exploitation of this vulnerability has severe implications. The Info.plist
file, normally responsible for managing permissions for kernel extensions, becomes ineffective. This includes the inability to blacklist certain extensions, such as AppleHWAccess.kext
. Consequently, with the SIP's control mechanism out of order, this extension can be loaded, granting unauthorized read and write access to the system's RAM.
Було можливим змонтувати нову файлову систему через захищені папки SIP, щоб обійти захист.
Система налаштована на завантаження з вбудованого образу диска установника в Install macOS Sierra.app
для оновлення ОС, використовуючи утиліту bless
. Використовується наступна команда:
Безпека цього процесу може бути скомпрометована, якщо зловмисник змінює образ оновлення (InstallESD.dmg
) перед завантаженням. Стратегія полягає в заміні динамічного завантажувача (dyld) на шкідливу версію (libBaseIA.dylib
). Ця заміна призводить до виконання коду зловмисника, коли ініціюється інсталятор.
Код зловмисника отримує контроль під час процесу оновлення, експлуатуючи довіру системи до інсталятора. Атака продовжується шляхом зміни образу InstallESD.dmg
за допомогою методу swizzling, особливо націлюючись на метод extractBootBits
. Це дозволяє інжектувати шкідливий код перед використанням образу диска.
Більше того, в InstallESD.dmg
є BaseSystem.dmg
, який слугує кореневою файловою системою коду оновлення. Інжекція динамічної бібліотеки в цей файл дозволяє шкідливому коду працювати в процесі, здатному змінювати файли на рівні ОС, що значно підвищує потенціал для компрометації системи.
У цій доповіді з DEF CON 31 показано, як systemmigrationd
(який може обійти SIP) виконує bash та perl скрипти, які можуть бути зловживані через змінні середовища BASH_ENV
та PERL5OPT
.
CVE-2023-42860
Як детально описано в цьому блозі, скрипт postinstall
з пакетів InstallAssistant.pkg
дозволяв виконання:
and it was possible to create a symlink in ${SHARED_SUPPORT_PATH}/SharedSupport.dmg
that would allow a user to unrestrict any file, bypassing SIP protection.
com.apple.rootless.install
The entitlement com.apple.rootless.install
allows to bypass SIP
The entitlement com.apple.rootless.install
is known to bypass System Integrity Protection (SIP) on macOS. This was notably mentioned in relation to CVE-2022-26712.
In this specific case, the system XPC service located at /System/Library/PrivateFrameworks/ShoveService.framework/Versions/A/XPCServices/SystemShoveService.xpc
possesses this entitlement. This allows the related process to circumvent SIP constraints. Furthermore, this service notably presents a method that permits the movement of files without enforcing any security measures.
Sealed System Snapshots
Sealed System Snapshots are a feature introduced by Apple in macOS Big Sur (macOS 11) as a part of its System Integrity Protection (SIP) mechanism to provide an additional layer of security and system stability. They are essentially read-only versions of the system volume.
Here's a more detailed look:
Незмінна система: Sealed System Snapshots роблять об'єм системи macOS "незмінним", що означає, що його не можна змінювати. Це запобігає будь-яким несанкціонованим або випадковим змінам системи, які можуть загрожувати безпеці або стабільності системи.
Оновлення системного програмного забезпечення: Коли ви встановлюєте оновлення або апгрейди macOS, macOS створює новий знімок системи. Об'єм завантаження macOS потім використовує APFS (Apple File System) для переходу на цей новий знімок. Весь процес застосування оновлень стає безпечнішим і надійнішим, оскільки система завжди може повернутися до попереднього знімка, якщо щось піде не так під час оновлення.
Розділення даних: У поєднанні з концепцією розділення об'ємів даних і системи, введеною в macOS Catalina, функція Sealed System Snapshot забезпечує, що всі ваші дані та налаштування зберігаються на окремому об'ємі "Data". Це розділення робить ваші дані незалежними від системи, що спрощує процес оновлення системи та підвищує безпеку системи.
Пам'ятайте, що ці знімки автоматично керуються macOS і не займають додаткового місця на вашому диску завдяки можливостям спільного використання простору APFS. Також важливо зазначити, що ці знімки відрізняються від знімків Time Machine, які є резервними копіями всієї системи, доступними для користувача.
Check Snapshots
The command diskutil apfs list
lists the details of the APFS volumes and their layout:
In the previous output it's possible to see that user-accessible locations are mounted under /System/Volumes/Data
.
Moreover, macOS System volume snapshot is mounted in /
and it's sealed (cryptographically signed by the OS). So, if SIP is bypassed and modifies it, the OS won't boot anymore.
It's also possible to verify that seal is enabled by running:
Крім того, знімок диска також змонтовано як тільки для читання:
Last updated