Відмінності між версіями «Переповнення буфера»
Рядок 33: | Рядок 33: | ||
Для GCC існують два розширення компілятора StackGuard і Stack-Smashing Protector які дозволяють виконати "розділення" стеку. Починаючи з gcc-4.1-stage2 система Stack-Smashing Protector є вбудованою в компілятор. | Для GCC існують два розширення компілятора StackGuard і Stack-Smashing Protector які дозволяють виконати "розділення" стеку. Починаючи з gcc-4.1-stage2 система Stack-Smashing Protector є вбудованою в компілятор. | ||
Недоліком такого методу є те що переповнення буферу стеку можна реалізувати в стеку з програмними даними, тобто дані програми залишаються незахищині. | Недоліком такого методу є те що переповнення буферу стеку можна реалізувати в стеку з програмними даними, тобто дані програми залишаються незахищині. | ||
+ | |||
+ | 4. Системи виявлення вторгнення | ||
+ | |||
+ | Системи виявлення вторгнення можуть запобігти переповненню буферу у стеку виявляючи довгі масиви інструкцій NOP. Ці інструкції вставляються в модифікуючі стрічки. При виявленні таких масивів система виявлення вторгнення автоматично їх блокує. | ||
+ | Зараз цей метод не є ефективним оскільки замість NOP-інструкцій можна спеціально згенеровані набори інших інструкцій(поліморфний код, самзмінний код, !!!Шелл-коды с шифрованием, самомодифицирующимся кодом, полиморфным кодом и алфавитно-цифровым кодом а также атаки возврата в стандартную библиотеку!!! ) | ||
Слід відмітити що перевірка розміру вхідних даних, що заноситься в стек, є більш ресурсозатратною ніж просте занесення даних, і інколи не потрібне здійснювати перевірку вхідних даних. | Слід відмітити що перевірка розміру вхідних даних, що заноситься в стек, є більш ресурсозатратною ніж просте занесення даних, і інколи не потрібне здійснювати перевірку вхідних даних. |
Версія за 11:35, 30 березня 2011
Змінити назву на Переповнення буферу у стеку.
Переповнення буфера у стеку (Buffer Overflow/Overrun) – це таке явище, коли програма, під час запису даних в буфер у стеку, перезаписує дані за його межами. Ця вразливість являється частинним випадком Переповнення буферу.
Причини вразливості
Причиною появи цієї вразливості є розміщення буферу у стеку процесу. Без належного контролю як програміста так і мови програмування за допомогою спеціальних маніпуляцій можна виконати цілеспрямовану зміну даних за межами буферу. Запис у стек здійснюється за принципом FIFO. Якщо не виконувати перевірку розміру вхідних даних, що заносяться в стек, можна перезаписати дані які перед тим знаходились у ньому. Це завжди приводить до втрати інформації, яка перезаписується. Ця вразливість поширена у програмах написаних на мові низького рівня - Assembler, та на мовах високого рівня С та С++, які не виконуються контролю розміру даних, що заносяться в буфер, а покладають відповідальність за виконання цих операцій на програміста. Цей тип вразливостей є одним із найстаріших і найефективніших методів злому програм.
Застосування переповнення буферу у стеку
Наведемо приклад практичної реалізації переповнення буферу у стеку на мові С++. Для цього розглянемо код програми що заносить до буферу дві змінні int intValue та char String[5]
Приклад реалізації////
Способи захисту
Є декілька способів захисту від цієї вразливості: 1. Застосування безпечних бібліотек
Високі мови програмування такі як C та С++ не виконуються контролю розміру даних, що заносяться в буфер. Для цього щоб уникнути даної вразливості необхідно використовувати спеціальні "безпечні" бібліотеки, які використовуються такі типи або класи що мають вбудовану перевірку довжини даних що заносяться в буфер.
2. Захист від пошкодження стеку
Цей тип захисту використовуються для виявлення пошкодження стеку. Після виконання функції перевіряється адреса повернення на зміни. Якщо зміни виявлена програма припиняє своє виконання з помилкою.
3. "Розділення" стеку
Стек містить як і дані програми так і системні дані(адреса повернення, значення вказівників ітд). Стек даних програмно розділяєтсья на 2 стеки, в одному розміщується тільки програмні дані, в другому службові дані. Це дозволить уникнути зміни адреси повернення і виконання довільного коду. Для GCC існують два розширення компілятора StackGuard і Stack-Smashing Protector які дозволяють виконати "розділення" стеку. Починаючи з gcc-4.1-stage2 система Stack-Smashing Protector є вбудованою в компілятор. Недоліком такого методу є те що переповнення буферу стеку можна реалізувати в стеку з програмними даними, тобто дані програми залишаються незахищині.
4. Системи виявлення вторгнення
Системи виявлення вторгнення можуть запобігти переповненню буферу у стеку виявляючи довгі масиви інструкцій NOP. Ці інструкції вставляються в модифікуючі стрічки. При виявленні таких масивів система виявлення вторгнення автоматично їх блокує. Зараз цей метод не є ефективним оскільки замість NOP-інструкцій можна спеціально згенеровані набори інших інструкцій(поліморфний код, самзмінний код, !!!Шелл-коды с шифрованием, самомодифицирующимся кодом, полиморфным кодом и алфавитно-цифровым кодом а также атаки возврата в стандартную библиотеку!!! )
Слід відмітити що перевірка розміру вхідних даних, що заноситься в стек, є більш ресурсозатратною ніж просте занесення даних, і інколи не потрібне здійснювати перевірку вхідних даних.