Дослідження описує практичні атаки, що обходять захист MTE в Chrome та Linux

Таблиця посилань

Анотація

1. Вступ

2. Передумови

• Розширення тегування пам'яті
• Атака спекулятивного виконання

3. Модель загроз

4. Пошук гаджетів витоку тегів

• Шаблон витоку тегів
• Фазінг витоку тегів

5. Гаджети TIKTAG

• TIKTAG-v1: експлуатація скорочення спекуляції
• TIKTAG-v2: експлуатація переадресації збереження до завантаження

6. Реальні атаки

6.1. Атака на Chrome

7. Оцінка

8. Пов'язані роботи

9. Висновок та посилання

\

Реальні атаки

Щоб продемонструвати можливість експлуатації гаджетів TIKTAG у пом'якшенні на основі MTE, цей розділ розробляє дві реальні атаки проти Chrome та ядра Linux (Рисунок 9). Існує кілька проблем для запуску реальних атак з використанням гаджетів TIKTAG. По-перше, гаджети TIKTAG повинні виконуватися в цільовому адресному просторі, що вимагає від зловмисника створення або пошуку гаджетів з цільової системи. По-друге, зловмисник повинен контролювати та спостерігати за станом кешу, щоб витікати результати перевірки тегів. Далі ми демонструємо реальні атаки з використанням гаджетів TIKTAG на двох реальних системах: браузері Google Chrome (§6.1) та ядрі Linux (§6.2), і обговорюємо стратегії пом'якшення.

\ 6.1. Атака на Chrome

браузер Вебсайт-браузер є основною поверхнею атаки для веб-атак, оскільки він обробляє ненадійний веб-контент, такий як JavaScript та HTML. Спочатку ми розглядаємо модель загроз (§6.1.1) і надаємо гаджет TIKTAG, побудований у движку JavaScript V8 (§6.1.2). Потім ми демонструємо ефективність гаджетів TIKTAG в експлуатації браузера (§6.1.3) і обговорюємо стратегії пом'якшення (§6.1.4).

\ ==6.1.1. Модель загроз.== Ми дотримуємося типової моделі загроз атак браузера Chrome, де зловмисник має на меті експлуатувати вразливості пошкодження пам'яті в процесі рендерера. Ми припускаємо, що користувач-жертва відвідує веб-сайт, контрольований зловмисником, який надає шкідливу веб-сторінку. Веб-сторінка включає створені HTML та JavaScript, які експлуатують вразливості пошкодження пам'яті в процесі рендерера жертви. Ми припускаємо, що всі сучасні техніки пом'якшення Chrome впроваджені, включаючи ASLR [18], CFI [15], ізоляцію сайту [53] та пісочницю V8 [56]. Крім того, як ортогональний захист, ми припускаємо, що процес рендерера вмикає випадкове тегування MTE в PartitionAlloc [2].

\ ==6.1.2. Конструювання гаджета TIKTAG.== У середовищі JavaScript V8, TIKTAG-v2 був успішно побудований і витік теги MTE будь-якої адреси пам'яті. Однак ми не знайшли конструйованого гаджета TIKTAG-v1, оскільки жорстке обмеження часу між BR та CHECK не було здійсненним у нашій техніці спекулятивного виходу з пісочниці V8 (§A).

V8 TikTag-v2 гаджет. Рисунок 8 є гаджетом TIKTAG-v2, побудованим у движку JavaScript V8 та його псевдо-C коді після JIT компіляції. З цим гаджетом зловмисник може дізнатися, чи збігається вгаданий тег Tg з тегом Tm, призначеним для target_addr. Зловмисник готує три масиви, slow, victim, probe, та значення idx. slow є Unit8Array з довжиною 64 і доступ до нього здійснюється в BR для запуску неправильного передбачення гілки. victim є Float64Array з довжиною 64, до якого здійснюється доступ для запуску переадресації збереження до завантаження. probe є Uint8Array з довжиною 512, і до нього здійснюється доступ в

