Защита стека
Защиту стека первым применил Криспин Коуэн в своей программе Stackguard, затем она была независимо реализована Microsoft с помощью флага компилятора /GS. В самом простом варианте суть ее состоит в том, что в стек между локальными переменными и адресом возврата записывается некое значение. В более современных реализациях для повышения эффективности может также изменяться порядок переменных. Достоинство этого подхода в том, что он легко реализуется и почти не снижает производительности, а кроме того, облегчает отладку в случае порчи стека. Другой примерэто программа ProPolice, созданная компанией IBM как расширение компилятора Gnu Compiler Collection (GCC). Любой современный продукт должен включать в себя защиту стека.
Запрет исполнения в стеке и куче
Эта контрмера существенно усложняет задачу хакера, но может сказаться на совместимости. Некоторые приложения считают допустимым компилировать и исполнять код на лету. Например, это относится к языкам Java и С#. Важно также отметить, что если противник сумеет заставить ваше приложение пасть жертвой атаки с возвратом в libc, когда для достижения неблаговидных целей выполняется вызов стандартной функции, то он сможет снять защиту со страницы памяти.
К сожалению, современная аппаратура по большей части не поддерживает эту возможность, а имеющаяся подержка зависит от процессора, операционной системы и даже ее конкретной версии. Поэтому рассчитывать на наличие такой защиты в реальных условиях не стоит, но все равно следует протестировать свою программу и убедиться, что она будет работать, когда стек и куча защищены от исполнения. Для этого нужно запустить ее на том процессоре и операционной системе, которые поддерживают аппаратную защиту. Например, если целевой платформой является Windows ХР, то прогоните тесты на машине с процессором AMD Athlon 64 FX под управлением Windows ХР SP2. В Windows эта технология называется Data Execution Protection (DEPзащита от исполнения данных), а раньше носила имя No eXecute (NX).
ОС Windows Server 2003 SP1 также поддерживает эту возможность, равно как подсистема РаХ для Linux и OpenBSD.
Другие ресурсы
Writing Secure Code, Second Edition by Michael Howard and David C. LeBlanc (Microsoft Press, 2002), Chapter 5, «Public Enemy #1: Buffer Overruns»
«Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows Server 2003» by David Litchfield: www.ngssoftware.com/papers/ defeatingw2k3stackprotection.pdf
«Nonstack Based Exploitation of Buffer Overrun Vulnerabilities on Windows NT/2000/ХР» by David Litchfield: www.ngssoftware.com/papers/nonstackbowindows.pdf
«Blind Exploitation of Stack Overflow Vulnerabilities» by Peter WinterSmith: www.ngssoftware.com/papers/NISR.BlindExploitation.pdf
«Creating Arbitrary Shellcode In Unicode Expanded Strings: The 'Venetian' Exploit» by Chris Anley: www.ngssoftware.com/papers/unicodebo.pdf
«Smashing The Stack For Fun And Profit» by Alephl (Elias Levy): www.insecure.org/stf/smashstack.txt
«The Tao of Windows Buffer Overflow» by Dildog: www.cultdeadcow.com/ cDc_files/cDc351/
Microsoft Security Bulletin MS04011/Security Update for Microsoft Windows (835732): www.microsoft.com/technet/security/Bulletin/MS04011 .mspx
Microsoft Application Compatibility Analyzer: www.microsoft.com/windows/ appcompatibility/analyzer.mspx
Using the Strsafe.h Functions: http://msdn.microsoft.com/library/enus/winui/ winui/windowsuserinterface/resources/strings/usingstrsafefunctions.asp
More Secure Buffer Function Calls: AUTOMATICALLY!: http://blogs.msdn.com/michael_howard /archive/2005/2/3.aspx
Repel Attacks on Your Code with the Visual Studio 2005 Safe С and С++ Libraries: http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCand С / default.aspx
«strlcpy and strlcatConsistent, 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 stacksmashing 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 Argamal) 23 июня 2000 года (www.securityfocus.com/archive/1/66842). Месяцем позже Паскаль Бушарен (Pascal Bouchareine) дал более развернутое пояснение (www.securityfocus.eom/archive/l/70552). В более раннем сообщении Марка Слемко (Mark Slemko) (www.securityfocus.com/archive/1 /10383) были описаны основные признаки ошибки, но о возможности записывать в память речи не было.