Помилки сегментації і безпеку: «канарки» в glibc і nx-біт

«Канарки» в glibc

В основних системних бібліотеках Linux є трохи інша схема реалізації засобів захисту від переповнення. У бібліотеках glibc для більшості функцій, виклик яких може привести до переповнення буфера, пропонуються альтернативні реалізації, використовують слова-канарки для перевірки цілісності стека.

Такі альтернативи мають суфікс «_chk» - printf_chk (), scanf_chk () і так далі. У програмістів немає потреби звертатися до цих функцій безпосередньо - їх виклик підставляється компілятором в код програми автоматично замість звичайних функцій, якщо визначена константа _FORTIFY_SOURCE і тільки якщо включена оптимізація. При спрацьовуванні цих «канарок», ми отримаємо таке повідомлення про переповнення буфера ( «*** buffer overflow detected ***»), а заодно і трасування виклику функцій і карту пам`яті процесу (фактично вміст уже згадуваного файлу / proc /

/ Maps).

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

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

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

NX-біт

Цей спосіб полягає у використанні NX-біта (No eXecutable bit) для сторінок пам`яті процесу, що не містять код. Цей підхід не передбачає безпосереднього виявлення факту переполненія- замість цього він намагається ускладнити використання подібних помилок для виконання шкідливого коду.

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

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

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

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

Реалізація NX-біта в апаратурі і додавання його підтримки в операційні системи стало серйозним кроком у зміцненні безпеки і напевно дозволило припинити безліч атак. Однак, як це нерідко буває, треба було зовсім небагато часу для створення елегантного способу обходу цього захисту.

Основною метою NX-біта є запобігання запуску будь-яких інструкцій з області даних, і з цим завданням він блискуче справляється. Однак так чи необхідна можливість запуску коду з області даних для успішної атаки? Виявляється, що зовсім немає. Адже переважна більшість додатків в Linux динамічно скомпоновані з бібліотекою libo, в якій є такі чудові функції, як system () і сімейство exec (), що дозволяють виконати будь-яку команду оболонки або запустити довільну програму.

До речі, якщо Ви хочете повністю убезпечити особисті даний користувачів, що користуються вашим онлайн сервісом? Тоді аутсорсингові послуги (https://itcloud.pro/outsorsing), що надаються справжніми професіоналами своєї справи, - це саме те, що Вам потрібно! Дізнайтеся подробиці прямо зараз на itcloud.pro.

Так що взагалі-то немає потреби створювати свої власні функції, поміщати їх в область даних, а потім передавати їм управління - досить передати управління однієї зі згаданих функцій libo, передавши їй потрібні параметри - наприклад, викликавши system ( «/ bin / bash») . Цьому NX-біт не заважає - адже функція system () знаходиться в області коду, і її запуск легітимний. Атака, що обходить NX-біт за допомогою виклику функцій бібліотеки libo, отримала назву «Return-Into-LibC».

Звичайно, залишаються завдання визначення адреси потрібної функції в області пам`яті процесу і формування потрібних аргументів, але вони не є нерозв`язними. Існують спеціальні прийоми, додатково ускладнюють ці завдання, такі як технологія рандомізації адресного простору процесу (Address Space Layout Randomization), при використанні якої бібліотеки при кожному старті програми розташовуються в її адресному просторі випадковим чином. Через це не можна заздалегідь дізнатися адресу тієї чи іншої бібліотечної функції, і атакуючому доводиться визначати адресу потрібної функції безпосередньо в ході роботи програми. Втім, це хоч і складно, але реально. До того ж для успішної атаки не обов`язково використовувати кожне переповнення буфера, досить одного вдалого «попадання». Так що NX-біт працює, але при великому бажанні обходиться.

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

Однак, крім технічних засобів, в світі відкритого ПЗ є ряд нетехнічних факторів, побічно що підвищують безпеку систем для кінцевих користувачів.

Наука і техніка