\ TEST для витоку результату перевірки тегу. Значення idx типу Number використовується для доступу за межами меж victim. значення idx вибирається так, що victim[idx] вказує на target_addr з вгаданим тегом Tg (тобто (Tg«56)|target_addr). Щоб спекулятивно отримати доступ до target_addr за межами пісочниці V8, ми використали техніку спекулятивного виходу з пісочниці V8, яку ми виявили під час нашого дослідження, яку ми детально описуємо в §A. Рядок 8 Рисунка 8a є блоком BR гаджета TIKTAG-v2, що запускає неправильне передбачення гілки з slow[0].

\ Рядки 12-13 є блоком CHECK, який виконує переадресацію збереження до завантаження з victim[idx], доступ до target_addr з вгаданим тегом Tg. Коли цей код JIT-компілюється (Рисунок 8b), виконується перевірка меж, порівнюючи idx з victim.length. Якщо idx є індексом за межами, код повертає undefined, але якщо поле victim.length займає багато часу для завантаження, CPU спекулятивно виконує наступні інструкції збереження та завантаження.

\ Після цього рядок 17 реалізує блок TEST, який отримує доступ до probe з переадресованим значенням val як індексом. Знову ж таки, перевірка меж для val відносно довжини probe передує, але ця перевірка проходить, оскільки PROBE_OFFSET менший за довжину масиву probe. В результаті probe[PROBE_OFFSET] кешується лише тоді, коли переадресація збереження до завантаження проходить успішно, що відбувається, коли Tg збігається з Tm.

\ ==6.1.3. Атака обходу Chrome MTE.== Рисунок 9a ілюструє загальну атаку обходу MTE на браузер Chrome з довільним примітивом витоку тегів гаджетів TIKTAG. Ми припускаємо вразливість переповнення буфера в процесі рендерера, де експлуатація тимчасової вразливості (наприклад, використання після звільнення) в основному така сама. Вразливість переповнює вказівник (тобто vuln_ptr) на вразливий об'єкт (тобто objvuln), пошкоджуючи сусідній об'єкт (тобто objtarget).

\ З впровадженням MTE PartitionAlloc два об'єкти мають різні теги з ймовірністю 14/15. Щоб уникнути виникнення виключення, зловмисник повинен переконатися, що теги objvuln та objtarget однакові. TIKTAG-v2 може бути використаний для витоку тегу objvuln ( 1 ) та objtarget ( 2 ). Якщо обидва витоки тегів однакові, зловмисник експлуатує вразливість, яка не викличе помилку перевірки тегу ( 3 ). В іншому випадку зловмисник звільняє та перевиділяє objtarget і повертається до першого кроку, поки теги не збіжаться.

\ ==Запуск побічного каналу кешу.== Щоб успішно експлуатувати гаджет TIKTAG, зловмисник повинен задовольнити наступні вимоги:

i) навчання гілок,

ii) контроль кешу, та

iii) вимірювання кешу. Усі три вимоги можуть бути задоволені в JavaScript.

По-перше, зловмисник може навчити передбачувач гілок, запустивши гаджет з ненульовим slow[0] та idx в межах, і запустити неправильне передбачення гілки в BR з нульовим значенням в slow[0] та idx за межами.

По-друге, зловмисник може витіснити рядки кешу slow[0], victim.length та probe[PROBE_OFFSET] з методами витіснення кешу JavaScript [8, 21, 70].

По-третє, зловмисник може виміряти стан кешу probe[PROBE_OFFSET] з таймером високої роздільної здатності на основі SharedArrayBuffer [16, 58].

\ ==Експлуатація вразливостей пошкодження пам'яті.== За умови витоку тегів MTE, зловмисник може експлуатувати просторові та тимчасові вразливості пошкодження пам'яті в рендерері. Стратегія атаки в основному така сама, як і традиційні атаки пошкодження пам'яті, але повинна гарантувати, що вразливість не викличе помилку перевірки тегу, використовуючи витоки тегів. Ми далі детально описуємо стратегію атаки в §C.

\ ==6.1.4. Пом'якшення.== Щоб пом'якшити атаки обходу MTE на основі гаджетів TIKTAG в процесі рендерера браузера, можна використовувати наступні пом'якшення:

i) пісочниця, обізнана про спекулятивне виконання: Щоб зупинити зловмисників від запуску атак на основі TIKTAG з пісочниці, такої як пісочниця V8, пісочниця може бути зміцнена шляхом запобігання будь-якому спекулятивному доступу до пам'яті за межами області пам'яті пісочниці. Хоча сучасні веб-браузери використовують пісочницю для ізоляції ненадійного веб-контенту від рендерера, вони часто ігнорують спекулятивні шляхи.

