Помилки сегментації і безпеку, або як «впала» програма може привести до злому системи

Відео: 1. Сегментація ринку. (Mark-IT 2015. Партнерський онлайн курс Storverk з маркетингу

Багато користувачів ОС Linux (і не тільки її), напевно, хоч раз в житті стикалися з «падінням» того чи іншого додатка. Сам факт аварійного завершення програми вже неприємний - адже він може призвести до втрати важливих даних, викликати необхідність заново повторювати вже виконану роботу і так далі.

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


Однією з основних причин аварійного завершення роботи програм ось уже кілька десятиліть є некоректна робота з пам`яттю, яка веде, як правило, до помилки сегментації (segmentation fault) - спробі звернення до неіснуючою адресою пам`яті.

Для розуміння причин виникнення таких проблем і виходять від них загроз для безпеки системи, необхідно розглянути організацію пам`яті будь-якого процесу в Linux на основних апаратних архітектурах.

Пам`ять будь-якої програми представляється як лінійний масив байтів. На початок цього масиву поміщається код програми, за ним слідують дані - глобальні змінні (як початкові, так і не мають початкового значення) і так звана «купа» ( «Heap»), з якої в процесі роботи програми виділяється пам`ять під динамічні змінні. Купа «росте» в бік збільшення адрес. Ближче до кінця масиву розташовується стек, який росте в сторону зменшення адрес (назустріч купі).

Розташування купи, стека і ряду інших об`єктів (наприклад, завантажених бібліотек, що) в пам`яті процесу можна побачити за допомогою файлової системи proofs. Вся ця інформація міститься в файлі / proc // Maps, де





- ідентифікатор процесу.

стек

Відео: Б, сегментація ринку і аватар клієнта 2

В стек записуються локальні змінні функцій і допоміжна інформація, яка використовується при їх виклик - зокрема адресаповернення і аргументи. Інформація, що відноситься до виклику однієї функції, формує так званий фрейм. Щоб визначити межі фреймів, в кожен новий фрейм поміщається покажчик на попередній.

Структура стека при виконанні функції

Відео: сегментація фінансового ринку

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

Якщо в області локальних змінних є змінна-буфер, в яку послідовно записуються деякий дані, то буфер буде «рости» знизу вгору. І якщо записати в цей буфер занадто багато інформації, то вона може затерти значення, розташовані в більш високих адресах.

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

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

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

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