Атака повернення в бібліотеку

(Перенаправлено з Ret2libc)

Атака повернення в бібліотеку (англ. Return-to-libc attack) — один з видів комп'ютерних атак, популярних на x86-сумісних машинах і схожих з ними[джерело?], пов'язаних з переповненням буфера, коли адреса повернення у функцію у стеку викликів підміняється адресою іншої функції в програмі, і в наступну частину стека записуються параметри для виклику функції. Ця техніка дозволяє нападнику виконати якусь існуючу функцію без необхідності впроваджувати шкідливий код в програму.

У GNU, GNU/Linux та інших UNIX-подібних ОС є спільна бібліотека libc, що надає функції мови Сі та стандарту POSIX, наприклад system() для виконання довільних програм. Подібні бібліотеки існують і в ОС сімейства Windows. Хоча атакуючий може змусити програму здійснити перехід на будь-яку адресу, більшість програм використовують libc (злінковані з нею), в ній є зручні функції запуску довільних програм. Тому функції стандартної бібліотеки є найбільш ймовірною метою подібних експлойтів, що і дало назву класу атак. Тим не менш можливо використання інших адрес повернення, у тому числі функцій з інших бібліотек і (або) фрагментів коду (у тому числі повернення на середину інструкції), докладніше див. Зворотно-орієнтоване програмування.

Захист від атаки ред.

Стек з захистом від виконання коду може запобігти деяким способам використання переповнення буфера, але не повернення в бібліотеку, оскільки в даній атаці використовується вже існуючий в адресному просторі процесу виконуваний код. З іншого боку, на відміну від класичних shellcode, дана атака може використовувати тільки існуючі функції. Захист stack-smashing[en] з GCC (відомий як ProPolice) і подібні захисти інших систем можуть запобігти або значно ускладнити цю атаку, так як вони виявляють порушення цілісності стека і, можливо, помітять впроваджені дані.

Технологія Address Space Layout Randomization (ASLR), що додає випадковість в розташування бібліотек в межах адресного простору процесів, робить атаку даного типу надзвичайно складною і практично даремною на 64-бітних системах, тому що адреси функцій стають випадковими. Для систем з 32-бітною адресацією технологія ASLR менш корисна, оскільки для додавання випадковості доступно лише близько 16 біт, і з подібними випадками можна боротися за допомогою перебору грубою силою в рамках декількох хвилин.[1]

Як і з звичайними переповненнями буфера, дана атака значно ускладнена для архітектур, які не зберігають адресу повернення у тому ж стеку, що і дані. Такими архітектурами є, наприклад, SPARC[2], що зберігає адресу повернення з поточної функції у регістрі %i7, і MIPS (регістр $ra). Атака може бути неможливою для процесорів, що зберігають регістрові вікна попередніх функцій в тіньових регістрах, наприклад PowerPC, стек викликів в якому реалізований як регістр що стекується (зберігає старе значення в тіньовій зоні, недоступній програмісту).

Схожі атаки ред.

Техніка «Зворотно-орієнтоване програмування» є розвитком ідей, що лежать в основі цієї атаки, і дозволяє виконувати більш складні дії за рахунок послідовного об'єднання декількох менших атак, кожна з яких виконує невелику кількість інструкцій за раз. У цій техніці не обов'язково використовувати переходи на початок функцій, а допустимо робити «повернення» на інструкцію, що знаходиться недалеко від інструкції повернення управління з функції (ret). Після виконання одного фрагмента, команда ret візьме зі стека наступну адресу і запустить своїм поверненням інший фрагмент. Таким чином, за допомогою ретельного компонування стека можливо створення достатньо складних послідовностей інструкцій.

Див. також ред.

Примітки ред.

  1. Shacham, Hovav; Page, Matthew; Pfaff, Ben; Goh, Eu-Jin; Modadugu, Nagendra; and Boneh, Dan. On the Effectiveness of Address-Space Randomization (PDF). Proceedings of Computer and Communications Security (CCS'04), October 25–29, 2004, Washington (DC). Архів оригіналу (PDF) за 15 вересня 2011. Процитовано 19 квітня 2018.
  2. Hovav Shacham: When Good Instructions Go Bad. Архів оригіналу за 16 травня 2018. Процитовано 19 квітня 2018.

Посилання ред.