\ Наприклад, пісочниця Chrome V8 [56] та пісочниця Safari Webkit [1] не повністю опосередковують спекулятивні шляхи [27]. На основі поточних методів стиснення вказівників [64], спекулятивні шляхи можуть бути обмежені областю пісочниці шляхом маскування старших бітів вказівників.

\ ii) бар'єр спекуляції: Як запропоновано в §5, розміщення бар'єра спекуляції після BR для потенційних гаджетів TIKTAG може запобігти атакам спекулятивного витоку тегів. Однак це пом'якшення може бути не застосовне в критичному для продуктивності середовищі браузера, оскільки може ввести значні накладні витрати на продуктивність.

\ iii) запобігання конструюванню гаджетів: як запропоновано в §5.2, гаджет TIKTAG-v2 може бути пом'якшений шляхом додавання інструкцій між інструкціями збереження та завантаження. Гаджет TIKTAGv1, хоча ми не знайшли експлуатованого, може бути пом'якшений шляхом додавання інструкцій між гілкою та доступом до пам'яті, як описано в §5.1.

\ 6.2. Атака на ядро Linux

ядро Linux на ARM широко використовується для мобільних пристроїв, серверів та пристроїв IoT, що робить його привабливою метою атаки. Експлуатація вразливості пошкодження пам'яті в ядрі може підвищити привілеї користувача, і тому MTE є перспективним механізмом захисту для ядра Linux. Атаки на основі TIKTAG проти ядра Linux створюють унікальні виклики, відмінні від атаки на браузер (§6.1).

\ Це пояснюється тим, що адресний простір зловмисника ізольований від адресного простору ядра, де буде виконуватися гаджет. Далі ми спочатку розглядаємо модель загроз ядра Linux (§6.2.1) і надаємо доказ концепції гаджета TIKTAG, який ми виявили в ядрі Linux (§6.2.2). Нарешті, ми демонструємо ефективність гаджетів TIKTAG в експлуатації вразливостей ядра Linux (§6.2.3).

\ ==6.2.1. Модель загроз.== Модель загроз тут в основному така сама, як і для типових атак підвищення привілеїв проти ядра. Зокрема, ми зосереджуємося на ядрі Android Linux на основі ARM, зміцненому з стандартними захистами ядра (наприклад, KASLR, SMEP, SMAP та CFI). Ми далі припускаємо, що ядро зміцнене рішенням випадкового тегування MTE, подібним до готових до виробництва рішень MTE, Scudo [3].

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

\ невідповідними тегами викличе помилку перевірки тегу, що є небажаним для реальних експлойтів. Одним критичним викликом у цій атаці є те, що гаджет повинен бути побудований шляхом повторного використання існуючого коду ядра та виконаний системними викликами, які зловмисник може викликати. Оскільки архітектура ARMv8 розділяє таблиці сторінок користувача та ядра, гаджети користувацького простору не можуть спекулятивно отримати доступ до пам'яті ядра. Ця конфігурація дуже відрізняється від моделі загроз атаки на браузер (§6.1), яка використовувала код, наданий зловмисником, для конструювання гаджета. Ми також виключили конструювання гаджетів на основі eBPF [17, 28], оскільки eBPF недоступний для непривілейованого процесу Android [33].

\ ==6.2.2. Гаджет ядра TikTag==. Як описано в §4.1, гаджети TIKTAG повинні відповідати кільком вимогам, і кожна вимога створює виклики в середовищі ядра.

По-перше, в BR, неправильне передбачення гілки повинно бути запущено з cond_ptr, який повинен бути контрольованим з користувацького простору. Оскільки останні процесори AArch64 ізолюють навчання передбачення гілок між користувачем та ядром [33], навчання гілок необхідно виконувати з простору ядра.

По-друге, в CHECK, guess_ptr повинен бути розіменований. guess_ptr повинен бути створений з користувацького простору таким чином, щоб він вбудовував вгаданий тег (Tg) і вказував на адресу ядра (тобто target_addr), щоб витікати тег (Tm). На відміну від середовища JavaScript браузера (§6.1), дані, надані користувачем, сильно очищаються в системних викликах, тому важко створити довільний вказівник ядра.

