Помилки сегментації і безпека: специфіка foss

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

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

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

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

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




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






Таким чином, невелика помилка в невеликій програмі може представляти серйозну загрозу для безпеки всієї системи. Тому хотілося б порадити розробникам приділяти належну увагу роботі з пам`яттю в своїх продуктах.

Звичайно, можна просто використовувати мови програмування і відповідні середовища виконання з автоматичним управлінням пам`яттю - такі як Java або Python, проте повністю замінити традиційні C / C ++ вони поки не можуть.

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

Користувачам же я хочу порадити не бути пасивними і при виявленні помилок сегментації в додатках (або просто при «падінні» додатків в разі програм з графічним інтерфейсом) повідомляти про це їх авторам або розробникам використовуваного дистрибутива. Адже саме колективна робота над ПО є силою Open Source, і користувачі - такі ж учасники цього процесу, як і розробники.