3. Класифікація вразливостей захисту

Коли вимога коректної роботи програми на всіх можливих вхідних даних порушується, стає можливим поява так званих вразливостей захисту (security vulnerability). Уразливості захисту можуть приводити до того, що одна програма може використовуватися для подолання обмежень захисту всієї системи в цілому.

Класифікація вразливостей захисту в залежності від програмних помилок:

1. Переповнення буферу (buffer overflow). Ця вразливість виникає через відсутність контролю за виходом за межі масиву в пам'яті під час виконання програми. Коли занадто великий пакет даних переповнює буфер обмеженого розміру, вміст сторонніх елементів пам'яті перезаписується, і відбувається збій і аварійний вихід з програми. За місцем розташування буфера в пам'яті процесу розрізняють переповнення буферу в стеку (stack buffer overflow), кучі (heap buffer overflow) і області статичних даних (bss buffer overflow).

2. Уразливості <зіпсованого введення> (tainted input vulnerability). Уразливості <зіпсованого введення> можуть виникати у випадках, коли вводимі користувачем дані без достатнього контролю передаються інтерпретатору деякої зовнішньої мови (зазвичай це мова Unix shell або SQL). У цьому випадку користувач може таким чином задати вхідні дані, що запущений інтерпретатор виконає зовсім не ту команду, яка передбачалася авторами вразливої програми.

3. Помилки форматних рядків (format string vulnerability). Даний тип вразливостей захисту є підкласом уразливості <зіпсованого введення>. Він виникає через недостатній контроль параметрів при використанні функцій форматного введення-виведення printf, fprintf, scanf, і т. д. стандартної бібліотеки мови Сі. Ці функції приймають в якості одного з параметрів символьний рядок, який задає формат введення або виведення подальших аргументів функції. Якщо користувач сам може задати вид форматування, то ця вразливість може виникнути в результаті невдалого застосування функцій форматування рядків.

4. Уразливості як наслідок помилок синхронізації (race conditions). Проблеми, пов'язані з багатозадачністю, призводять до ситуацій, званих <стан гонки>: програма, не розрахована на виконання в багатозадачному середовищі, може вважати, що, наприклад, використовувані нею при роботі файли не може змінити інша програма. Як наслідок, зловмисник, який вчасно підміняє вміст цих робочих файлів, може нав'язати програмі виконання певних дій.

Звичайно, крім перерахованих існують і інші класи уразливостей захисту.

4. Огляд існуючих аналізаторів

Для виявлення вразливостей захисту в програмах застосовують такі інструментальні засоби:

• Динамічні відлагоджувачі. Інструменти, які дозволяють робити налагодження програми в процесі її виконання.

• Статичні аналізатори (статичні відлагоджувачі). Інструменти, які використовують інформацію, накопичену в ході статичного аналізу програми.

Статичні аналізатори вказують на ті місця в програмі, в яких можливе знаходиться помилка. Ці підозрілі фрагменти коду можуть, як містити помилку, так і виявитися абсолютно безпечними.

4.1. Статичний аналіз коду (англ. static code analysis) - аналіз програмного забезпечення, вироблений без реального виконання досліджуваних програм (аналіз, вироблений з виконанням програм називається динамічний аналіз коду). У більшості випадків аналіз проводиться над будь-якої версією вихідного коду, хоча іноді аналізу піддається будь-який вид об'єктного коду, наприклад P-код або код на MSIL. Термін зазвичай застосовують до аналізу, виробленому спеціальним ПО, тоді як ручний аналіз називають розумінням або осягненням програми.

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

Деякі люди вважають програмні метрики і зворотну розробку формами статичного аналізу.

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

Статичні аналізатори можуть бути як загального призначення (наприклад, Microsoft PREFast, Gimpel PC-Lint, Parasoft C + + Test), так і спеціалізованими для пошуку певних класів помилок (наприклад, Chord для верифікації паралельних Java програм). Зазвичай інструменти статичного аналізу досить дорогі, вимагають знань про методологію їх використання, мають достатньо складні підсистеми налаштування і придушення помилкових повідомлень. З цієї причини статичні аналізатори зазвичай використовуються в компаніях з високою культурою розробки і зрілими процесами розробки програмного забезпечення. В обмін на складність у використанні, статичні аналізатори коду дозволяють виявити велику кількість помилок на найбільш ранніх етапах розробки програмного коду. Використання методології статичного аналізу також дисциплінує програмістів і допомагає контролювати роботу молодих співробітників.

Основна перевага використання статичних аналізаторів коду полягає в можливості суттєвої зниженні вартості усунення дефектів в програмі. Чим раніше помилка виялена, тим менше вартість її виправлення. Так згідно з даними наведеними в книзі Макконнелла "Досконалий Код", виправлення помилки на етапі тестування обійдеться в десять разів дорожче, ніж на етапі конструювання (кодування):

Рис.17.2. Середня вартість виправлення дефектів в залежності від часу їх внесення і виявлення

(дані для таблиці взяті з книги С. Макконнелла "Досконалий Код").

Інструменти статичного аналізу дозволяють виявити велику кількість помилок етапу конструювання, що істотно знижує вартість розробки всього проекту.

Visual Studio. Починаючи з версії 2005 у компілятора cl.exe з'явився ключ / analyze, який включає додатковий аналіз і висновок попереджень про потенційні проблеми. На жаль, цей ключ є тільки у версії студії Team (в Professional його немає).

4.2. Динамічний аналіз коду (англ. Dynamic program analysis) - аналіз програмного забезпечення, виконуваний за допомогою виконання програм на реальному або віртуальному процесорі (аналіз, що виконується без запуску програм називається статичний аналіз коду). Утиліти динамічного аналізу можуть вимагати завантаження спеціальних бібліотек, перекомпіляцію програмного коду. Деякі утиліти можуть інструментувати виконуваний код в процесі виконання або перед ним. Для більшої ефективності динамічного аналізу потрібна подача тестованій програмі достатньої кількості вхідних даних, щоб отримати більш повне покриття коду. Також потрібно подбати про мінімізацію впливу інструментування на виконання програми, що тестується (включаючи тимчасові характеристики).

Виведення на основі фактів (Case-Based reasoning) є загальнопоширеною парадигмою в області автоматизації мислення та машинного навчання. Виведення на основі фактів складається з чотирьох основних етапів [1]. На першому етапі виконується аналіз бази відомих фактів (retrieve).

, (2)

де r -

Таблиця 1.