\ Наприклад, access_ok() забезпечує, що наданий користувачем вказівник вказує на користувацький простір, а макрос array_index_nospec запобігає спекулятивному доступу за межами з наданим користувачем індексом. Таким чином, guess_ptr повинен бути існуючим вказівником ядра, зокрема вразливим вказівником, який викликає пошкодження пам'яті. Наприклад, може бути використаний висячий вказівник в використанні після звільнення (UAF) або вказівник за межами в переповненні буфера. Нарешті, в TEST, test_ptr повинен бути розіменований, і test_ptr повинен бути доступним з користувацького простору. Щоб полегшити вимірювання стану кешу, test_ptr повинен бути вказівником користувацького простору, наданим через аргумент системного виклику.

\ ==Виявлені гаджети.== Ми вручну проаналізували вихідний код ядра Linux, щоб знайти гаджет TIKTAG, який відповідає вищезазначеним вимогам. В результаті ми знайшли один потенційно експлуатований гаджет TIKTAG-v1 в snd_timer_user_read() (Рисунок 10). Цей гаджет виконує вимоги TIKTAG-v1 (§5.1). У рядку 10 (тобто BR), оператор switch запускає неправильне передбачення гілки з контрольованим користувачем значенням tu->tread (тобто cond_ptr). У рядках 14-17 (тобто CHECK), tread (тобто guess_ptr) розіменовується чотирма інструкціями завантаження. tread вказує на об'єкт struct snd_timer_tread64, який зловмисник може довільно виділяти та звільняти.

\ Якщо тимчасова вразливість перетворює tread у висячий вказівник, він може бути використаний як guess_ptr. У рядку 20 (тобто TEST), вказівник користувацького простору buffer (тобто test_ptr) розіменовується в copy_to_user. Оскільки цей гаджет не доступний безпосередньо з користувацького простору, ми внесли невелику модифікацію в код ядра; ми видалили ранній повернення для стандартного випадку в рядку 6. Це гарантує, що буфер доступний лише в спекулятивному шляху для спостереження різниці стану кешу через спекулятивне виконання.

\ Хоча ця модифікація не є реалістичною в реальному сценарії, вона демонструє потенційну експлуатованість гаджета, якщо були внесені подібні зміни коду. Ми виявили кілька більше потенційно експлуатованих гаджетів, але не змогли спостерігати різницю стану кешу між збігом та невідповідністю тегів. Тим не менш, ми вважаємо, що є сильний потенціал для експлуатації цих гаджетів. Запуск атак на основі TIKTAG включає складну та чутливу інженерію, і тому ми не змогли експериментувати з усіма можливими випадками.

\ Особливо, TIKTAG-v1 покладається на скорочення спекуляції на події неправильного шляху, які також можуть включати помилки трансляції адрес або інші виключення на шляху неправильного передбачення гілки. Оскільки системні виклики включають складні потоки управління, скорочення спекуляції може не бути запущене, як очікувалося. Крім того, кілька гаджетів можуть стати експлуатованими при зміні коду ядра. Наприклад, гаджет TIKTAG-v1 в ip6mr_ioctl() не виявив поведінки витоку тегу MTE при виклику з його шляху системного виклику (тобто ioctl). Однак гаджет мав витік тегу, коли він був перенесений на інші системні виклики (наприклад, write) з простим потоком управління.

\ ==6.2.3. Атака обходу ядра MTE.== Рисунок 9b ілюструє атаки обходу MTE на ядро Linux. Беручи вразливість використання після звільнення як приклад, ми припускаємо, що зловмисник ідентифікував відповідний гаджет TIKTAG, SysTikTagUAF(), здатний витікати результат перевірки тегу висячого вказівника, створеного вразливістю. Наприклад, гаджет TIKTAG-v1 в snd_timer_user_read() (Рисунок 10) може витікати результат перевірки тегу tread, який може стати висячим вказівником через вразливість використання після звільнення або подвійного звільнення.

