19 смертных грехов, угрожающих безопасности программ. Майкл Ховард

С / default.aspx

      □ «strlcpy and strlcat – Consistent, Safe, String Copy and Concatenation by Todd C. Miller and Theo de Raadt: www.usenix.org/events/usenix99/millert.html

      □ GCC extension for protecting applications from stack–smashing attacks: www.trl. ibm.com/projects/security/ssp/

      □ PaX: http://pax.grsecurity.net/

      □ OpenBSD Security: www.openbsd.org/security.html

      □ Static Source Code Analysis Tools for C: http://spinroot.com/static/

      Резюме

      Рекомендуется

      □ Тщательно проверяйте любой доступ к буферу за счет использования безопасных функций для работы со строками и областями памяти.

      □ Пользуйтесь встраиваемыми в компилятор средствами защиты, например флагом /GS и программой ProPolice.

      □ Применяйте механизмы защиты от переполнения буфера на уровне операционной системы, например DEP и РаХ.

      □ Уясните, какие данные контролирует противник, и обрабатывайте их безопасным образом.

      Не рекомендуется

      □ Не думайте, что компилятор и ОС все сделают за вас, это всего лишь дополнительные средства защиты.

      □ Не используйте небезопасные функции в новых программах.

      Стоит подумать

      □ Об установке последней версии компилятора C/C++, поскольку разработчики включают в генерируемый код новые механизмы защиты.

      □ О постепенном удалении небезопасных функций из старых программ.

      □ Об использовании строк и контейнерных классов из библиотеки С++ вместо применения низкоуровневых функций С для работы со строками.

      Грех 2.

      Ошибки, связанные с форматной строкой

      В чем состоит грех

      С форматной строкой связан новый класс атак, появившихся в последние годы. Одно из первых сообщений на эту тему прислал Ламагра Аграмал (Lamagra Arga–mal) 23 июня 2000 года (www.securityfocus.com/archive/1/66842). Месяцем позже Паскаль Бушарен (Pascal Bouchareine) дал более развернутое пояснение (www.securityfocus.eom/archive/l/70552). В более раннем сообщении Марка Слемко (Mark Slemko) (www.securityfocus.com/archive/1 /10383) были описаны основные признаки ошибки, но о возможности записывать в память речи не было.

      Как и в случае многих других проблем, относящихся к безопасности, суть ошибки в форматной строке заключается в отсутствии контроля данных, поступающих от пользователя. В программе на C/C++ такая ошибка позволяет произвести запись по произвольному адресу в памяти, а опаснее всего то, что при этом необязательно затрагиваются соседние блоки памяти. В результате противник может обойти защиту стека и модифицировать очень небольшие участки памяти. Проблема может возникнуть и тогда, когда форматная строка читается из не заслуживающего доверия источника, контролируемого противником, но это свойственно скорее системам UNIX и Linux. В Windows таблицы строк обычно хранятся внутри исполняемого файла или в динамически загружаемых библиотеках ресурсов (ресурсных DLL). Если противник может изменить основной исполняемый файл или ресурсную DLL, то он способен провести прямолинейную атаку, и не эксплуатируя ошибки в форматной строке.

      Но и в программах на других языках атаки на форматную строку могут стать источником серьезных неприятностей. Самая очевидная заключается в том, что пользователь не понимает, что происходит, однако при некоторых условиях противник может организовать атаку с кросс–сайтовым сценарием или внедрением SQL–команд, тем самым запортив или модифицировав данные.

      Подверженные греху языки

      Самыми опасными в этом отношении являются языки С и С++. Успешная атака приводит к исполнению произвольного кода и раскрытию информации. В программах на других языках произвольный код обычно выполнить не удается, но, как отмечено выше, возможны другие виды атак. С программой на Perl ничего не