Про які ризики / вразливості безпеки повинен знати кожен програміст C? [зачинено]

Існує багато ризиків для безпеки, пов’язаних із тісним контактом з обладнанням, на відміну від використання добре перевірених та перевірених API з мов програмування високого рівня. Набагато простіше викликати переповнення буфера в C, ніж на такій мові, як Java.

Які ризики чи вразливості (наприклад, переповнення буфера), про які повинен знати кожен програміст C (вразливості IE, що стосуються програмістів на C)? До яких проблем це може призвести? Як їх уникнути, і які поширені помилки призводять до того, що вони виникають у програмах?

Переливи буфера - великі. Ніщо в C не перевірено діапазон за замовчуванням, тому дуже просто перезаписати буфер. Існує стандартна функція бібліотеки gets(), яку не можна зупинити від переповнення буфера, і її майже ніколи не можна використовувати.

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

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

Пов'язане питання - це проблема запису в буфер, занадто малий одним символом, забуваючи, що для рядка C, який має довгих n символів, потрібно n + 1 символів через '\0'термінатор. Якщо зловмиснику вдасться зберегти рядок без термінатора, будь-яка функція C, що очікує на рядок, буде продовжувати обробку, поки не потрапить на нульовий байт, що може призвести до копіювання або виведення більше інформації, ніж бажано (або потрапляння на захищену пам'ять для атаки DOS ). Знову ж таки, рішення - це огляд обізнаності, турботи та коду.

З printf()сім'єю є ще один ризик . Якщо ви коли-небудь пишете char * str; ... printf(str);, ви налаштовуєте себе на проблеми, якщо він strмістить "%" під час друку. %nДиректива формат дозволяє printf()записати в пам'ять. Рішенням є printf("%s", str);або puts(str);. (Також використовуйте C99 snprintf()замість sprintf().)

Використання непідписаних цілих чисел, зокрема в якості індексів циклу, може спричинити проблеми. Якщо призначити невелике негативне значення неподписаному, ви отримаєте велике додатне значення. Це може підірвати такі речі, як обробка лише N примірників чогось, або обмежених функцій на кшталт strncpy(). Вивчіть усі непідписані цілі числа. Ви можете уникнути unsigned short, оскільки велике значення одного з них перетвориться на велике позитивне значення у int.

Не забувайте, що константа символів у С насправді є int. Написати щось на кшталт char c; while((c = getchar()) != EOF) ...може легко не вдатися, оскільки EOFне буде представницьким в char.

Я можу придумати набагато більш характерні помилки C, але вони можуть спричинити проблеми із безпекою.

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

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

Розглянемо наступний код, який складе без проблем.

if(lpstr_current_state = CONST_EMERGENCY_STATE_HOLY_CRAP)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

Коли ви перевіряєте, чи lpstr_current_stateнемає, CONST_EMERGENCY_STATE_HOLY_CRAPви насправді призначаєте. Краще завжди ставити постійну змінну зліва. Якщо ви ставите константу зліва, компілятор не вдасться, оскільки ви не можете призначити значення змінній.

if(CONST_EMERGENCY_STATE_HOLY_CRAP = lpstr_current_state)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

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

if(CONST_EMERGENCY_STATE_HOLY_CRAP == lpstr_current_state)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

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

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

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