\ Атака відбувається наступним чином: по-перше, зловмисник звільняє об'єкт ядра (тобто objvuln) і залишає його вказівник (тобто vuln_ptr) як висячий вказівник ( 1 ). Далі, зловмисник виділяє інший об'єкт ядра (тобто objtarget) за адресою objvuln з SysAllocTarget() ( 2 ). Потім зловмисник викликає SysTikTag() з буфером користувацького простору (тобто ubuf) ( 3 ) і витікає результат перевірки тегу (тобто Tm == Tg) шляхом вимірювання затримки доступу ubuf ( 4 ). Якщо теги збігаються, зловмисник запускає SysExploitUAF(), системний виклик, який експлуатує вразливість використання після звільнення ( 5 ). В іншому випадку зловмисник перевиділяє objtarget, поки теги не збіжаться.

\ ==Запуск побічного каналу кешу.== Як у §6.1.3, успішна експлуатація гаджета TIKTAG вимагає i) навчання гілок, ii) контроль кешу та iii) вимірювання кешу. Для навчання гілок зловмисник може навчити передбачувач гілок і запустити спекуляцію з контрольованими користувачем умовами гілок з користувацького простору. Для контролю кешу зловмисник може очистити буфер користувацького простору (тобто ubuf), тоді як адреса пам'яті ядра може бути витіснена шляхом відскакування рядка кешу [25]. Для вимірювання кешу затримка доступу ubuf може бути виміряна за допомогою віртуального лічильника (тобто CNTVCT_EL0) або таймера на основі лічильника пам'яті (тобто роздільна здатність близька до циклу CPU).

\ ==Експлуатація вразливостей пошкодження пам'яті.== Гаджети TIKTAG дозволяють обійти MTE та експлуатувати вразливості пошкодження пам'яті ядра. Зловмисник може викликати гаджет TIKTAG в ядрі, щоб спекулятивно запустити пошкодження пам'яті та отримати результат перевірки тегу. Потім зловмисник може отримати результат перевірки тегу та запустити пошкодження пам'яті лише тоді, коли теги збігаються. Ми детально описуємо процес атаки обходу MTE ядра Linux в §D.

\ ==6.2.4. Пом'якшення.== Щоб пом'якшити гаджет TIKTAG в ядрі Linux, розробники ядра повинні розглянути наступні пом'якшення:

i) бар'єр спекуляції: бар'єри спекуляції можуть ефективно пом'якшити гаджет TIKTAG-v1 в ядрі Linux. Щоб запобігти витоку зловмисниками результату перевірки тегу через буфер користувацького простору, функції ядра, які отримують доступ до адрес користувацького простору, такі як copy_to_user та copy_from_user, можуть бути зміцнені бар'єрами спекуляції. Як описано в §5.1, витік результатів перевірки тегів з доступом до збереження може бути пом'якшений шляхом розміщення бар'єра спекуляції перед доступом до збереження (тобто TEST).

\ Наприклад, щоб пом'якшити гаджети, що використовують copy_to_user, бар'єр спекуляції може бути вставлений перед викликом copy_to_user. Для гаджетів, що використовують доступ до завантаження в буфер користувацького простору, бар'єри пом'якшують гаджети, якщо вставлені між гілкою та доступом до пам'яті ядра (тобто CHECK). Наприклад, щоб пом'якшити гаджети, що використовують copy_from_user, розробники ядра повинні ретельно проаналізувати базу коду ядра, щоб знайти шаблон умовної гілки, доступу до пам'яті ядра та copy_from_user(), і вставити бар'єр спекуляції між гілкою та доступом до пам'яті ядра.

\ ii) запобігання конструюванню гаджетів: щоб усунути потенційні гаджети TIKTAG в ядрі Linux, вихідний код ядра може бути проаналізований та виправлений. Оскільки гаджети TIKTAG також можуть бути побудовані оптимізаціями компілятора, може бути проведений бінарний аналіз. Для кожного виявленого гаджета інструкції можуть бути переупорядковані або можуть бути вставлені додаткові інструкції, щоб запобігти конструюванню гаджета, дотримуючись стратегій пом'якшення в §5.1 та §5.2.

:::info Автори:

1. Juhee Kim
2. Jinbum Park
3. Sihyeon Roh
4. Jaeyoung Chung
5. Youngjoo Lee
6. Taesoo Kim
7. Byoungyoung Lee

:::

:::info ця стаття доступна на arxiv за ліцензією CC 4.0.

:::

\