Відмінності між версіями «Переповнення буфера»

Рядок 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-інструкцій можна спеціально згенеровані набори інших інструкцій(поліморфний код, самзмінний код, !!!Шелл-коды с шифрованием, самомодифицирующимся кодом, полиморфным кодом и алфавитно-цифровым кодом а также атаки возврата в стандартную библиотеку!!! )


Слід відмітити що перевірка розміру вхідних даних, що заноситься в стек, є більш ресурсозатратною ніж просте занесення даних, і інколи не потрібне здійснювати перевірку вхідних даних.