Моей потрясающей семье. Ничто не может сравниться с ощущением, которое испытываешь, когда приходишь домой и в ответ на вопрос «Кто дома, ребятки?» слышишь, как два голоска хором кричат: «Папа!»
– Майкл
Моему отцу, который объяснил мне, почему надо постоянно учиться и принимать новые вызовы.
– Дэвид
Маме. Она привила мне интеллектуальное любопытство и всегда была со мной рядом.
-Джон
Об авторах
Майкл Ховард работает старшим менеджером по безопасности программного обеспечения в группе по обеспечению безопасности в Microsoft Corp. Является соавтором удостоенной различных наград книги «Writing Secure Code» (Разработка безопасного кода). Он также совместно с коллегами ведет колонку «Basic Training» в журнале «ШЕЕ Security & Privacy Magazine» и является одним из авторов документа «Processes to Produce Secure Software» («Процессы в производстве безопасного программного обеспечения»), выпущенного организацией National Cyber Security Partnership для Министерства национальной безопасности (Department of Homeland Security). Будучи архитектором «Жизненного цикла разработки безопасного программного обеспечения» в Microsoft, Майкл посвящает большую часть времени выработке и внедрению передового опыта создания безопасных программ, которыми в конечном итоге будут пользоваться обычные люди.
Дэвид Лебланк, доктор философии, в настоящее время работает главным архитектором программ в компании Webroot Software. До этого он занимал должность архитектора подсистемы безопасности в подразделении Microsoft, занимающемся разработкой Microsoft Office, стоял у истоков инициативы Trustworthy Computing и работал «белым хакером» в группе безопасности сетей в Microsoft. Дэвид является соавтором книг «Writing Secure Code» и «Assessing Network Secu–rity» («Оценка безопасности сети»), а также многочисленных статей. В погожие дни он любит конные прогулки вместе со своей женой Дженнифер.
Джон Виега первым дал описание 19 серьезных просчетов при написании программ. Этот труд привлек внимание средств массовой информации и лег в основу настоящей книги. Джон является основателем и техническим директором компании Secure Software (www.securesoftware.com). Он один из авторов первой книги по безопасности программного обеспечения «Building Secure Software» («Создание безопасного программного обеспечения»), а также книг «Network Security and Cryptography with OpenSSL» («Безопасность и криптографические методы в сетях. Подход на основе библиотеки OpenSSL») и «Secure Programming СоокЬоок» («Рецепты для написания безопасных программ»). Он является основным автором процесса CLASP, призванного включить элементы безопасности в цикл разработки программ. Джон написал и сопровождает несколько относящихся к безопасности программ с открытыми исходными текстами. Раньше Джон занимал должности адъюнкт–профессора в техническом колледже штата Вирджиния и старшего научного сотрудника в Институте стратегии кибепространства (Cyberspace Policy Institute). Джон хорошо известен своими работами в области безопасности программ и криптографии, а в настоящее время он трудится над стандартами безопасности для сетей и программ.
О научных редакторах
Алан Крассовски работает главным инженером по безопасности программного обеспечения в компании Symantec Corporation. Он возглавляет группу по безопасности продуктов, в задачу которой входит оказание помощи другим группам разработчиков в плане внедрения безопасных технологий, которые сокращают риски и способствуют завоеванию доверия со стороны клиентов. За последние 20 лет Алан работал над многими коммерческими программными проектами. До присоединения к Symantec он руководил разработками, был инженером–программистом и оказывал консультативные услуги многим компаниям, занимающим лидирующее положение в отрасли, в частности Microsoft, IBM, Tektronix, Step Technologies. Screenplay Systems, Quark и Continental Insurance. Он получил научную степень бакалавра в области вычислительной техники в Рочестерском технологическом институте, штат Нью–Йорк.
Дэвид А. Уилер много лет занимается совершествованием практических методов разработки программ для систем с повышенным риском, в том числе особо крупных и нуждающихся в высокой степени безопасности. Он соавтор и соредактор книги «Software Inspection: An Industry Best Practice» («Инспекция программ: передовой опыт»), а также книг «Ada95: The Lovelace Tutorial» и «Secure Programming for Linux and UNIX HOWTO» («Рецепты безопасного программирования для Linux и UNIX»). Проживает в Северной Вирджинии.
Предисловие
В основе теории компьютеров лежит предположение о детерминированном поведении машин. Обычно мы ожидаем, что компьютер будет вести себя так, как мы его запрограммировали. На самом деле это лишь приближенное допущение. Современные компьютеры общего назначения и их программное обеспечение стали настолько сложными, что между щелчком по кнопке мыши и видимым результатом лежит множество программных слоев. И мы вынуждены полагаться на то, что все они работают правильно.
Любой слой программного обеспечения может содержать ошибки, из–за которых оно работает не так, как хотел автор, или, по крайней мере, не соответствует ожиданиям пользователя. Эти ошибки вносят в систему неопределенность, что может приводить к серьезным последствиям с точки зрения безопасности. Проявляться они могут по–разному: от простого краха системы, и тогда ошибку можно использовать, чтобы вызвать отказ от обслуживания, до переполнения буфера, позволяющего противнику выполнить в системе произвольный код.
Коль скоро поведение программных систем недетерминировано из–за ошибок, то самые лучшие идеи по их защите – не более чем гипотезы. Мы можем воздвигать межсетевые экраны, реализовывать технологии защиты от переполнения буфера на уровне ОС, применять самые разнообразные методики, но все это никоим образом не изменит фундаментальную парадигму безопасности. И лишь за счет радикального улучшения качества программ и сокращения числа ошибок мы можем надеяться на успешность попыток обеспечить безопасность программного обеспечения.
Устранение всех рисков, относящихся к безопасности, – нереальная задача при современном уровне развития систем разработки. У этой проблемы так много аспектов, что, даже для того чтобы просто оставаться в курсе дел, нужно посвящать этому все свое время. Что уж говорить о владении предметом в совершенстве!
Если мы хотим добиться прогресса в битве против ошибок, связанных с безопасностью, то должны облегчить процесс их идентификации и устранения организациям, занимающимся разработкой, и при этом учесть реальные ограничения. О безопасности программного обеспечения написано немало отличных книг, в том числе и авторами настоящего издания. Но я полагаю необходимым не углубляться в разного рода сложности, а предложить разработчикам небольшой набор критически важных советов, следуя которым они смогут повысить качество своих программ с минимальными усилиями. Идея в том, чтобы осветить наиболее типичные проблемы, которые нетрудно устранить, а не ставить нереалистичную задачу достижения полной безопасности.
В бытность начальником отдела в Министерстве национальной безопасности я попросил Джона Виегу составить перечень 19 «грехов» программиста. Первоначальный список был призван поставить корпоративный мир в известность о тех ошибках, которые чаще всего угрожают безопасности, но он не был составлен в форме рецептов. А эта книга именно такова. В ней приводится список проблем, от которых организации–разработчики должны защищаться в первую очередь, и даются рекомендации, как не допустить самого возникновения этих проблем. В книге также показано, как выявить подобные ошибки: посредством анализа кода или тестирования. Описание приемов и методик краткое и точное, авторы четко формулируют, что надо, а чего никогда не надо делать. Авторы проделали огромную работу, чтобы представить вашему вниманию список наиболее распространенных дефектов, от которых страдает безопасность современных программ. Надеюсь, что сообщество разработчиков оценит эту книгу и воспользуется ей для устранения недетерминизма и рисков, с которыми мы постоянно сталкиваемся.
Амит Йоран,
бывший начальник
отдела национальной кибербезопасности
Министерства национальной безопасности
Грейт Фоллс, Вирджиния,
21 мая 2005 г.
Благодарности
Эта книга – косвенный результат дальновидности Амита Йорана. Мы благодарны ему за то, что во время работы в Министерстве национальной безопасности (и позже) он делал все возможное, чтобы привлечь внимание к проблемам безопасности программного обеспечения. Мы также выражаем признательность следующим специалистам в области безопасности за усердие, с которым они рецензировали черновики отдельных глав, за их мудрость и за откровенные комментарии: Дэвиду Рафаэлю (David Raphael), Марку Кэрфи (Mark Curphy), Рудольфу Араю (Rudolph Arauj), Алану Крассовски (Alan Krassowski), Дэвиду Уилеру (David Wheeler) и Биллу Хильфу (Bill Hilf). Эта книга не состоялась бы без настойчивости сотрудников издательства McGraw–Hill. Большое спасибо трем «Дж»: Джейн Браунлоу (Jane Brownlow), Дженнифер Хауш (Jennifer Housh) и Джоди Маккензи Qody McKenzie).
Введение
В 2004 году Амит Йоран, тогда начальник отдела национальной кибербезопасности Министерства национальной безопасности США, объявил, что около 95% всех дефектов программ, относящихся к безопасности, проистекают из 19 типичных ошибок, природа которых вполне понятна. Мы не станем подвергать сомнению ваши интеллектуальные способности и объяснять важность безопасного программного обеспечения в современном взаимосвязанном мире, вы и так все понимаете, но приведем основные принципы поиска и исправления наиболее распространенных ошибок в вашем собственном коде.
Неприятная особенность ошибок, касающихся безопасности, состоит в том, что допустить их очень легко, а результаты одной неправильно написанной строчки могут быть поистине катастрофическими. Червь Blaster смог распространиться из–за ошибки всего в двух строках кода.
Если попытаться выразить весь накопленный опыт одной фразой, то, наверное, она звучала бы так: «Никакой язык программирования, никакая платформа не способны сделать программу безопасной, это можете сделать только вы». Существует масса литературы о том, как создавать безопасное программное обеспечение, да и авторы настоящей книги написали на эту тему немало текстов, к которым прислушиваются. И все же есть потребность в небольшой, простой и прагматической книге, в которой рассматривались бы все основные проблемы.
Работая над этой книгой, мы старались придерживаться следующих правил, которые не позволили бы оторваться от земли.
□ Простота. Мы не тратили место на пустую болтовню. Здесь вы не найдете ни репортажей с поля боя, ни забавных анекдотов – только голые факты. Скорее всего, вы просто хотите сделать свою работу качественно и в кратчайшие сроки. Поэтому мы стремились к тому, чтобы найти нужную информацию можно было просто и быстро.
□ Краткость. Это следствие предыдущего правила: сосредоточившись исключительно на фактах, мы смогли сделать книгу небольшой по объему. Это введение тоже не будет многословным.
□ Кроссплатформенность. Интернет – это среда, связывающая между собой мириады вычислительных устройств, работающих под управлением разных операционных систем и программ, написанных на разных языках. Мы хотели, чтобы эта книга была полезна всем разработчикам, поэтому представленные примеры относятся к большинству имеющихся операционных систем.
□ Многоязычие. Следствие предыдущего правила: мы приводим примеры ошибок в программах, которые составлены на разных языках.
Структура книги
В каждой главе описывается один «смертный грех». Вообще–то они никак не упорядочены, но самые гнусные мы разместили в начале книги. Главы разбиты на разделы:
□ «В чем состоит грех» – краткое введение, в котором объясняется, почему данное деяние считается грехом;
□ «Как происходит грехопадение» – описывается суть проблемы; принципиальная ошибка, которая доводит до греха;
□ «Подверженные греху языки» – перечень языков, подверженных данному греху;
□ «Примеры ошибочного кода» – конкретные примеры ошибок в программах, написанных на разных языках и работающих на разных платформах;
□ «Где искать ошибку» – на что нужно прежде всего обращать внимание при поиске в программе подобных ошибок;
□ «Выявление ошибки на этапе анализа кода» тут все понятно: как найти грехи в своем коде. Мы понимаем, что разработчики – люди занятые, поэтому старались писать этот раздел коротко и по делу;
□ «Тестирование» – описываются инструменты и методики тестирования, которые позволят обнаружить признаки рассматриваемого греха;
□ «Примеры из реальной жизни» – реальные примеры данного греха, взятые из базы данных типичных уязвимостей и брешей (Common Vulnerabilities and Exposures – CVE) (www.cve.mitre.org). с сайта BugTraq (www.securityfocus.com) или базы данных уязвимостей в программах с открытыми исходными текстами (Open Source Vulnerability Database) (www.osvdb.org). В каждом случае мы приводим свои комментарии. Примечание: пока мы работали над этой книгой, рассматривался вопрос об отказе с 15 октября 2005 года от номеров CAN в базе данных CVE и переходе исключительно на номера CVE. Если это случится, то все ссылки на номер ошибки «CAN…» следует заменить ссылкой на соответствующий номер CVE. Например, если вы не сможете найти статью CAN–2004–0029 (ошибка Lotus Notes для Linux), попробуйте поискать CVE–2004–0029;
□ «Искупление греха» – как исправить ошибку, чтобы избавиться от греха. И в этом случае мы демонстрируем варианты для разных языков;
□ «Дополнительные защитные меры» – другие меры, которые можно предпринять. Они не исправляют ошибку, но мешают противнику воспользоваться потенциальным дефектом, если вы ее все–таки допустите;
□ «Другие ресурсы» – это небольшая книжка, поэтому мы даем ссылки на другие источники информации: главы книг, статьи и сайты;
□ «Резюме» – это неотъемлемая часть главы, предполагается, что вы будете к ней часто обращаться. Здесь приводятся списки рекомендуемых, нерекомендуемых и возможных действий при написании нового или анализе существующего кода. Не следует недооценивать важность этого раздела! Содержание всех Резюме сведено воедино в Приложении В.
Кому предназначена эта книга
Эта книга адресована всем разработчикам программного обеспечения. В ней описаны наиболее распространенные ошибки, приводящие к печальным последствиям, а равно способы их устранения до того, как программа будет передана заказчику. Вы найдете здесь полезный материал вне зависимости от того, на каком языке пишете, будь то С, С++, Java, С#, ASP, ASP.NET, Visual Basic, PHP, Perl или JSP. Она применима к операционным системам Windows, Linux, Apple Mac OS X, OpenBSD и Solaris, а равно к самым разнообразным платформам: «толстым» клиентам, «тонким» клиентам или пользователям Web. Честно говоря, безопасность не зависит ни от языка, ни от операционной системы, ни от платформы. Если ваш код небезопасен, то пользователи беззащитны перед атакой.
Какие главы следует прочитать
Это небольшая книжка, поэтому не ленитесь. Прочтите ее целиком, ведь никогда не знаешь, над чем предстоит работать в будущем.
Но все же есть грехи, которым подвержены лишь некоторые языки и некоторые среды, поэтому важно, чтобы в первую очередь вы прочли о тех, что специфичны именно для вашего языка программирования, вашей ОС и вашей среды исполнения (Web и т. п.).
Вот минимум, с которым надо ознакомиться при различных предположениях о специфике вашей работы.
□ Всем рекомендуется ознакомиться с грехами 6, 12 и 13.
□ Если вы программируете наязыках C/C++, то обязаны прочесть о грехах 1, 2 и З.
□ Если вы программируете для Web с использованием таких технологий, как JSP, ASP, ASP.NET, PHP, CGI или Perl, то познакомьтесь с грехами 7 и 9.
□ Если вы создаете приложения для работы с базами данных, например Oracle, MySQL, DB2 или SQL Server, прочтите о грехе 4.
□ Если вы разрабатываете сетевые системы (клиент–серверные, через Web и прочие), не проходите мимо грехов 5, 8, 10, 14 и 15.
□ Если в вашем приложении каким–то образом используется криптография или пароли, обратите внимание на грехи 8, 10, 11, 17 и 18.
□ Если ваша программа работает в ОС Linux, Mac OS X или UNIX, следует прочесть о грехе 16.
□ Если с вашим приложением будут работать неопытные пользователи, взгляните на описание греха 19.
Мы полагаем, что эта книга важна, поскольку в работе над ней приняли участие трое наиболее авторитетных на сегодняшний день специалистов–практиков в сфере безопасности, а также потому, что она охватывает все распространенные языки и платформы для развертывания программ. Надеемся, что вы найдете здесь немало полезной информации.
Майкл Ховард, Дэвид Лебланк, Джон Виега, июль 2005 г.
Грех 1.
Переполнение буфера
В чем состоит грех
Уже давно ясно, что переполнение буфера – это проблема всех низкоуровневых языков программирования. Возникает она потому, что в целях эффективности данные и информация о потоке выполнения программы перемешаны, а в низкоуровневом языке разрешен прямой доступ к памяти. С и С++ больше других языков страдают от переполнений буфера.
Строго говоря, переполнение возникает, когда программа пытается писать в память, не принадлежащую выделенному буферу, но есть и ряд других ошибок, приводящих к тому же эффекту. Одна из наиболее интересных связана с форматной строкой, мы рассмотрим ее в описании греха 2. Еще одно проявление той же проблемы встречается, когда противнику разрешено писать в произвольную область памяти за пределами некоторого массива. И хотя формально это не есть классическое переполнение буфера, мы рассмотрим здесь и этот случай.
Результатом переполнения буфера может стать что угодно – от краха программы до получения противником полного контроля над приложением, а если приложение запущено от имени пользователя с высоким уровнем доступа (root, Administrator или System), то и над всей операционной системой и другими пользователями. Если рассматриваемое приложение – это сетевая служба, то ошибка может привести к распространению червя. Первый получивший широкую известность Интернет–червь эксплуатировал ошибку в сервере finger, он так и назывался – «finger–червь Роберта Т. Морриса» (или просто «червь Морриса»). Казалось бы, что после того как в 1988 году Интернет был поставлен на колени, мы уже должны научиться избегать переполнения буфера, но и сейчас нередко появляются сообщения о такого рода ошибках в самых разных программах.
Быть может, кто–то думает, что такие ошибки свойственны лишь небрежным и беззаботным программистам. Однако на самом деле эта проблема сложна, решения не всегда тривиальны, и всякий, кто достаточно часто программировал на С или С++, почти наверняка хоть раз да допускал нечто подобное. Автор этой главы, который учит других разработчиков, как писать безопасный код, сам однажды передал заказчику программу, в которой было переполнение на одну позицию (off–by–one overflow). Даже самые лучшие, самые внимательные программисты допускают ошибки, но при этом они знают, насколько важно тщательно тестировать программу, чтобы эти ошибки не остались незамеченными.
Подверженные греху языки
Чаще всего переполнение буфера встречается в программах, написанных на С, недалеко от него отстает и С++. Совсем просто переполнить буфер в ассемблерной программе, поскольку тут нет вообще никаких предохранительных механизмов. По существу, С++ так же небезопасен, как и С, поскольку основан на этом языке. Но использование стандартной библиотеки шаблонов STL позволяет свести риск некорректной работы со строками к минимуму, а более строгий компилятор С++ помогает программисту избегать некоторых ошибок. Даже если ваша программа составлена на чистом С, мы все же рекомендуем использовать компилятор С++, чтобы выловить как можно больше ошибок.
В языках более высокого уровня, появившихся позже, программист уже не имеет прямого доступа к памяти, хотя за это и приходится расплачиваться производительностью. В такие языки, как Java, С# и Visual Basic, уже встроены строковый тип, массивы с контролем выхода за границы и запрет на прямой доступ к памяти (в стандартном режиме). Кто–то может сказать, что в таких языках переполнение буфера невозможно, но правильнее было бы считать, что оно лишь гораздо менее вероятно. Ведь в большинстве своем эти языки реализованы на С или С++, а ошибка в реализации может стать причиной переполнения буфера. Еще один потенциальный источник проблемы заключается в том, что на какой–то стадии все эти высокоуровневые языки должны обращаться к операционной системе, а уж она–то почти наверняка написана на С или С++. Язык С# позволяет обойти стандартные механизмы .NET, объявив небезопасный участок с помощью ключевого слова unsafe. Да, это упрощает взаимодействие с операционной системой и библиотеками, написанными на C/C++, но одновременно открывает возможность допустить обычные для C/C++ ошибки. Даже если вы программируете преимущественно на языках высокого уровня, не отказывайтесь от тщательного контроля данных, передаваемых внешним библиотекам, если не хотите пасть жертвой содержащихся в них ошибок.
Мы не станем приводить исчерпывающий список языков, подверженных ошибкам из–за переполнения буфера, скажем лишь, что к их числу относится большинство старых языков.
Майкл Ховард, Дэвид Лебланк, Джон Виега
19 смертных грехов, угрожающих безопасности программ. Как не допустить типичных ошибок
Моей потрясающей семье. Ничто не может сравниться с ощущением, которое испытываешь, когда приходишь домой и в ответ на вопрос «Кто дома, ребятки?» слышишь, как два голоска хором кричат: «Папа!»
– Майкл
Моему отцу, который объяснил мне, почему надо постоянно учиться и принимать новые вызовы.
– Дэвид
Маме. Она привила мне интеллектуальное любопытство и всегда была со мной рядом.
-Джон
Об авторах
Майкл Ховард работает старшим менеджером по безопасности программного обеспечения в группе по обеспечению безопасности в Microsoft Corp. Является соавтором удостоенной различных наград книги «Writing Secure Code» (Разработка безопасного кода). Он также совместно с коллегами ведет колонку «Basic Training» в журнале «ШЕЕ Security & Privacy Magazine» и является одним из авторов документа «Processes to Produce Secure Software» («Процессы в производстве безопасного программного обеспечения»), выпущенного организацией National Cyber Security Partnership для Министерства национальной безопасности (Department of Homeland Security). Будучи архитектором «Жизненного цикла разработки безопасного программного обеспечения» в Microsoft, Майкл посвящает большую часть времени выработке и внедрению передового опыта создания безопасных программ, которыми в конечном итоге будут пользоваться обычные люди.
Дэвид Лебланк, доктор философии, в настоящее время работает главным архитектором программ в компании Webroot Software. До этого он занимал должность архитектора подсистемы безопасности в подразделении Microsoft, занимающемся разработкой Microsoft Office, стоял у истоков инициативы Trustworthy Computing и работал «белым хакером» в группе безопасности сетей в Microsoft. Дэвид является соавтором книг «Writing Secure Code» и «Assessing Network Secu–rity» («Оценка безопасности сети»), а также многочисленных статей. В погожие дни он любит конные прогулки вместе со своей женой Дженнифер.
Джон Виега первым дал описание 19 серьезных просчетов при написании программ. Этот труд привлек внимание средств массовой информации и лег в основу настоящей книги. Джон является основателем и техническим директором компании Secure Software (www.securesoftware.com). Он один из авторов первой книги по безопасности программного обеспечения «Building Secure Software» («Создание безопасного программного обеспечения»), а также книг «Network Security and Cryptography with OpenSSL» («Безопасность и криптографические методы в сетях. Подход на основе библиотеки OpenSSL») и «Secure Programming СоокЬоок» («Рецепты для написания безопасных программ»). Он является основным автором процесса CLASP, призванного включить элементы безопасности в цикл разработки программ. Джон написал и сопровождает несколько относящихся к безопасности программ с открытыми исходными текстами. Раньше Джон занимал должности адъюнкт–профессора в техническом колледже штата Вирджиния и старшего научного сотрудника в Институте стратегии кибепространства (Cyberspace Policy Institute). Джон хорошо известен своими работами в области безопасности программ и криптографии, а в настоящее время он трудится над стандартами безопасности для сетей и программ.
О научных редакторах
Алан Крассовски работает главным инженером по безопасности программного обеспечения в компании Symantec Corporation. Он возглавляет группу по безопасности продуктов, в задачу которой входит оказание помощи другим группам разработчиков в плане внедрения безопасных технологий, которые сокращают риски и способствуют завоеванию доверия со стороны клиентов. За последние 20 лет Алан работал над многими коммерческими программными проектами. До присоединения к Symantec он руководил разработками, был инженером–программистом и оказывал консультативные услуги многим компаниям, занимающим лидирующее положение в отрасли, в частности Microsoft, IBM, Tektronix, Step Technologies. Screenplay Systems, Quark и Continental Insurance. Он получил научную степень бакалавра в области вычислительной техники в Рочестерском технологическом институте, штат Нью–Йорк.
Дэвид А. Уилер много лет занимается совершествованием практических методов разработки программ для систем с повышенным риском, в том числе особо крупных и нуждающихся в высокой степени безопасности. Он соавтор и соредактор книги «Software Inspection: An Industry Best Practice» («Инспекция программ: передовой опыт»), а также книг «Ada95: The Lovelace Tutorial» и «Secure Programming for Linux and UNIX HOWTO» («Рецепты безопасного программирования для Linux и UNIX»). Проживает в Северной Вирджинии.
Предисловие
В основе теории компьютеров лежит предположение о детерминированном поведении машин. Обычно мы ожидаем, что компьютер будет вести себя так, как мы его запрограммировали. На самом деле это лишь приближенное допущение. Современные компьютеры общего назначения и их программное обеспечение стали настолько сложными, что между щелчком по кнопке мыши и видимым результатом лежит множество программных слоев. И мы вынуждены полагаться на то, что все они работают правильно.
Любой слой программного обеспечения может содержать ошибки, из–за которых оно работает не так, как хотел автор, или, по крайней мере, не соответствует ожиданиям пользователя. Эти ошибки вносят в систему неопределенность, что может приводить к серьезным последствиям с точки зрения безопасности. Проявляться они могут по–разному: от простого краха системы, и тогда ошибку можно использовать, чтобы вызвать отказ от обслуживания, до переполнения буфера, позволяющего противнику выполнить в системе произвольный код.
Коль скоро поведение программных систем недетерминировано из–за ошибок, то самые лучшие идеи по их защите – не более чем гипотезы. Мы можем воздвигать межсетевые экраны, реализовывать технологии защиты от переполнения буфера на уровне ОС, применять самые разнообразные методики, но все это никоим образом не изменит фундаментальную парадигму безопасности. И лишь за счет радикального улучшения качества программ и сокращения числа ошибок мы можем надеяться на успешность попыток обеспечить безопасность программного обеспечения.
Устранение всех рисков, относящихся к безопасности, – нереальная задача при современном уровне развития систем разработки. У этой проблемы так много аспектов, что, даже для того чтобы просто оставаться в курсе дел, нужно посвящать этому все свое время. Что уж говорить о владении предметом в совершенстве!
Если мы хотим добиться прогресса в битве против ошибок, связанных с безопасностью, то должны облегчить процесс их идентификации и устранения организациям, занимающимся разработкой, и при этом учесть реальные ограничения. О безопасности программного обеспечения написано немало отличных книг, в том числе и авторами настоящего издания. Но я полагаю необходимым не углубляться в разного рода сложности, а предложить разработчикам небольшой набор критически важных советов, следуя которым они смогут повысить качество своих программ с минимальными усилиями. Идея в том, чтобы осветить наиболее типичные проблемы, которые нетрудно устранить, а не ставить нереалистичную задачу достижения полной безопасности.
В бытность начальником отдела в Министерстве национальной безопасности я попросил Джона Виегу составить перечень 19 «грехов» программиста. Первоначальный список был призван поставить корпоративный мир в известность о тех ошибках, которые чаще всего угрожают безопасности, но он не был составлен в форме рецептов. А эта книга именно такова. В ней приводится список проблем, от которых организации–разработчики должны защищаться в первую очередь, и даются рекомендации, как не допустить самого возникновения этих проблем. В книге также показано, как выявить подобные ошибки: посредством анализа кода или тестирования. Описание приемов и методик краткое и точное, авторы четко формулируют, что надо, а чего никогда не надо делать. Авторы проделали огромную работу, чтобы представить вашему вниманию список наиболее распространенных дефектов, от которых страдает безопасность современных программ. Надеюсь, что сообщество разработчиков оценит эту книгу и воспользуется ей для устранения недетерминизма и рисков, с которыми мы постоянно сталкиваемся.
Амит Йоран,
бывший начальник
отдела национальной кибербезопасности
Министерства национальной безопасности
Грейт Фоллс, Вирджиния,
21 мая 2005 г.
Благодарности
Эта книга – косвенный результат дальновидности Амита Йорана. Мы благодарны ему за то, что во время работы в Министерстве национальной безопасности (и позже) он делал все возможное, чтобы привлечь внимание к проблемам безопасности программного обеспечения. Мы также выражаем признательность следующим специалистам в области безопасности за усердие, с которым они рецензировали черновики отдельных глав, за их мудрость и за откровенные комментарии: Дэвиду Рафаэлю (David Raphael), Марку Кэрфи (Mark Curphy), Рудольфу Араю (Rudolph Arauj), Алану Крассовски (Alan Krassowski), Дэвиду Уилеру (David Wheeler) и Биллу Хильфу (Bill Hilf). Эта книга не состоялась бы без настойчивости сотрудников издательства McGraw–Hill. Большое спасибо трем «Дж»: Джейн Браунлоу (Jane Brownlow), Дженнифер Хауш (Jennifer Housh) и Джоди Маккензи Qody McKenzie).
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
Майкл Ховард, Дэвид Лебланк, Джон Виега19 смертных грехов, угрожающих безопасности программ. Как не допустить типичных ошибок
Моей потрясающей семье. Ничто не может сравниться с ощущением, которое испытываешь, когда приходишь домой и в ответ на вопрос «Кто дома, ребятки?» слышишь, как два голоска хором кричат: «Папа!»
Майкл
Моему отцу, который объяснил мне, почему надо постоянно учиться и принимать новые вызовы.
Дэвид
Маме. Она привила мне интеллектуальное любопытство и всегда была со мной рядом.
-Джон
Об авторах
Майкл Ховард работает старшим менеджером по безопасности программного обеспечения в группе по обеспечению безопасности в Microsoft Corp. Является соавтором удостоенной различных наград книги «Writing Secure Code» (Разработка безопасного кода). Он также совместно с коллегами ведет колонку «Basic Training» в журнале «ШЕЕ Security & Privacy Magazine» и является одним из авторов документа «Processes to Produce Secure Software» («Процессы в производстве безопасного программного обеспечения»), выпущенного организацией National Cyber Security Partnership для Министерства национальной безопасности (Department of Homeland Security). Будучи архитектором «Жизненного цикла разработки безопасного программного обеспечения» в Microsoft, Майкл посвящает большую часть времени выработке и внедрению передового опыта создания безопасных программ, которыми в конечном итоге будут пользоваться обычные люди.
Дэвид Лебланк, доктор философии, в настоящее время работает главным архитектором программ в компании Webroot Software. До этого он занимал должность архитектора подсистемы безопасности в подразделении Microsoft, занимающемся разработкой Microsoft Office, стоял у истоков инициативы Trustworthy Computing и работал «белым хакером» в группе безопасности сетей в Microsoft. Дэвид является соавтором книг «Writing Secure Code» и «Assessing Network Security» («Оценка безопасности сети»), а также многочисленных статей. В погожие дни он любит конные прогулки вместе со своей женой Дженнифер.
Джон Виега первым дал описание 19 серьезных просчетов при написании программ. Этот труд привлек внимание средств массовой информации и лег в основу настоящей книги. Джон является основателем и техническим директором компании Secure Software (www.securesoftware.com). Он один из авторов первой книги по безопасности программного обеспечения «Building Secure Software» («Создание безопасного программного обеспечения»), а также книг «Network Security and Cryptography with OpenSSL» («Безопасность и криптографические методы в сетях. Подход на основе библиотеки OpenSSL») и «Secure Programming СоокЬоок» («Рецепты для написания безопасных программ»). Он является основным автором процесса CLASP, призванного включить элементы безопасности в цикл разработки программ. Джон написал и сопровождает несколько относящихся к безопасности программ с открытыми исходными текстами. Раньше Джон занимал должности адъюнктпрофессора в техническом колледже штата Вирджиния и старшего научного сотрудника в Институте стратегии кибепространства (Cyberspace Policy Institute). Джон хорошо известен своими работами в области безопасности программ и криптографии, а в настоящее время он трудится над стандартами безопасности для сетей и программ.
О научных редакторах
Алан Крассовски работает главным инженером по безопасности программного обеспечения в компании Symantec Corporation. Он возглавляет группу по безопасности продуктов, в задачу которой входит оказание помощи другим группам разработчиков в плане внедрения безопасных технологий, которые сокращают риски и способствуют завоеванию доверия со стороны клиентов. За последние 20 лет Алан работал над многими коммерческими программными проектами. До присоединения к Symantec он руководил разработками, был инженеромпрограммистом и оказывал консультативные услуги многим компаниям, занимающим лидирующее положение в отрасли, в частности Microsoft, IBM, Tektronix, Step Technologies. Screenplay Systems, Quark и Continental Insurance. Он получил научную степень бакалавра в области вычислительной техники в Рочестерском технологическом институте, штат НьюЙорк.
Дэвид А. Уилер много лет занимается совершествованием практических методов разработки программ для систем с повышенным риском, в том числе особо крупных и нуждающихся в высокой степени безопасности. Он соавтор и соредактор книги «Software Inspection: An Industry Best Practice» («Инспекция программ: передовой опыт»), а также книг «Ada95: The Lovelace Tutorial» и «Secure Programming for Linux and UNIX HOWTO» («Рецепты безопасного программирования для Linux и UNIX»). Проживает в Северной Вирджинии.
Предисловие
В основе теории компьютеров лежит предположение о детерминированном поведении машин. Обычно мы ожидаем, что компьютер будет вести себя так, как мы его запрограммировали. На самом деле это лишь приближенное допущение. Современные компьютеры общего назначения и их программное обеспечение стали настолько сложными, что между щелчком по кнопке мыши и видимым результатом лежит множество программных слоев. И мы вынуждены полагаться на то, что все они работают правильно.
Любой слой программного обеспечения может содержать ошибки, изза которых оно работает не так, как хотел автор, или, по крайней мере, не соответствует ожиданиям пользователя. Эти ошибки вносят в систему неопределенность, что может приводить к серьезным последствиям с точки зрения безопасности. Проявляться они могут поразному: от простого краха системы, и тогда ошибку можно использовать, чтобы вызвать отказ от обслуживания, до переполнения буфера, позволяющего противнику выполнить в системе произвольный код.
Коль скоро поведение программных систем недетерминировано изза ошибок, то самые лучшие идеи по их защитене более чем гипотезы. Мы можем воздвигать межсетевые экраны, реализовывать технологии защиты от переполнения буфера на уровне ОС, применять самые разнообразные методики, но все это никоим образом не изменит фундаментальную парадигму безопасности. И лишь за счет радикального улучшения качества программ и сокращения числа ошибок мы можем надеяться на успешность попыток обеспечить безопасность программного обеспечения.
Устранение всех рисков, относящихся к безопасности, нереальная задача при современном уровне развития систем разработки. У этой проблемы так много аспектов, что, даже для того чтобы просто оставаться в курсе дел, нужно посвящать этому все свое время. Что уж говорить о владении предметом в совершенстве!
Если мы хотим добиться прогресса в битве против ошибок, связанных с безопасностью, то должны облегчить процесс их идентификации и устранения организациям, занимающимся разработкой, и при этом учесть реальные ограничения. О безопасности программного обеспечения написано немало отличных книг, в том числе и авторами настоящего издания. Но я полагаю необходимым не углубляться в разного рода сложности, а предложить разработчикам небольшой набор критически важных советов, следуя которым они смогут повысить качество своих программ с минимальными усилиями. Идея в том, чтобы осветить наиболее типичные проблемы, которые нетрудно устранить, а не ставить нереалистичную задачу достижения полной безопасности.
В бытность начальником отдела в Министерстве национальной безопасности я попросил Джона Виегу составить перечень 19 «грехов» программиста. Первоначальный список был призван поставить корпоративный мир в известность о тех ошибках, которые чаще всего угрожают безопасности, но он не был составлен в форме рецептов. А эта книга именно такова. В ней приводится список проблем, от которых организацииразработчики должны защищаться в первую очередь, и даются рекомендации, как не допустить самого возникновения этих проблем. В книге также показано, как выявить подобные ошибки: посредством анализа кода или тестирования. Описание приемов и методик краткое и точное, авторы четко формулируют, что надо, а чего никогда не надо делать. Авторы проделали огромную работу, чтобы представить вашему вниманию список наиболее распространенных дефектов, от которых страдает безопасность современных программ. Надеюсь, что сообщество разработчиков оценит эту книгу и воспользуется ей для устранения недетерминизма и рисков, с которыми мы постоянно сталкиваемся.
Амит Йоран,
Эта книга необходима всем разработчикам программного обеспечения, независимо от платформы, языка или вида приложений. В ней рассмотрены 19 грехов, угрожащих безопасности программ, и показано как от них избавиться. Рассмотрены уязвимости на языках C/C++, C#, Java, Visual Basic, Visual Basic .NET, Perl, Python в операционных системах Windows, Unix, Linux, Mac OS, Novell Netware. Авторы издания, Майкл Ховард и Дэвид Лебланк, обучают программистов как писать безопасный код в компании Microsoft. На различных примерах продемонстрированы как сами ошибки, так и способы их исправления и защиты от них. Если вы — программист, то вам просто необходимо прочесть эту книгу.
Фрагмент текстового слоя документа размещен для индексирующих роботов.
Для полноценной работы с документом, пожалуйста, перейдите в
ридер.
Майкл Ховард, Дэвид Лебланк, Джон Виега 19 смертных грехов, угрожающих безопасности программ Как не допустить типичных ошибок Предисловие Амита Йорана
DEADLY SINS OF SOFTWARE SECURITY Programming Flaws and How to Fix Them MICHAEL HOWARD DAVID LEBLANC JOHN VIEGA McGrawHill/Osborne New York Chicago San Francisco Lisbon London Madrid Mexico City Milan New Delhi San Juan Seoul Singapore Sydney Toronto
СМЕРТНЫХ ГРЕХОВ, УГРОЖАЮЩИХ БЕЗОПАСНОСТИ ПРОГРАММ Как не допустить типичных ошибок Москва МАЙКЛ ХОВАРД ДЭВИД ЛЕБЛАНК ДЖОН ВИЕГА
УДК 004.4 ББК 32.973.26018.2 М97 Ховард М., Лебланк Д., Виега Д. Х68 19 смертных грехов, угрожающих безопасности программ. Как не допустить типичных ошибок . – М.: ДМК Пресс. – 288 с.: ил. ISBN 597060027Х Эта книга необходима всем разработчикам программного обеспечения, независимо от платформы, языка или вида приложений. В ней рассмотрены 19 грехов, угрожащих безопасности программ, и показано как от них избавиться. Рассмотрены уязвимости на языках C/C++, C#, Java, Visual Basic, Visual Basic .NET, Perl, Python в операционных системах Windows, Unix, Linux, Mac OS, Novell Netware. Авторы издания, Майкл Ховард и Дэвид Лебланк, обучают программистов как писать безопасный код в компании Microsoft. На различных примерах продемонстрированы как сами ошибки, так и способы их исправления и защиты от них. Если вы – программист, то вам просто необходимо прочесть эту книгу. УДК 004.4 ББК 32.973.26018.2 Original English language edition published by McGrawHill Companies. Copyright © by McGrawHill Companies. All rights reserved. Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Материал, изложенный в данной книге, многократно проверен. Но поскольку вероятность технических ошибок все равно существует, издательство не может гарантировать абсолютную точность и правильность приводимых сведений. В связи с этим издательство не несет ответственности за возможные ошибки, связанные с использованием книги. ISBN 0-07-226085-8 (àíãë.) Copyright © by McGrawHill Companies. ISBN 5-9706-0027-Õ © Ïåðåâîä íà ðóññêèé ÿçûê, îôîðìëåíèå, èçäàíèå, Èçäàòåëüñêèé Äîì ÄÌÊ-ïðåññ
Моей потрясающей семье. Ничто не может сравниться с ощущением, которое испытываешь, когда приходишь домой и в ответ на вопрос «Кто дома, ребятки?» слышишь, как два голоска хором кричат: «Папа!» – Майкл Моему отцу, который объяснил мне, почему надо постоянно учиться и принимать новые вызовы. – Дэвид Маме. Она привила мне интеллектуальное любопытство и всегда была со мной рядом. – Джон
Содержание Об авторах .................................................................................... 18 О научных редакторах .................................................................. 19 Предисловие ................................................................................ 20 Благодарности ............................................................................. 22 Введение....................................................................................... 23 Структура книги.......................................................................... 24 Кому предназначена эта книга ................................................... 25 Какие главы следует прочитать .................................................. 25 Грех 1. Переполнение буфера ................................................ 26 В чем состоит грех ..................................................................... 26 Подверженные греху языки ........................................................ 27 Как происходит грехопадение .................................................... 27 Греховность C/C++................................................................. 31 Родственные грехи................................................................. 33 Где искать ошибку ...................................................................... 33 Выявление ошибки на этапе анализа кода ................................. 33 Тестирование ............................................................................. 34 Примеры из реальной жизни ...................................................... 35 CVE19990042 ....................................................................... 35 CVE20000389 – CVE20000392 ........................................... 35 CVE20020842, CVE20030095, CAN20030096 ................... 35 CAN20030352....................................................................... 36 Искупление греха ....................................................................... 37 Замена опасных функций работы со строками....................... 37 Следите за выделениями памяти ........................................... 37 Проверьте циклы и доступ к массивам ................................... 37 Пользуйтесь строками в стиле C++, а не C ............................. 37 Пользуйтесь STLконтейнерами вместо статических массивов ................................................................................ 38
Содержание Содержание Содержание Содержание Содержание Пользуйтесь инструментами анализа .................................... 38 Дополнительные защитные меры............................................... 38 Защита стека.......................................................................... 39 Запрет исполнения в стеке и куче .......................................... 39 Другие ресурсы .......................................................................... 39 Резюме....................................................................................... 40 Грех 2. Ошибки, связанные с форматной строкой ............ 42 В чем состоит грех ..................................................................... 42 Подверженные греху языки ........................................................ 42 Как происходит грехопадение .................................................... 43 Греховность C/C++................................................................. 45 Родственные грехи................................................................. 45 Где искать ошибку ...................................................................... 46 Выявление ошибки на этапе анализа кода ................................. 46 Тестирование ............................................................................. 46 Примеры из реальной жизни ...................................................... 47 CVE20000573 ....................................................................... 47 CVE20000844 ....................................................................... 47 Искупление греха ....................................................................... 47 Искупление греха в C/C++ ...................................................... 48 Дополнительные защитные меры............................................... 48 Другие ресурсы .......................................................................... 48 Резюме....................................................................................... 48 Грех 3. Переполнение целых чисел ....................................... 49 В чем состоит грех ..................................................................... 49 Подверженные греху языки ........................................................ 49 Как происходит грехопадение .................................................... 49 Греховность C и C++ .............................................................. 50 Поразрядные операции ......................................................... 55 Греховность C# ...................................................................... 55 Греховность Visual Basic и Visual Basic .NET ........................... 56 Греховность Java.................................................................... 57 Греховность Perl..................................................................... 58 Где искать ошибку ...................................................................... 59 Выявление ошибки на этапе анализа кода ................................. 59 C/C++ ..................................................................................... 59 C# .......................................................................................... 61 Java ........................................................................................ 62 Visual Basic и Visual Basic .NET ................................................ 62
Содержание Содержание Содержание Содержание Содержание Perl ......................................................................................... 62 Тестирование ............................................................................. 62 Примеры из реальной жизни ...................................................... 62 Ошибка в интерпретаторе Windows Script позволяет выполнить произвольный код ................................................ 63 Переполнение целого в конструкторе объекта SOAPParameter....................................................................... 63 Переполнение кучи в HTRдокументе, передаваемом поблочно, может скомпрометировать Webсервер ................ 63 Искупление греха ....................................................................... 64 Дополнительные защитные меры............................................... 66 Другие ресурсы .......................................................................... 66 Резюме....................................................................................... 66 Не рекомендуется .................................................................. 66 Грех 4. Внедрение SQLкоманд .............................................. 67 В чем состоит грех ..................................................................... 67 Подверженные греху языки ........................................................ 67 Как происходит грехопадение .................................................... 68 Греховность C# ...................................................................... 68 Греховность PHP .................................................................... 69 Греховность Perl/CGI.............................................................. 69 Греховность Java.................................................................... 70 Греховность SQL .................................................................... 71 Родственные грехи................................................................. 72 Где искать ошибку ...................................................................... 72 Выявление ошибки на этапе анализа кода ................................. 72 Тестирование ............................................................................. 73 Примеры из реальной жизни ...................................................... 75 CAN20040348....................................................................... 75 CAN20020554....................................................................... 75 Искупление греха ....................................................................... 75 Проверяйте все входные данные ........................................... 76 Никогда не применяйте конкатенацию для построения SQLпредложений .................................................................. 76 Дополнительные защитные меры............................................... 79 Другие ресурсы .......................................................................... 79 Резюме....................................................................................... 80 Грех 5. Внедрение команд....................................................... 82 В чем состоит грех ..................................................................... 82
Содержание Содержание Содержание Содержание Содержание Подверженные греху языки ........................................................ 82 Как происходит грехопадение .................................................... 82 Родственные грехи................................................................. 84 Где искать ошибку ...................................................................... 84 Выявление ошибки на этапе анализа кода ................................. 84 Тестирование ............................................................................. 86 Примеры из реальной жизни ...................................................... 86 CAN20011187....................................................................... 86 CAN20020652....................................................................... 87 Искупление греха ....................................................................... 87 Контроль данных .................................................................... 87 Если проверка не проходит .................................................... 90 Дополнительные защитные меры............................................... 90 Другие ресурсы .......................................................................... 91 Резюме....................................................................................... 91 Грех 6. Пренебрежение обработкой ошибок....................... 92 В чем состоит грех ..................................................................... 92 Подверженные греху языки ........................................................ 92 Как происходит грехопадение .................................................... 92 Раскрытие излишней информации ........................................ 92 Игнорирование ошибок ......................................................... 93 Неправильная интерпретация ошибок ................................... 93 Бесполезные возвращаемые значения .................................. 94 Обработка не тех исключений, что нужно ............................... 94 Обработка всех исключений .................................................. 94 Греховность C/C++................................................................. 94 Греховность C/C++ в Windows ................................................ 95 Греховность C++ .................................................................... 96 Греховность C#, VB.NET и Java .............................................. 96 Родственные грехи................................................................. 97 Где искать ошибку ...................................................................... 97 Выявление ошибки на этапе анализа кода ................................. 97 Тестирование ............................................................................. 97 Примеры из реальной жизни ...................................................... 98 CAN20040077 do_mremap в ядре Linux................................. 98 Искупление греха ....................................................................... 98 Искупление греха в C/C++ ...................................................... 98 Искупление греха в C#, VB.NET и Java.................................... 99 Другие ресурсы .......................................................................... 99 Резюме..................................................................................... 100
10 10 10 10 Содержание Содержание Содержание Содержание Содержание Грех 7. Кросссайтовые сценарии....................................... 101 В чем состоит грех ................................................................... 101 Подверженные греху языки ...................................................... 101 Как происходит грехопадение .................................................. 101 Греховное ISAPIрасширение или фильтр на C/C++ ............. 102 Греховность ASP .................................................................. 103 Греховность форм ASP.NET .................................................. 103 Греховность JSP................................................................... 103 Греховность PHP .................................................................. 103 Греховность Perlмодуля CGI.pm.......................................... 103 Греховность modperl........................................................... 104 Где искать ошибку .................................................................... 104 Выявление ошибки на этапе анализа кода ............................... 104 Тестирование ........................................................................... 105 Примеры из реальной жизни .................................................... 106 Уязвимость IBM Lotus Domino для атаки с кросссайтовым сценарием и внедрением HTML .............. 106 Ошибка при контроле входных данных в сценарии isqlplus, входящем в состав Oracle HTTP Server, позволяет удаленному пользователю провести атаку с кросссайтовым сценарием .............................................. 106 CVE20020840 ..................................................................... 107 Искупление греха ..................................................................... 107 Искупление греха в ISAPIрасширениях и фильтрах на C/C++ .............................................................................. 107 Искупление греха в ASP ....................................................... 108 Искупление греха в ASP.NET ................................................. 108 Искупление греха в JSP ........................................................ 108 Искупление греха в PHP ....................................................... 110 Искупление греха в Perl/CGI ................................................. 110 Искупление греха в modperl ................................................ 111 Замечание по поводу HTMLкодирования ............................ 111 Дополнительные защитные меры............................................. 112 Другие ресурсы ........................................................................ 112 Резюме..................................................................................... 113 Грех 8. Пренебрежение защитой сетевого трафика ....... 114 В чем состоит грех ................................................................... 114 Подверженные греху языки ...................................................... 114 Как происходит грехопадение .................................................. 115 Родственные грехи............................................................... 117
11 11 11 11 Содержание Содержание Содержание Содержание Содержание Где искать ошибку .................................................................... 117 Выявление ошибки на этапе анализа кода ............................... 118 Тестирование ........................................................................... 121 Примеры из реальной жизни .................................................... 121 TCP/IP .................................................................................. 121 Протоколы электронной почты............................................. 122 Протокол E*Trade ................................................................. 122 Искупление греха ..................................................................... 122 Рекомендации низкого уровня ............................................. 123 Дополнительные защитные меры............................................. 126 Другие ресурсы ........................................................................ 126 Резюме..................................................................................... 126 Грех 9. Применение загадочных URL и скрытых полей форм ............................................................................... 128 В чем состоит грех ................................................................... 128 Подверженные греху языки ...................................................... 128 Как происходит грехопадение .................................................. 128 Загадочные URL ................................................................... 128 Скрытые поля формы ........................................................... 129 Родственные грехи............................................................... 129 Где искать ошибку .................................................................... 130 Выявление ошибки на этапе анализа кода ............................... 130 Тестирование ........................................................................... 131 Примеры из реальной жизни .................................................... 131 CAN20001001..................................................................... 132 Модификация скрытого поля формы в программе MaxWebPortal ....................................................................... 132 Искупление греха ..................................................................... 132 Противник просматривает данные ....................................... 132 Противник воспроизводит данные ....................................... 133 Противник предсказывает данные ....................................... 135 Противник изменяет данные ................................................ 136 Дополнительные защитные меры............................................. 137 Другие ресурсы ........................................................................ 137 Резюме..................................................................................... 137 Грех 10. Неправильное применение SSL и TLS ................. 138 В чем состоит грех ................................................................... 138 Подверженные греху языки ...................................................... 138 Как происходит грехопадение .................................................. 139
12 12 12 12 Содержание Содержание Содержание Содержание Содержание Родственные грехи............................................................... 142 Где искать ошибку .................................................................... 142 Выявление ошибки на этапе анализа кода ............................... 143 Тестирование ........................................................................... 144 Примеры из реальной жизни .................................................... 145 Почтовые клиенты ................................................................ 145 Webбраузер Safari ............................................................... 146 SSLпрокси Stunnel .............................................................. 146 Искупление греха ..................................................................... 147 Выбор версии протокола ..................................................... 147 Выбор семейства шифров ................................................... 148 Проверка сертификата......................................................... 149 Проверка имени хоста.......................................................... 150 Проверка отзыва сертификата ............................................. 151 Дополнительные защитные меры............................................. 153 Другие ресурсы ........................................................................ 153 Резюме..................................................................................... 154 Грех 11. Использование слабых систем на основе паролей ................................................................... 155 В чем состоит грех ................................................................... 155 Подверженные греху языки ...................................................... 155 Как происходит грехопадение .................................................. 155 Родственные грехи............................................................... 158 Где искать ошибку .................................................................... 158 Выявление ошибки на этапе анализа кода ............................... 158 Политика управления сложностью пароля ........................... 158 Смена и переустановка пароля ............................................ 159 Протоколы проверки паролей .............................................. 159 Ввод и хранение паролей ..................................................... 160 Тестирование ........................................................................... 160 Примеры из реальной жизни .................................................... 161 CVE20051505 ..................................................................... 161 CVE20050432 ..................................................................... 162 Ошибка в TENEX ................................................................... 162 Кража у Пэрис Хилтон .......................................................... 163 Искупление греха ..................................................................... 163 Многофакторная аутентификация ....................................... 163 Хранение и проверка паролей.............................................. 164 Рекомендации по выбору протокола .................................... 167 Рекомендации по переустановке паролей ........................... 168
13 13 13 13 Содержание Содержание Содержание Содержание Содержание Рекомендации по выбору пароля ......................................... 169 Прочие рекомендации ......................................................... 170 Дополнительные защитные меры............................................. 170 Другие ресурсы ........................................................................ 170 Резюме..................................................................................... 170 Не рекомендуется ................................................................ 171 Стоит подумать .................................................................... 171 Грех 12. Пренебрежение безопасным хранением и защитой данных.................................................................... 172 В чем состоит грех ................................................................... 172 Подверженные греху языки ...................................................... 172 Как происходит грехопадение .................................................. 172 Слабый контроль доступа к секретным данным ................... 172 Греховность элементов управления доступом ..................... 174 Встраивание секретных данных в код .................................. 176 Родственные грехи............................................................... 177 Где искать ошибку .................................................................... 177 Выявление ошибки на этапе анализа кода ............................... 178 Тестирование ........................................................................... 178 Примеры из реальной жизни .................................................... 181 CVE20000100 ..................................................................... 181 CAN20021590..................................................................... 181 CVE19990886 ..................................................................... 181 CAN20040311..................................................................... 182 CAN20040391..................................................................... 182 Искупление греха ..................................................................... 182 Использование технологий защиты, предоставляемых операционной системой ...................................................... 183 Искупление греха в C/C++ для Windows 2000 и последующих версий......................................................... 183 Искупление греха в ASP.NET версии 1.1 и старше ................ 185 Искупление греха в C# на платформе .NET Framework 2.0 ... 185 Искупление греха в C/C++ для Mac OS X версии v10.2 и старше............................................................................... 186 Искупление греха без помощи операционной системы (или «храните секреты от греха подальше») ......................... 186 Замечание по поводу Java и Java KeyStore ........................... 188 Дополнительные защитные меры............................................. 189 Другие ресурсы ........................................................................ 190 Резюме..................................................................................... 191
14 14 14 14 Содержание Содержание Содержание Содержание Содержание Грех 13. Утечка информации ................................................ 192 В чем состоит грех ................................................................... 192 Подверженные греху языки ...................................................... 192 Как происходит грехопадение .................................................. 193 Побочные каналы ................................................................. 193 Слишком много информации! .............................................. 194 Модель безопасности информационного потока ................. 196 Греховность C# (и других языков)........................................ 198 Родственные грехи............................................................... 198 Где искать ошибку .................................................................... 199 Выявление ошибки на этапе анализа кода ............................... 199 Тестирование ........................................................................... 200 Имитация кражи ноутбука .................................................... 200 Примеры из реальной жизни .................................................... 200 Атака с хронометражем Дэна Бернстайна на шифр AES ...... 201 CAN20051411..................................................................... 201 CAN20051133..................................................................... 201 Искупление греха ..................................................................... 202 Искупление греха в C# (и других языках) ............................. 203 Учет локальности.................................................................. 203 Дополнительные защитные меры............................................. 203 Другие ресурсы ........................................................................ 204 Резюме..................................................................................... 204 Грех 14. Некорректный доступ к файлам........................... 206 В чем состоит грех ................................................................... 206 Подверженные греху языки ...................................................... 206 Как происходит грехопадение .................................................. 207 Греховность C/C++ в Windows .............................................. 207 Греховность C/C++............................................................... 208 Греховность Perl................................................................... 208 Греховность Python .............................................................. 208 Родственные грехи............................................................... 209 Где искать ошибку .................................................................... 209 Выявление ошибки на этапе анализа кода ............................... 209 Тестирование ........................................................................... 210 Примеры из реальной жизни .................................................... 210 CAN20050004..................................................................... 210 CAN20050799..................................................................... 211 CAN20040452 и CAN20040448 ......................................... 211 CVE20040115 Microsoft Virtual PC для Macintosh ................ 211
15 15 15 15 Содержание Содержание Содержание Содержание Содержание Искупление греха ..................................................................... 211 Искупление греха в Perl ........................................................ 212 Искупление греха в C/C++ для Unix ...................................... 212 Искупление греха в C/C++ для Windows ............................... 213 Получение места нахождения временного каталога пользователя ....................................................................... 213 Искупление греха в .NET ...................................................... 213 Дополнительные защитные меры............................................. 214 Другие ресурсы ........................................................................ 214 Резюме..................................................................................... 214 Грех 15. Излишнее доверие к системе разрешения сетевых имен ............................................................................ 215 В чем состоит грех ................................................................... 215 Подверженные греху языки ...................................................... 215 Как происходит грехопадение .................................................. 215 Греховные приложения ........................................................ 218 Родственные грехи............................................................... 218 Где искать ошибку .................................................................... 219 Выявление ошибки на этапе анализа кода ............................... 219 Тестирование ........................................................................... 220 Примеры из реальной жизни .................................................... 220 CVE20020676 ..................................................................... 220 CVE19990024 ..................................................................... 221 Искупление греха ..................................................................... 221 Другие ресурсы ........................................................................ 222 Резюме..................................................................................... 223 Грех 16. Гонки........................................................................... 224 В чем состоит грех ................................................................... 224 Подверженные греху языки ...................................................... 224 Как происходит грехопадение .................................................. 224 Греховность кода ................................................................. 226 Родственные грехи............................................................... 227 Где искать ошибку .................................................................... 227 Выявление ошибки на этапе анализа кода ............................... 228 Тестирование ........................................................................... 229 Примеры из реальной жизни .................................................... 229 CVE20011349 ..................................................................... 229 CAN20031073..................................................................... 230 CVE20040849 ..................................................................... 230
16 16 16 16 Содержание Содержание Содержание Содержание Содержание Искупление греха ..................................................................... 230 Дополнительные защитные меры............................................. 232 Другие ресурсы ........................................................................ 232 Резюме..................................................................................... 233 Грех 17. Неаутентифицированный обмен ключами ........ 234 В чем состоит грех ................................................................... 234 Подверженные греху языки ...................................................... 234 Как происходит грехопадение .................................................. 234 Родственные грехи............................................................... 236 Где искать ошибку .................................................................... 236 Выявление ошибки на этапе анализа кода ............................... 236 Тестирование ........................................................................... 237 Примеры из реальной жизни .................................................... 237 Атака с «человеком посередине» на Novell Netware .............. 237 CAN20040155..................................................................... 238 Искупление греха ..................................................................... 238 Дополнительные защитные меры............................................. 239 Другие ресурсы ........................................................................ 239 Резюме..................................................................................... 239 Грех 18. Случайные числа криптографического качества ..................................................................................... 240 В чем состоит грех ................................................................... 240 Подверженные греху языки ...................................................... 240 Как происходит грехопадение .................................................. 240 Греховность некриптографических генераторов ................. 241 Греховность криптографических генераторов ..................... 242 Греховность генераторов истинно случайных чисел ............ 242 Родственные грехи............................................................... 243 Где искать ошибку .................................................................... 243 Выявление ошибки на этапе анализа кода ............................... 244 Когда следует использовать случайные числа ..................... 244 Выявление мест, где применяются PRNGгенераторы ........ 244 Правильно ли затравлен CRNGгенератор ........................... 245 Тестирование ........................................................................... 245 Примеры из реальной жизни .................................................... 246 Браузер Netscape ................................................................. 246 Проблемы в OpenSSL ........................................................... 246 Искупление греха ..................................................................... 247
17 17 17 17 Содержание Содержание Содержание Содержание Содержание Windows ................................................................................ 247 Код для .NET......................................................................... 248 Unix ...................................................................................... 248 Java ...................................................................................... 249 Повторное воспроизведение потока случайных чисел ......... 250 Дополнительные защитные меры............................................. 250 Другие ресурсы ........................................................................ 250 Резюме..................................................................................... 251 Стоит подумать .................................................................... 251 Грех 19. Неудобный интерфейс ........................................... 252 В чем состоит грех ................................................................... 252 Подверженные греху языки ...................................................... 252 Как происходит грехопадение .................................................. 252 Каков круг ваших пользователей? ........................................ 253 Минное поле: показ пользователям информации о безопасности .................................................................... 254 Родственные грехи............................................................... 254 Где искать ошибку .................................................................... 255 Выявление ошибки на этапе анализа кода ............................... 255 Тестирование ........................................................................... 255 Примеры из реальной жизни .................................................... 256 Аутентификация сертификата в протоколе SSL/TLS ............ 256 Установка корневого сертификата в Internet Explorer 4.0 ..... 257 Искупление греха ..................................................................... 257 Делайте интерфейс пользователя простым и понятным ...... 258 Принимайте за пользователей решения, касающиеся безопасности................................................... 258 Упрощайте избирательное ослабление политики безопасности ....................................................................... 259 Ясно описывайте последствия ............................................. 260 Помогайте пользователю предпринять действия................. 262 Предусматривайте централизованное управление.............. 263 Другие ресурсы ........................................................................ 263 Резюме..................................................................................... 264 Приложение A. Соответствие между 19 смертными грехами и «10 ошибками» OWASP ........................................ 265 Приложение B. Сводка рекомендаций ............................... 266 Предметный указатель .......................................................... 276
Об авторах Майкл Ховард работает старшим менеджером по безопасности программного обеспечения в группе по обеспечению безопасности в Microsoft Corp. Является соавтором удостоенной различных наград книги «Writing Secure Code» (Разработка безопасного кода). Он также совместно с коллегами ведет колонку «Basic Training» в журнале «IEEE Security & Privacy Magazine» и является одним из авторов документа « Processes to Produce Secure Software» («Процессы в производстве безопасного программного обеспечения»), выпущенного организацией National Cyber Security Partnership для Министерства национальной безопасности (Department of Homeland Security). Будучи архитектором «Жизненного цикла разработки безопасного программного обеспечения» в Microsoft, Майкл посвящает большую часть времени выработке и внедрению передового опыта создания безопасных программ, которыми в конечном итоге будут пользоваться обычные люди. Дэвид Лебланк, доктор философии, в настоящее время работает главным архитектором программ в компании Webroot Software. До этого он занимал должность архитектора подсистемы безопасности в подразделении Microsoft, занимающемся разработкой Microsoft Office, стоял у истоков инициативы Trustworthy Computing и работал «белым хакером» в группе безопасности сетей в Microsoft. Дэвид является соавтором книг «Writing Secure Code» и «Assessing Network Secu- rity» («Оценка безопасности сети»), а также многочисленных статей. В погожие дни он любит конные прогулки вместе со своей женой Дженнифер. Джон Виега первым дал описание 19 серьезных просчетов при написании программ. Этот труд привлек внимание средств массовой информации и лег в основу настоящей книги. Джон является основателем и техническим директором компании Secure Software (www.securesoftware.com). Он один из авторов первой книги по безопасности программного обеспечения «Building Secure Software» («Создание безопасного программного обеспечения»), а также книг «Network Security and Cryptography with OpenSSL» («Безопасность и криптографические методы в сетях. Подход на основе библиотеки OpenSSL») и «Secure Programming Cookbook» («Рецепты для написания безопасных программ»). Он является основным автором процесса CLASP, призванного включить элементы безопасности в цикл разработки программ. Джон написал и сопровождает несколько относящихся к безопасности программ с открытыми исходными текстами. Раньше Джон занимал должности адъюнктпрофессора в техническом колледже штата Вирджиния и старшего научного сотрудника в Институте стратегии кибепространства (Cyber- space Policy Institute). Джон хорошо известен своими работами в области безопасности программ и криптографии, а в настоящее время он трудится над стандартами безопасности для сетей и программ.
О научных редакторах Алан Крассовски работает главным инженером по безопасности программного обеспечения в компании Symantec Corporation. Он возглавляет группу по безопасности продуктов, в задачу которой входит оказание помощи другим группам разработчиков в плане внедрения безопасных технологий, которые сокращают риски и способствуют завоеванию доверия со стороны клиентов. За последние 20 лет Алан работал над многими коммерческими программными проектами. До присоединения к Symantec он руководил разработками, был инженеромпрограм- мистом и оказывал консультативные услуги многим компаниям, занимающим лидирующее положение в отрасли, в частности Microsoft, IBM, Tektronix, Step Technologies. Screenplay Systems, Quark и Continental Insurance. Он получил научную степень бакалавра в области вычислительной техники в Рочестерском технологическом институте, штат НьюЙорк. Дэвид А. Уилер много лет занимается совершествованием практических методов разработки программ для систем с повышенным риском, в том числе особо крупных и нуждающихся в высокой степени безопасности. Он соавтор и соредактор книги «Software Inspection: An Industry Best Practice» («Инспекция программ: передовой опыт»), а также книг «Ada95: The Lovelace Tutorial» и «Secure Program- ming for Linux and UNIX HOWTO» («Рецепты безопасного программирования для Linux и UNIX»). Проживает в Северной Вирджинии.
Предисловие Предисловие Предисловие Предисловие Предисловие Предисловие В основе теории компьютеров лежит предположение о детерминированном поведении машин. Обычно мы ожидаем, что компьютер будет вести себя так, как мы его запрограммировали. На самом деле это лишь приближенное допущение. Современные компьютеры общего назначения и их программное обеспечение стали настолько сложными, что между щелчком по кнопке мыши и видимым результатом лежит множество программных слоев. И мы вынуждены полагаться на то, что все они работают правильно. Любой слой программного обеспечения может содержать ошибки, изза которых оно работает не так, как хотел автор, или, по крайней мере, не соответствует ожиданиям пользователя. Эти ошибки вносят в систему неопределенность, что может приводить к серьезным последствиям с точки зрения безопасности. Проявляться они могут поразному: от простого краха системы, и тогда ошибку можно использовать, чтобы вызвать отказ от обслуживания, до переполнения буфера, позволяющего противнику выполнить в системе произвольный код. Коль скоро поведение программных систем недетерминировано изза ошибок, то самые лучшие идеи по их защите – не более чем гипотезы. Мы можем воздвигать межсетевые экраны, реализовывать технологии защиты от переполнения буфера на уровне ОС, применять самые разнообразные методики, но все это никоим образом не изменит фундаментальную парадигму безопасности. И лишь за счет радикального улучшения качества программ и сокращения числа ошибок мы можем надеяться на успешность попыток обеспечить безопасность программного обеспечения. Устранение всех рисков, относящихся к безопасности, – нереальная задача при современном уровне развития систем разработки. У этой проблемы так много аспектов, что, даже для того чтобы просто оставаться в курсе дел, нужно посвящать этому все свое время. Что уж говорить о владении предметом в совершенстве! Если мы хотим добиться прогресса в битве против ошибок, связанных с безопасностью, то должны облегчить процесс их идентификации и устранения организациям, занимающимся разработкой, и при этом учесть реальные ограничения. О безопасности программного обеспечения написано немало отличных книг, в том числе и авторами настоящего издания. Но я полагаю необходимым не углубляться в разного рода сложности, а предложить разработчикам небольшой набор критически важных советов, следуя которым они смогут повысить качество своих программ с минимальными усилиями. Идея в том, чтобы осветить наиболее типичные проблемы, которые нетрудно устранить, а не ставить нереалистичную задачу достижения полной безопасности.
21 21 21 21 В бытность начальником отдела в Министерстве национальной безопасности я попросил Джона Виегу составить перечень 19 «грехов» программиста. Первоначальный список был призван поставить корпоративный мир в известность о тех ошибках, которые чаще всего угрожают безопасности, но он не был составлен в форме рецептов. А эта книга именно такова. В ней приводится список проблем, от которых организацииразработчики должны защищаться в первую очередь, и даются рекомендации, как не допустить самого возникновения этих проблем. В книге также показано, как выявить подобные ошибки: посредством анализа кода или тестирования. Описание приемов и методик краткое и точное, авторы четко формулируют, что надо, а чего никогда не надо делать. Авторы проделали огромную работу, чтобы представить вашему вниманию список наиболее распространенных дефектов, от которых страдает безопасность современных программ. Надеюсь, что сообщество разработчиков оценит эту книгу и воспользуется ей для устранения недетерминизма и рисков, с которыми мы постоянно сталкиваемся. Амит Йоран, бывший начальник отдела национальной кибербезопасности Министерства национальной безопасности Грейт Фоллс, Вирджиния, 21 мая 2005 г. Предисловие Предисловие Предисловие Предисловие Предисловие
Благодарности Эта книга – косвенный результат дальновидности Амита Йорана. Мы благодарны ему за то, что во время работы в Министерстве национальной безопасности (и позже) он делал все возможное, чтобы привлечь внимание к проблемам безопасности программного обеспечения. Мы также выражаем признательность следующим специалистам в области безопасности за усердие, с которым они рецензировали черновики отдельных глав, за их мудрость и за откровенные комментарии: Дэвиду Рафаэлю (David Raphael), Марку Кэрфи (Mark Curphy), Рудольфу Араю (Rudolph Arauj), Алану Крассовски (Alan Krassowski), Дэвиду Уилеру (David Wheeler) и Биллу Хильфу (Bill Hilf). Эта книга не состоялась бы без настойчивости сотрудников издательства McGrawHill. Большое спасибо трем «Дж»: Джейн Браунлоу (Jane Brownlow), Дженнифер Хауш (Jennifer Housh) и Джоди Маккензи ( Jody McKenzie).
- Книги
- Зарубежная компьютерная литература
- Майкл Ховард
📚 19 смертных грехов, угрожающих безопасности программ читать книгу
Читайте только на ЛитРес!
Как читать книгу после покупки
- Чтение только в Литрес «Читай!»
По вашей ссылке друзья получат скидку 10% на эту книгу, а вы будете получать 10% от стоимости их покупок на свой счет ЛитРес. Подробнее
Стоимость книги: 199 ₽
Ваш доход с одной покупки друга: 19,90 ₽
Чтобы посоветовать книгу друзьям, необходимо войти или зарегистрироваться
- Объем: 360 стр. 27 иллюстраций
- Жанр: зарубежная компьютерная литература, программированиеРедактировать
Эта и ещё 2 книги за 399 ₽
По абонементу вы каждый месяц можете взять из каталога одну книгу до 700 ₽ и две книги из специальной подборки. Узнать больше
Оплачивая абонемент, я принимаю условия оплаты и её автоматического продления, указанные в оферте
Описание книги
Эта книга необходима всем разработчикам программного обеспечения, независимо от платформы, языка или вида приложений. В ней рассмотрены 19 грехов, угрожающих безопасности программ, и показано, как от них избавиться. Рассмотрены уязвимости на языках C/C++, C#, Java, Visual Basic, Visual Basic.NET, Perl, Python в операционных системах Windows, Unix, Linux, Mac OS, Novell Netware. Авторы издания, Майкл Ховард и Дэвид Лебланк, обучают программистов, как писать безопасный код в компании Microsoft. На различных примерах продемонстрированы как сами ошибки, так и способы их исправления и защиты от них. Если вы программист, то вам просто необходимо прочесть эту книгу.
Подробная информация
- Возрастное ограничение:
- 0+
- Дата выхода на ЛитРес:
- 29 июля 2011
- Объем:
- 360 стр. 27 иллюстраций
- ISBN:
- 5-9706-0027-X
- Переводчик:
- А. А. Слинкин
- Правообладатель:
- ДМК Пресс
- Оглавление
«19 смертных грехов, угрожающих безопасности программ» — читать онлайн бесплатно фрагмент книги. Оставляйте комментарии и отзывы, голосуйте за понравившиеся.
Оставьте отзыв
Другие книги автора
Поделиться отзывом на книгу
Майкл Ховард, Дэвид Лебланк, ещё 2 автора
19 смертных грехов, угрожающих безопасности программТекст
Моей потрясающей семье. Ничто не может сравниться с ощущением, которое испытываешь, когда приходишь домой и в ответ на вопрос «Кто дома, ребятки?» слышишь, как два голоска хором кричат: «Папа!»
– Майкл
Моему отцу, который объяснил мне, почему надо постоянно учиться и принимать новые вызовы.
– Дэвид
Маме. Она привила мне интеллектуальное любопытство и всегда была со мной рядом.
-Джон
Об авторах
Майкл Ховард работает старшим менеджером по безопасности программного обеспечения в группе по обеспечению безопасности в Microsoft Corp. Является соавтором удостоенной различных наград книги «Writing Secure Code» (Разработка безопасного кода). Он также совместно с коллегами ведет колонку «Basic Training» в журнале «ШЕЕ Security & Privacy Magazine» и является одним из авторов документа «Processes to Produce Secure Software» («Процессы в производстве безопасного программного обеспечения»), выпущенного организацией National Cyber Security Partnership для Министерства национальной безопасности (Department of Homeland Security). Будучи архитектором «Жизненного цикла разработки безопасного программного обеспечения» в Microsoft, Майкл посвящает большую часть времени выработке и внедрению передового опыта создания безопасных программ, которыми в конечном итоге будут пользоваться обычные люди.
Дэвид Лебланк, доктор философии, в настоящее время работает главным архитектором программ в компании Webroot Software. До этого он занимал должность архитектора подсистемы безопасности в подразделении Microsoft, занимающемся разработкой Microsoft Office, стоял у истоков инициативы Trustworthy Computing и работал «белым хакером» в группе безопасности сетей в Microsoft. Дэвид является соавтором книг «Writing Secure Code» и «Assessing Network Secu–rity» («Оценка безопасности сети»), а также многочисленных статей. В погожие дни он любит конные прогулки вместе со своей женой Дженнифер.
Джон Виега первым дал описание 19 серьезных просчетов при написании программ. Этот труд привлек внимание средств массовой информации и лег в основу настоящей книги. Джон является основателем и техническим директором компании Secure Software (www.securesoftware.com). Он один из авторов первой книги по безопасности программного обеспечения «Building Secure Software» («Создание безопасного программного обеспечения»), а также книг «Network Security and Cryptography with OpenSSL» («Безопасность и криптографические методы в сетях. Подход на основе библиотеки OpenSSL») и «Secure Programming СоокЬоок» («Рецепты для написания безопасных программ»). Он является основным автором процесса CLASP, призванного включить элементы безопасности в цикл разработки программ. Джон написал и сопровождает несколько относящихся к безопасности программ с открытыми исходными текстами. Раньше Джон занимал должности адъюнкт–профессора в техническом колледже штата Вирджиния и старшего научного сотрудника в Институте стратегии кибепространства (Cyberspace Policy Institute). Джон хорошо известен своими работами в области безопасности программ и криптографии, а в настоящее время он трудится над стандартами безопасности для сетей и программ.
О научных редакторах
Алан Крассовски работает главным инженером по безопасности программного обеспечения в компании Symantec Corporation. Он возглавляет группу по безопасности продуктов, в задачу которой входит оказание помощи другим группам разработчиков в плане внедрения безопасных технологий, которые сокращают риски и способствуют завоеванию доверия со стороны клиентов. За последние 20 лет Алан работал над многими коммерческими программными проектами. До присоединения к Symantec он руководил разработками, был инженером–программистом и оказывал консультативные услуги многим компаниям, занимающим лидирующее положение в отрасли, в частности Microsoft, IBM, Tektronix, Step Technologies. Screenplay Systems, Quark и Continental Insurance. Он получил научную степень бакалавра в области вычислительной техники в Рочестерском технологическом институте, штат Нью–Йорк.
Дэвид А. Уилер много лет занимается совершествованием практических методов разработки программ для систем с повышенным риском, в том числе особо крупных и нуждающихся в высокой степени безопасности. Он соавтор и соредактор книги «Software Inspection: An Industry Best Practice» («Инспекция программ: передовой опыт»), а также книг «Ada95: The Lovelace Tutorial» и «Secure Programming for Linux and UNIX HOWTO» («Рецепты безопасного программирования для Linux и UNIX»). Проживает в Северной Вирджинии.
Предисловие
В основе теории компьютеров лежит предположение о детерминированном поведении машин. Обычно мы ожидаем, что компьютер будет вести себя так, как мы его запрограммировали. На самом деле это лишь приближенное допущение. Современные компьютеры общего назначения и их программное обеспечение стали настолько сложными, что между щелчком по кнопке мыши и видимым результатом лежит множество программных слоев. И мы вынуждены полагаться на то, что все они работают правильно.
Любой слой программного обеспечения может содержать ошибки, из–за которых оно работает не так, как хотел автор, или, по крайней мере, не соответствует ожиданиям пользователя. Эти ошибки вносят в систему неопределенность, что может приводить к серьезным последствиям с точки зрения безопасности. Проявляться они могут по–разному: от простого краха системы, и тогда ошибку можно использовать, чтобы вызвать отказ от обслуживания, до переполнения буфера, позволяющего противнику выполнить в системе произвольный код.
Коль скоро поведение программных систем недетерминировано из–за ошибок, то самые лучшие идеи по их защите – не более чем гипотезы. Мы можем воздвигать межсетевые экраны, реализовывать технологии защиты от переполнения буфера на уровне ОС, применять самые разнообразные методики, но все это никоим образом не изменит фундаментальную парадигму безопасности. И лишь за счет радикального улучшения качества программ и сокращения числа ошибок мы можем надеяться на успешность попыток обеспечить безопасность программного обеспечения.
Устранение всех рисков, относящихся к безопасности, – нереальная задача при современном уровне развития систем разработки. У этой проблемы так много аспектов, что, даже для того чтобы просто оставаться в курсе дел, нужно посвящать этому все свое время. Что уж говорить о владении предметом в совершенстве!
Если мы хотим добиться прогресса в битве против ошибок, связанных с безопасностью, то должны облегчить процесс их идентификации и устранения организациям, занимающимся разработкой, и при этом учесть реальные ограничения. О безопасности программного обеспечения написано немало отличных книг, в том числе и авторами настоящего издания. Но я полагаю необходимым не углубляться в разного рода сложности, а предложить разработчикам небольшой набор критически важных советов, следуя которым они смогут повысить качество своих программ с минимальными усилиями. Идея в том, чтобы осветить наиболее типичные проблемы, которые нетрудно устранить, а не ставить нереалистичную задачу достижения полной безопасности.
В бытность начальником отдела в Министерстве национальной безопасности я попросил Джона Виегу составить перечень 19 «грехов» программиста. Первоначальный список был призван поставить корпоративный мир в известность о тех ошибках, которые чаще всего угрожают безопасности, но он не был составлен в форме рецептов. А эта книга именно такова. В ней приводится список проблем, от которых организации–разработчики должны защищаться в первую очередь, и даются рекомендации, как не допустить самого возникновения этих проблем. В книге также показано, как выявить подобные ошибки: посредством анализа кода или тестирования. Описание приемов и методик краткое и точное, авторы четко формулируют, что надо, а чего никогда не надо делать. Авторы проделали огромную работу, чтобы представить вашему вниманию список наиболее распространенных дефектов, от которых страдает безопасность современных программ. Надеюсь, что сообщество разработчиков оценит эту книгу и воспользуется ей для устранения недетерминизма и рисков, с которыми мы постоянно сталкиваемся.
Амит Йоран,
бывший начальник
отдела национальной кибербезопасности
Министерства национальной безопасности
Грейт Фоллс, Вирджиния,
21 мая 2005 г.
Благодарности
Эта книга – косвенный результат дальновидности Амита Йорана. Мы благодарны ему за то, что во время работы в Министерстве национальной безопасности (и позже) он делал все возможное, чтобы привлечь внимание к проблемам безопасности программного обеспечения. Мы также выражаем признательность следующим специалистам в области безопасности за усердие, с которым они рецензировали черновики отдельных глав, за их мудрость и за откровенные комментарии: Дэвиду Рафаэлю (David Raphael), Марку Кэрфи (Mark Curphy), Рудольфу Араю (Rudolph Arauj), Алану Крассовски (Alan Krassowski), Дэвиду Уилеру (David Wheeler) и Биллу Хильфу (Bill Hilf). Эта книга не состоялась бы без настойчивости сотрудников издательства McGraw–Hill. Большое спасибо трем «Дж»: Джейн Браунлоу (Jane Brownlow), Дженнифер Хауш (Jennifer Housh) и Джоди Маккензи Qody McKenzie).
Введение
В 2004 году Амит Йоран, тогда начальник отдела национальной кибербезопасности Министерства национальной безопасности США, объявил, что около 95% всех дефектов программ, относящихся к безопасности, проистекают из 19 типичных ошибок, природа которых вполне понятна. Мы не станем подвергать сомнению ваши интеллектуальные способности и объяснять важность безопасного программного обеспечения в современном взаимосвязанном мире, вы и так все понимаете, но приведем основные принципы поиска и исправления наиболее распространенных ошибок в вашем собственном коде.
Неприятная особенность ошибок, касающихся безопасности, состоит в том, что допустить их очень легко, а результаты одной неправильно написанной строчки могут быть поистине катастрофическими. Червь Blaster смог распространиться из–за ошибки всего в двух строках кода.
Если попытаться выразить весь накопленный опыт одной фразой, то, наверное, она звучала бы так: «Никакой язык программирования, никакая платформа не способны сделать программу безопасной, это можете сделать только вы». Существует масса литературы о том, как создавать безопасное программное обеспечение, да и авторы настоящей книги написали на эту тему немало текстов, к которым прислушиваются. И все же есть потребность в небольшой, простой и прагматической книге, в которой рассматривались бы все основные проблемы.
Работая над этой книгой, мы старались придерживаться следующих правил, которые не позволили бы оторваться от земли.
□ Простота. Мы не тратили место на пустую болтовню. Здесь вы не найдете ни репортажей с поля боя, ни забавных анекдотов – только голые факты. Скорее всего, вы просто хотите сделать свою работу качественно и в кратчайшие сроки. Поэтому мы стремились к тому, чтобы найти нужную информацию можно было просто и быстро.
□ Краткость. Это следствие предыдущего правила: сосредоточившись исключительно на фактах, мы смогли сделать книгу небольшой по объему. Это введение тоже не будет многословным.
□ Кроссплатформенность. Интернет – это среда, связывающая между собой мириады вычислительных устройств, работающих под управлением разных операционных систем и программ, написанных на разных языках. Мы хотели, чтобы эта книга была полезна всем разработчикам, поэтому представленные примеры относятся к большинству имеющихся операционных систем.
□ Многоязычие. Следствие предыдущего правила: мы приводим примеры ошибок в программах, которые составлены на разных языках.
Структура книги
В каждой главе описывается один «смертный грех». Вообще–то они никак не упорядочены, но самые гнусные мы разместили в начале книги. Главы разбиты на разделы:
□ «В чем состоит грех» – краткое введение, в котором объясняется, почему данное деяние считается грехом;
□ «Как происходит грехопадение» – описывается суть проблемы; принципиальная ошибка, которая доводит до греха;
□ «Подверженные греху языки» – перечень языков, подверженных данному греху;
□ «Примеры ошибочного кода» – конкретные примеры ошибок в программах, написанных на разных языках и работающих на разных платформах;
□ «Где искать ошибку» – на что нужно прежде всего обращать внимание при поиске в программе подобных ошибок;
□ «Выявление ошибки на этапе анализа кода» тут все понятно: как найти грехи в своем коде. Мы понимаем, что разработчики – люди занятые, поэтому старались писать этот раздел коротко и по делу;
□ «Тестирование» – описываются инструменты и методики тестирования, которые позволят обнаружить признаки рассматриваемого греха;
□ «Примеры из реальной жизни» – реальные примеры данного греха, взятые из базы данных типичных уязвимостей и брешей (Common Vulnerabilities and Exposures – CVE) (www.cve.mitre.org). с сайта BugTraq (www.securityfocus.com) или базы данных уязвимостей в программах с открытыми исходными текстами (Open Source Vulnerability Database) (www.osvdb.org). В каждом случае мы приводим свои комментарии. Примечание: пока мы работали над этой книгой, рассматривался вопрос об отказе с 15 октября 2005 года от номеров CAN в базе данных CVE и переходе исключительно на номера CVE. Если это случится, то все ссылки на номер ошибки «CAN…» следует заменить ссылкой на соответствующий номер CVE. Например, если вы не сможете найти статью CAN–2004–0029 (ошибка Lotus Notes для Linux), попробуйте поискать CVE–2004–0029;
□ «Искупление греха» – как исправить ошибку, чтобы избавиться от греха. И в этом случае мы демонстрируем варианты для разных языков;
□ «Дополнительные защитные меры» – другие меры, которые можно предпринять. Они не исправляют ошибку, но мешают противнику воспользоваться потенциальным дефектом, если вы ее все–таки допустите;
□ «Другие ресурсы» – это небольшая книжка, поэтому мы даем ссылки на другие источники информации: главы книг, статьи и сайты;
□ «Резюме» – это неотъемлемая часть главы, предполагается, что вы будете к ней часто обращаться. Здесь приводятся списки рекомендуемых, нерекомендуемых и возможных действий при написании нового или анализе существующего кода. Не следует недооценивать важность этого раздела! Содержание всех Резюме сведено воедино в Приложении В.
Кому предназначена эта книга
Эта книга адресована всем разработчикам программного обеспечения. В ней описаны наиболее распространенные ошибки, приводящие к печальным последствиям, а равно способы их устранения до того, как программа будет передана заказчику. Вы найдете здесь полезный материал вне зависимости от того, на каком языке пишете, будь то С, С++, Java, С#, ASP, ASP.NET, Visual Basic, PHP, Perl или JSP. Она применима к операционным системам Windows, Linux, Apple Mac OS X, OpenBSD и Solaris, а равно к самым разнообразным платформам: «толстым» клиентам, «тонким» клиентам или пользователям Web. Честно говоря, безопасность не зависит ни от языка, ни от операционной системы, ни от платформы. Если ваш код небезопасен, то пользователи беззащитны перед атакой.
Какие главы следует прочитать
Это небольшая книжка, поэтому не ленитесь. Прочтите ее целиком, ведь никогда не знаешь, над чем предстоит работать в будущем.
Но все же есть грехи, которым подвержены лишь некоторые языки и некоторые среды, поэтому важно, чтобы в первую очередь вы прочли о тех, что специфичны именно для вашего языка программирования, вашей ОС и вашей среды исполнения (Web и т. п.).
Вот минимум, с которым надо ознакомиться при различных предположениях о специфике вашей работы.
□ Всем рекомендуется ознакомиться с грехами 6, 12 и 13.
□ Если вы программируете наязыках C/C++, то обязаны прочесть о грехах 1, 2 и З.
□ Если вы программируете для Web с использованием таких технологий, как JSP, ASP, ASP.NET, PHP, CGI или Perl, то познакомьтесь с грехами 7 и 9.
□ Если вы создаете приложения для работы с базами данных, например Oracle, MySQL, DB2 или SQL Server, прочтите о грехе 4.
□ Если вы разрабатываете сетевые системы (клиент–серверные, через Web и прочие), не проходите мимо грехов 5, 8, 10, 14 и 15.
□ Если в вашем приложении каким–то образом используется криптография или пароли, обратите внимание на грехи 8, 10, 11, 17 и 18.
□ Если ваша программа работает в ОС Linux, Mac OS X или UNIX, следует прочесть о грехе 16.
□ Если с вашим приложением будут работать неопытные пользователи, взгляните на описание греха 19.
Мы полагаем, что эта книга важна, поскольку в работе над ней приняли участие трое наиболее авторитетных на сегодняшний день специалистов–практиков в сфере безопасности, а также потому, что она охватывает все распространенные языки и платформы для развертывания программ. Надеемся, что вы найдете здесь немало полезной информации.
Майкл Ховард, Дэвид Лебланк, Джон Виега, июль 2005 г.
Грех 1.
Переполнение буфера
В чем состоит грех
Уже давно ясно, что переполнение буфера – это проблема всех низкоуровневых языков программирования. Возникает она потому, что в целях эффективности данные и информация о потоке выполнения программы перемешаны, а в низкоуровневом языке разрешен прямой доступ к памяти. С и С++ больше других языков страдают от переполнений буфера.
Строго говоря, переполнение возникает, когда программа пытается писать в память, не принадлежащую выделенному буферу, но есть и ряд других ошибок, приводящих к тому же эффекту. Одна из наиболее интересных связана с форматной строкой, мы рассмотрим ее в описании греха 2. Еще одно проявление той же проблемы встречается, когда противнику разрешено писать в произвольную область памяти за пределами некоторого массива. И хотя формально это не есть классическое переполнение буфера, мы рассмотрим здесь и этот случай.
Результатом переполнения буфера может стать что угодно – от краха программы до получения противником полного контроля над приложением, а если приложение запущено от имени пользователя с высоким уровнем доступа (root, Administrator или System), то и над всей операционной системой и другими пользователями. Если рассматриваемое приложение – это сетевая служба, то ошибка может привести к распространению червя. Первый получивший широкую известность Интернет–червь эксплуатировал ошибку в сервере finger, он так и назывался – «finger–червь Роберта Т. Морриса» (или просто «червь Морриса»). Казалось бы, что после того как в 1988 году Интернет был поставлен на колени, мы уже должны научиться избегать переполнения буфера, но и сейчас нередко появляются сообщения о такого рода ошибках в самых разных программах.
Быть может, кто–то думает, что такие ошибки свойственны лишь небрежным и беззаботным программистам. Однако на самом деле эта проблема сложна, решения не всегда тривиальны, и всякий, кто достаточно часто программировал на С или С++, почти наверняка хоть раз да допускал нечто подобное. Автор этой главы, который учит других разработчиков, как писать безопасный код, сам однажды передал заказчику программу, в которой было переполнение на одну позицию (off–by–one overflow). Даже самые лучшие, самые внимательные программисты допускают ошибки, но при этом они знают, насколько важно тщательно тестировать программу, чтобы эти ошибки не остались незамеченными.
Подверженные греху языки
Чаще всего переполнение буфера встречается в программах, написанных на С, недалеко от него отстает и С++. Совсем просто переполнить буфер в ассемблерной программе, поскольку тут нет вообще никаких предохранительных механизмов. По существу, С++ так же небезопасен, как и С, поскольку основан на этом языке. Но использование стандартной библиотеки шаблонов STL позволяет свести риск некорректной работы со строками к минимуму, а более строгий компилятор С++ помогает программисту избегать некоторых ошибок. Даже если ваша программа составлена на чистом С, мы все же рекомендуем использовать компилятор С++, чтобы выловить как можно больше ошибок.
В языках более высокого уровня, появившихся позже, программист уже не имеет прямого доступа к памяти, хотя за это и приходится расплачиваться производительностью. В такие языки, как Java, С# и Visual Basic, уже встроены строковый тип, массивы с контролем выхода за границы и запрет на прямой доступ к памяти (в стандартном режиме). Кто–то может сказать, что в таких языках переполнение буфера невозможно, но правильнее было бы считать, что оно лишь гораздо менее вероятно. Ведь в большинстве своем эти языки реализованы на С или С++, а ошибка в реализации может стать причиной переполнения буфера. Еще один потенциальный источник проблемы заключается в том, что на какой–то стадии все эти высокоуровневые языки должны обращаться к операционной системе, а уж она–то почти наверняка написана на С или С++. Язык С# позволяет обойти стандартные механизмы .NET, объявив небезопасный участок с помощью ключевого слова unsafe. Да, это упрощает взаимодействие с операционной системой и библиотеками, написанными на C/C++, но одновременно открывает возможность допустить обычные для C/C++ ошибки. Даже если вы программируете преимущественно на языках высокого уровня, не отказывайтесь от тщательного контроля данных, передаваемых внешним библиотекам, если не хотите пасть жертвой содержащихся в них ошибок.
Мы не станем приводить исчерпывающий список языков, подверженных ошибкам из–за переполнения буфера, скажем лишь, что к их числу относится большинство старых языков.
Скачать программу для просмотраСделайте свои программы безопасными, исключив с самого начала причины возможных уязвимостей. Эта книга необходима всем разработчикам программного обеспечения, независимо от платформы, языка или вида приложений. В ней рассмотрены 19 грехов, угрожающих безопасности программ, и показано как от них избавиться. Рассмотрены уязвимости на языках C/C++, C#, Java, Visual Basic, Visual Basic .NET, Perl, Python в операционных системах Windows, Unix, Linux, Mac OS, Novell Netware. Авторы бестселлеров Майкл Ховард и Дэвид Лебланк, обучающие программистов в Microsoft, как писать безопасный код, объединили усилия с Джоном Виега, человеком, который сформулировал 19 смертных грехов программиста, и решили написать это руководство. На различных примерах продемонстрированы как сами ошибки, так и способы их исправления и защиты от них.
| Вложение | Размер |
|---|---|
| 19 смертных грехов, угрожающих безопасности программ. Как не допустить типичных ошибок | 2.74 МБ |
Маме. Она привила мне интеллектуальное любопытство и всегда была со мной рядом.
-Джон
Об авторах
Майкл Ховард работает старшим менеджером по безопасности программного обеспечения в группе по обеспечению безопасности в Microsoft Corp. Является соавтором удостоенной различных наград книги «Writing Secure Code» (Разработка безопасного кода). Он также совместно с коллегами ведет колонку «Basic Training» в журнале «ШЕЕ Security & Privacy Magazine» и является одним из авторов документа «Processes to Produce Secure Software» («Процессы в производстве безопасного программного обеспечения»), выпущенного организацией National Cyber Security Partnership для Министерства национальной безопасности (Department of Homeland Security). Будучи архитектором «Жизненного цикла разработки безопасного программного обеспечения» в Microsoft, Майкл посвящает большую часть времени выработке и внедрению передового опыта создания безопасных программ, которыми в конечном итоге будут пользоваться обычные люди.
Дэвид Лебланк, доктор философии, в настоящее время работает главным архитектором программ в компании Webroot Software. До этого он занимал должность архитектора подсистемы безопасности в подразделении Microsoft, занимающемся разработкой Microsoft Office, стоял у истоков инициативы Trustworthy Computing и работал «белым хакером» в группе безопасности сетей в Microsoft. Дэвид является соавтором книг «Writing Secure Code» и «Assessing Network Secu–rity» («Оценка безопасности сети»), а также многочисленных статей. В погожие дни он любит конные прогулки вместе со своей женой Дженнифер.
Джон Виега первым дал описание 19 серьезных просчетов при написании программ. Этот труд привлек внимание средств массовой информации и лег в основу настоящей книги. Джон является основателем и техническим директором компании Secure Software (www.securesoftware.com). Он один из авторов первой книги по безопасности программного обеспечения «Building Secure Software» («Создание безопасного программного обеспечения»), а также книг «Network Security and Cryptography with OpenSSL» («Безопасность и криптографические методы в сетях. Подход на основе библиотеки OpenSSL») и «Secure Programming СоокЬоок» («Рецепты для написания безопасных программ»). Он является основным автором процесса CLASP, призванного включить элементы безопасности в цикл разработки программ. Джон написал и сопровождает несколько относящихся к безопасности программ с открытыми исходными текстами. Раньше Джон занимал должности адъюнкт–профессора в техническом колледже штата Вирджиния и старшего научного сотрудника в Институте стратегии кибепространства (Cyberspace Policy Institute). Джон хорошо известен своими работами в области безопасности программ и криптографии, а в настоящее время он трудится над стандартами безопасности для сетей и программ.
О научных редакторах
Алан Крассовски работает главным инженером по безопасности программного обеспечения в компании Symantec Corporation. Он возглавляет группу по безопасности продуктов, в задачу которой входит оказание помощи другим группам разработчиков в плане внедрения безопасных технологий, которые сокращают риски и способствуют завоеванию доверия со стороны клиентов. За последние 20 лет Алан работал над многими коммерческими программными проектами. До присоединения к Symantec он руководил разработками, был инженером–программистом и оказывал консультативные услуги многим компаниям, занимающим лидирующее положение в отрасли, в частности Microsoft, IBM, Tektronix, Step Technologies. Screenplay Systems, Quark и Continental Insurance. Он получил научную степень бакалавра в области вычислительной техники в Рочестерском технологическом институте, штат Нью–Йорк.
Дэвид А. Уилер много лет занимается совершествованием практических методов разработки программ для систем с повышенным риском, в том числе особо крупных и нуждающихся в высокой степени безопасности. Он соавтор и соредактор книги «Software Inspection: An Industry Best Practice» («Инспекция программ: передовой опыт»), а также книг «Ada95: The Lovelace Tutorial» и «Secure Programming for Linux and UNIX HOWTO» («Рецепты безопасного программирования для Linux и UNIX»). Проживает в Северной Вирджинии.
Предисловие
В основе теории компьютеров лежит предположение о детерминированном поведении машин. Обычно мы ожидаем, что компьютер будет вести себя так, как мы его запрограммировали. На самом деле это лишь приближенное допущение. Современные компьютеры общего назначения и их программное обеспечение стали настолько сложными, что между щелчком по кнопке мыши и видимым результатом лежит множество программных слоев. И мы вынуждены полагаться на то, что все они работают правильно.
Любой слой программного обеспечения может содержать ошибки, из–за которых оно работает не так, как хотел автор, или, по крайней мере, не соответствует ожиданиям пользователя. Эти ошибки вносят в систему неопределенность, что может приводить к серьезным последствиям с точки зрения безопасности. Проявляться они могут по–разному: от простого краха системы, и тогда ошибку можно использовать, чтобы вызвать отказ от обслуживания, до переполнения буфера, позволяющего противнику выполнить в системе произвольный код.
Коль скоро поведение программных систем недетерминировано из–за ошибок, то самые лучшие идеи по их защите – не более чем гипотезы. Мы можем воздвигать межсетевые экраны, реализовывать технологии защиты от переполнения буфера на уровне ОС, применять самые разнообразные методики, но все это никоим образом не изменит фундаментальную парадигму безопасности. И лишь за счет радикального улучшения качества программ и сокращения числа ошибок мы можем надеяться на успешность попыток обеспечить безопасность программного обеспечения.
Устранение всех рисков, относящихся к безопасности, – нереальная задача при современном уровне развития систем разработки. У этой проблемы так много аспектов, что, даже для того чтобы просто оставаться в курсе дел, нужно посвящать этому все свое время. Что уж говорить о владении предметом в совершенстве!
Если мы хотим добиться прогресса в битве против ошибок, связанных с безопасностью, то должны облегчить процесс их идентификации и устранения организациям, занимающимся разработкой, и при этом учесть реальные ограничения. О безопасности программного обеспечения написано немало отличных книг, в том числе и авторами настоящего издания. Но я полагаю необходимым не углубляться в разного рода сложности, а предложить разработчикам небольшой набор критически важных советов, следуя которым они смогут повысить качество своих программ с минимальными усилиями. Идея в том, чтобы осветить наиболее типичные проблемы, которые нетрудно устранить, а не ставить нереалистичную задачу достижения полной безопасности.
В бытность начальником отдела в Министерстве национальной безопасности я попросил Джона Виегу составить перечень 19 «грехов» программиста. Первоначальный список был призван поставить корпоративный мир в известность о тех ошибках, которые чаще всего угрожают безопасности, но он не был составлен в форме рецептов. А эта книга именно такова. В ней приводится список проблем, от которых организации–разработчики должны защищаться в первую очередь, и даются рекомендации, как не допустить самого возникновения этих проблем. В книге также показано, как выявить подобные ошибки: посредством анализа кода или тестирования. Описание приемов и методик краткое и точное, авторы четко формулируют, что надо, а чего никогда не надо делать. Авторы проделали огромную работу, чтобы представить вашему вниманию список наиболее распространенных дефектов, от которых страдает безопасность современных программ. Надеюсь, что сообщество разработчиков оценит эту книгу и воспользуется ей для устранения недетерминизма и рисков, с которыми мы постоянно сталкиваемся.
Амит Йоран,
бывший начальник
отдела национальной кибербезопасности
Министерства национальной безопасности
Грейт Фоллс, Вирджиния,
21 мая 2005 г.
Благодарности
Эта книга – косвенный результат дальновидности Амита Йорана. Мы благодарны ему за то, что во время работы в Министерстве национальной безопасности (и позже) он делал все возможное, чтобы привлечь внимание к проблемам безопасности программного обеспечения. Мы также выражаем признательность следующим специалистам в области безопасности за усердие, с которым они рецензировали черновики отдельных глав, за их мудрость и за откровенные комментарии: Дэвиду Рафаэлю (David Raphael), Марку Кэрфи (Mark Curphy), Рудольфу Араю (Rudolph Arauj), Алану Крассовски (Alan Krassowski), Дэвиду Уилеру (David Wheeler) и Биллу Хильфу (Bill Hilf). Эта книга не состоялась бы без настойчивости сотрудников издательства McGraw–Hill. Большое спасибо трем «Дж»: Джейн Браунлоу (Jane Brownlow), Дженнифер Хауш (Jennifer Housh) и Джоди Маккензи Qody McKenzie).
Введение
В 2004 году Амит Йоран, тогда начальник отдела национальной кибербезопасности Министерства национальной безопасности США, объявил, что около 95% всех дефектов программ, относящихся к безопасности, проистекают из 19 типичных ошибок, природа которых вполне понятна. Мы не станем подвергать сомнению ваши интеллектуальные способности и объяснять важность безопасного программного обеспечения в современном взаимосвязанном мире, вы и так все понимаете, но приведем основные принципы поиска и исправления наиболее распространенных ошибок в вашем собственном коде.
Неприятная особенность ошибок, касающихся безопасности, состоит в том, что допустить их очень легко, а результаты одной неправильно написанной строчки могут быть поистине катастрофическими. Червь Blaster смог распространиться из–за ошибки всего в двух строках кода.
Если попытаться выразить весь накопленный опыт одной фразой, то, наверное, она звучала бы так: «Никакой язык программирования, никакая платформа не способны сделать программу безопасной, это можете сделать только вы». Существует масса литературы о том, как создавать безопасное программное обеспечение, да и авторы настоящей книги написали на эту тему немало текстов, к которым прислушиваются. И все же есть потребность в небольшой, простой и прагматической книге, в которой рассматривались бы все основные проблемы.
Работая над этой книгой, мы старались придерживаться следующих правил, которые не позволили бы оторваться от земли.
□ Простота. Мы не тратили место на пустую болтовню. Здесь вы не найдете ни репортажей с поля боя, ни забавных анекдотов – только голые факты. Скорее всего, вы просто хотите сделать свою работу качественно и в кратчайшие сроки. Поэтому мы стремились к тому, чтобы найти нужную информацию можно было просто и быстро.
□ Краткость. Это следствие предыдущего правила: сосредоточившись исключительно на фактах, мы смогли сделать книгу небольшой по объему. Это введение тоже не будет многословным.
□ Кроссплатформенность. Интернет – это среда, связывающая между собой мириады вычислительных устройств, работающих под управлением разных операционных систем и программ, написанных на разных языках. Мы хотели, чтобы эта книга была полезна всем разработчикам, поэтому представленные примеры относятся к большинству имеющихся операционных систем.
□ Многоязычие. Следствие предыдущего правила: мы приводим примеры ошибок в программах, которые составлены на разных языках.
Структура книги
В каждой главе описывается один «смертный грех». Вообще–то они никак не упорядочены, но самые гнусные мы разместили в начале книги. Главы разбиты на разделы:
□ «В чем состоит грех» – краткое введение, в котором объясняется, почему данное деяние считается грехом;
□ «Как происходит грехопадение» – описывается суть проблемы; принципиальная ошибка, которая доводит до греха;
□ «Подверженные греху языки» – перечень языков, подверженных данному греху;
□ «Примеры ошибочного кода» – конкретные примеры ошибок в программах, написанных на разных языках и работающих на разных платформах;
□ «Где искать ошибку» – на что нужно прежде всего обращать внимание при поиске в программе подобных ошибок;
□ «Выявление ошибки на этапе анализа кода» тут все понятно: как найти грехи в своем коде. Мы понимаем, что разработчики – люди занятые, поэтому старались писать этот раздел коротко и по делу;
□ «Тестирование» – описываются инструменты и методики тестирования, которые позволят обнаружить признаки рассматриваемого греха;
□ «Примеры из реальной жизни» – реальные примеры данного греха, взятые из базы данных типичных уязвимостей и брешей (Common Vulnerabilities and Exposures – CVE) (www.cve.mitre.org). с сайта BugTraq (www.securityfocus.com) или базы данных уязвимостей в программах с открытыми исходными текстами (Open Source Vulnerability Database) (www.osvdb.org). В каждом случае мы приводим свои комментарии. Примечание: пока мы работали над этой книгой, рассматривался вопрос об отказе с 15 октября 2005 года от номеров CAN в базе данных CVE и переходе исключительно на номера CVE. Если это случится, то все ссылки на номер ошибки «CAN…» следует заменить ссылкой на соответствующий номер CVE. Например, если вы не сможете найти статью CAN–2004–0029 (ошибка Lotus Notes для Linux), попробуйте поискать CVE–2004–0029;
□ «Искупление греха» – как исправить ошибку, чтобы избавиться от греха. И в этом случае мы демонстрируем варианты для разных языков;
□ «Дополнительные защитные меры» – другие меры, которые можно предпринять. Они не исправляют ошибку, но мешают противнику воспользоваться потенциальным дефектом, если вы ее все–таки допустите;
□ «Другие ресурсы» – это небольшая книжка, поэтому мы даем ссылки на другие источники информации: главы книг, статьи и сайты;
□ «Резюме» – это неотъемлемая часть главы, предполагается, что вы будете к ней часто обращаться. Здесь приводятся списки рекомендуемых, нерекомендуемых и возможных действий при написании нового или анализе существующего кода. Не следует недооценивать важность этого раздела! Содержание всех Резюме сведено воедино в Приложении В.
Кому предназначена эта книга
Эта книга адресована всем разработчикам программного обеспечения. В ней описаны наиболее распространенные ошибки, приводящие к печальным последствиям, а равно способы их устранения до того, как программа будет передана заказчику. Вы найдете здесь полезный материал вне зависимости от того, на каком языке пишете, будь то С, С++, Java, С#, ASP, ASP.NET, Visual Basic, PHP, Perl или JSP. Она применима к операционным системам Windows, Linux, Apple Mac OS X, OpenBSD и Solaris, а равно к самым разнообразным платформам: «толстым» клиентам, «тонким» клиентам или пользователям Web. Честно говоря, безопасность не зависит ни от языка, ни от операционной системы, ни от платформы. Если ваш код небезопасен, то пользователи беззащитны перед атакой.
Какие главы следует прочитать
Это небольшая книжка, поэтому не ленитесь. Прочтите ее целиком, ведь никогда не знаешь, над чем предстоит работать в будущем.
Но все же есть грехи, которым подвержены лишь некоторые языки и некоторые среды, поэтому важно, чтобы в первую очередь вы прочли о тех, что специфичны именно для вашего языка программирования, вашей ОС и вашей среды исполнения (Web и т. п.).
Вот минимум, с которым надо ознакомиться при различных предположениях о специфике вашей работы.
□ Всем рекомендуется ознакомиться с грехами 6, 12 и 13.
□ Если вы программируете наязыках C/C++, то обязаны прочесть о грехах 1, 2 и З.
□ Если вы программируете для Web с использованием таких технологий, как JSP, ASP, ASP.NET, PHP, CGI или Perl, то познакомьтесь с грехами 7 и 9.
□ Если вы создаете приложения для работы с базами данных, например Oracle, MySQL, DB2 или SQL Server, прочтите о грехе 4.
□ Если вы разрабатываете сетевые системы (клиент–серверные, через Web и прочие), не проходите мимо грехов 5, 8, 10, 14 и 15.
□ Если в вашем приложении каким–то образом используется криптография или пароли, обратите внимание на грехи 8, 10, 11, 17 и 18.
□ Если ваша программа работает в ОС Linux, Mac OS X или UNIX, следует прочесть о грехе 16.
□ Если с вашим приложением будут работать неопытные пользователи, взгляните на описание греха 19.
Мы полагаем, что эта книга важна, поскольку в работе над ней приняли участие трое наиболее авторитетных на сегодняшний день специалистов–практиков в сфере безопасности, а также потому, что она охватывает все распространенные языки и платформы для развертывания программ. Надеемся, что вы найдете здесь немало полезной информации.
Майкл Ховард, Дэвид Лебланк, Джон Виега, июль 2005 г.
Грех 1.
Переполнение буфера
В чем состоит грех
Уже давно ясно, что переполнение буфера – это проблема всех низкоуровневых языков программирования. Возникает она потому, что в целях эффективности данные и информация о потоке выполнения программы перемешаны, а в низкоуровневом языке разрешен прямой доступ к памяти. С и С++ больше других языков страдают от переполнений буфера.
Строго говоря, переполнение возникает, когда программа пытается писать в память, не принадлежащую выделенному буферу, но есть и ряд других ошибок, приводящих к тому же эффекту. Одна из наиболее интересных связана с форматной строкой, мы рассмотрим ее в описании греха 2. Еще одно проявление той же проблемы встречается, когда противнику разрешено писать в произвольную область памяти за пределами некоторого массива. И хотя формально это не есть классическое переполнение буфера, мы рассмотрим здесь и этот случай.
Результатом переполнения буфера может стать что угодно – от краха программы до получения противником полного контроля над приложением, а если приложение запущено от имени пользователя с высоким уровнем доступа (root, Administrator или System), то и над всей операционной системой и другими пользователями. Если рассматриваемое приложение – это сетевая служба, то ошибка может привести к распространению червя. Первый получивший широкую известность Интернет–червь эксплуатировал ошибку в сервере finger, он так и назывался – «finger–червь Роберта Т. Морриса» (или просто «червь Морриса»). Казалось бы, что после того как в 1988 году Интернет был поставлен на колени, мы уже должны научиться избегать переполнения буфера, но и сейчас нередко появляются сообщения о такого рода ошибках в самых разных программах.
Быть может, кто–то думает, что такие ошибки свойственны лишь небрежным и беззаботным программистам. Однако на самом деле эта проблема сложна, решения не всегда тривиальны, и всякий, кто достаточно часто программировал на С или С++, почти наверняка хоть раз да допускал нечто подобное. Автор этой главы, который учит других разработчиков, как писать безопасный код, сам однажды передал заказчику программу, в которой было переполнение на одну позицию (off–by–one overflow). Даже самые лучшие, самые внимательные программисты допускают ошибки, но при этом они знают, насколько важно тщательно тестировать программу, чтобы эти ошибки не остались незамеченными.
Подверженные греху языки
Чаще всего переполнение буфера встречается в программах, написанных на С, недалеко от него отстает и С++. Совсем просто переполнить буфер в ассемблерной программе, поскольку тут нет вообще никаких предохранительных механизмов. По существу, С++ так же небезопасен, как и С, поскольку основан на этом языке. Но использование стандартной библиотеки шаблонов STL позволяет свести риск некорректной работы со строками к минимуму, а более строгий компилятор С++ помогает программисту избегать некоторых ошибок. Даже если ваша программа составлена на чистом С, мы все же рекомендуем использовать компилятор С++, чтобы выловить как можно больше ошибок.
В языках более высокого уровня, появившихся позже, программист уже не имеет прямого доступа к памяти, хотя за это и приходится расплачиваться производительностью. В такие языки, как Java, С# и Visual Basic, уже встроены строковый тип, массивы с контролем выхода за границы и запрет на прямой доступ к памяти (в стандартном режиме). Кто–то может сказать, что в таких языках переполнение буфера невозможно, но правильнее было бы считать, что оно лишь гораздо менее вероятно. Ведь в большинстве своем эти языки реализованы на С или С++, а ошибка в реализации может стать причиной переполнения буфера. Еще один потенциальный источник проблемы заключается в том, что на какой–то стадии все эти высокоуровневые языки должны обращаться к операционной системе, а уж она–то почти наверняка написана на С или С++. Язык С# позволяет обойти стандартные механизмы .NET, объявив небезопасный участок с помощью ключевого слова unsafe. Да, это упрощает взаимодействие с операционной системой и библиотеками, написанными на C/C++, но одновременно открывает возможность допустить обычные для C/C++ ошибки. Даже если вы программируете преимущественно на языках высокого уровня, не отказывайтесь от тщательного контроля данных, передаваемых внешним библиотекам, если не хотите пасть жертвой содержащихся в них ошибок.
Мы не станем приводить исчерпывающий список языков, подверженных ошибкам из–за переполнения буфера, скажем лишь, что к их числу относится большинство старых языков.
Как происходит грехопадение
Классическое проявление переполнения буфера – это затирание стека. В откомпилированной программе стек используется для хранения управляющей информации (например, аргументов). Здесь находится также адрес возврата из функции и, поскольку число регистров в процессорах семейства х86 невелико, сюда же перед входом в функцию помещаются регистры для временного хранения. Увы, в стеке же выделяется память для локальных переменных. Иногда их неправильно называют статически распределенными в противоположность динамической памяти, выделенной из кучи. Когда кто–то говорит о переполнении статического буфера, он чаще всего имеет в виду переполнение буфера в стеке. Суть проблемы в том, что если приложение пытается писать за границей массива, распределенного в стеке, то противник получает возможность изменить управляющую информацию. А это уже половина успеха, ведь цель противника – модифицировать управляющие данные по своему усмотрению.
Возникает вопрос: почему мы продолжаем пользоваться столь очевидно опасной системой? Избежать проблемы, по крайней мере частично, можно было бы, перейдя на 64–разрядный процессор Intel Itanium, где адрес возврата хранится в регистре. Но тогда пришлось бы смириться с утратой обратной совместимости, хотя на момент работы над этой книгой представляется, что процессор х64 в конце концов станет популярным.
Можно также спросить, почему мы не переходим на языки, осуществляющие строгий контроль массивов и запрещающие прямую работу с памятью. Дело в том, что для многих приложений производительность высокоуровневых языков недостаточно высока. Возможен компромисс: писать интерфейсные части программ, с которыми взаимодействуют пользователи, на языке высокого уровня, а основную часть кода – на низкоуровневом языке. Другое решение–в полной мере задействовать возможности С++ и пользоваться написанными для него библиотеками для работы со строками и контейнерными классами. Например, в Web–сервере Internet Information Server (IIS) 6.0 обработка всех входных данных переписана с использованием строковых классов; один отважный разработчик даже заявил, что даст отрезать себе мизинец, если в его коде отыщется хотя бы одно переполнение буфера. Пока что мизинец остался при нем, и за два года после выхода этого сервера не было опубликовано ни одного сообщения о проблемах с его безопасностью. Поскольку современные компиляторы умеют работать с шаблонными классами, на С++ теперь можно создавать очень эффективный код.
Но довольно теории, рассмотрим пример.
tinclude <stdio.h>
void DontDoIhis (char* input)
{
char buf[16];
strcpy(buf, input);
printf(«%sn» , buf);
}
int main(int argc, char* argv[])
{
// мы не проверяем аргументы
// а чего еще ожидать от программы, в которой используется
// функция strcpy?
DontDoThis(argv[l]);
return 0;
}
Откомпилируем эту программу и посмотрим, что произойдет. Для демонстрации автор собрал приложение, включив отладочные символы и отключив контроль стека. Хороший компилятор предпочел бы встроить такую короткую функцию, как DontDoThis, особенно если она вызывается только один раз, поэтому оптимизация также была отключена. Вот как выглядит стек непосредственно перед вызовом strcpy:
0x0012FEC0 с8 fe 12 00 .. <– адрес аргумента buf
0x0012FEC4 с4 18 32 00 .2. <– адрес аргумента input
0x0012FEC8 d0 fe 12 00 .. <– начало буфера buf
0x0012FECC 04 80 40 00 .<<Unicode: 80>>@.
0x0012FED0 el 02 3f 4f .?0
0x0012FED4 66 00 00 00 f… <– конец buf
0x0012FED8 e4 fe 12 00 .. <– содержимое регистра EBP
0x0012FEDC 3f 10 40 00 ?.@. <– адрес возврата
0x0012FEE0 c4 18 32 00 .2. <– адрес аргумента DontDoThis
0x0012FEE4 cO ff 12 00 ..
0x0012FEE8 10 13 40 00 ..@. <– адрес, куда вернется main()
Напомним, что стек растет сверху вниз (от старших адресов к младшим). Этот пример выполнялся на процессоре Intel со схемой адресации «little–endian». Это означает, что младший байт хранится в памяти первым, так что адрес возврата «3f104000» на самом деле означает 0x0040103f.
А теперь посмотрим, что происходит, когда буфер buf переполняется. Сразу вслед за buf находится сохраненное значение регистра EBP (Extended Base Pointer – расширенный указатель на базу). ЕВР содержит указатель кадра стека; при ошибке на одну позицию его значение будет затерто. Если противник сможет получить контроль над областью памяти, начинающейся с адреса 0x0012fe00 (последний байт вследствие ошибки обнулен), то программа перейдет по этому адресу и выполнит помещенный туда противником код.
Если не ограничиваться переполнением на один байт, то следующим будет затерт адрес возврата. Коль скоро противник сумеет получить контроль над этим значением и записать в буфер, адрес которого известен, достаточное число байтов ассемблерного кода, то мы будем иметь классический пример переполнения буфера, допускающего написание эксплойта. Отметим, что ассемблерный код (его обычно называют shell–кодом, потому что чаще всего задача эксплойта – получить доступ к оболочке (shell)) необязательно размещать именно в перезаписываемом буфере. Это типичный случай, но, вообще говоря, код можно внедрить в любое место вашей программы. Не обольщайтесь, полагая, что переполнению подвержен только очень небольшой участок.
После того как адрес возврата переписан, в распоряжении противника оказываются аргументы атакуемой функции. Если функция перед возвратом каким–то образом модифицирует переданные ей аргументы, то открываются новые соблазнительные возможности. Это следует иметь в виду, оценивая эффективность таких средств борьбы с переполнением стека, как программа Stackguard Криспина Коуэена (Crispin Cowan), программа ProPolice, распространяемая IBM, и флаг /GS в компиляторе Microsoft.
Как видите, мы предоставили противнику как минимум три возможности получить контроль над нашим приложением, а это ведь была очень простая функция. Если в стеке объявлен объект класса С++ с виртуальными функциями, то станет доступна таблица указателей на виртуальные функции; такая ошибка тоже легко эксплуатируется. Если одним из аргументов функции является указатель на функцию, что часто бывает в оконных системах (например, в X Window System или Microsoft Windows), то перезапись этого указателя перед использованием–очевидный способ получить контроль над приложением.
Есть множество хитроумных способов перехватить управление программой, гораздо больше, чем способен измыслить наш слабый ум. Существует несоответствие между возможностями и ресурами, доступными разработчику и хакеру. В своей работе вы ограничены сроками, тогда как противник может тратить все свое свободное время на то, чтобы придумать, как заставить вашу программу делать то, что нужно ему. Ваша программа может защищать ресурс, достаточно ценный, чтобы потратить на ее взлом несколько месяцев. Хакер тратит массу времени на то, чтобы быть в курсе последних достижений в области взлома. К его услугам – такие ресурсы, как www.metasploit.com, позволяющие в несколько «кликов» создать shell–код, который будет делать что угодно и при этом включать только символы из ограниченного набора.
Если вы попытаетесь выяснить, можно ли создать эксплойт для какой–то программы, то, скорее всего, полученный ответ будет неполным. В большинстве случае можно лишь доказать, что программа либо уязвима, либо вы недостаточно хитроумны (или потратили на поиск решения недостаточно времени), чтобы написать для нее эксплойт. Очень редко можно с уверенностью утверждать, что для некоторого переполнения эксплойт невозможен.
Мораль, стало быть, в том, что самое правильное – исправить ошибки! Сколько раз случалось, что модификации с целью «повысить качество кода» заодно приводили и к исправлению ошибок, связанных с безопасностью. Автор как–то битых три часа убеждал команду разработчиков исправить некую ошибку. В переписке приняло участие восемь человек, и мы потратили 20 человекочасов (половина рабочей недели одного программиста), споря, нужно ли исправлять ошибку, поскольку разработчики жаждали получить доказательства того, что для нее можно написать эксплойт. Когда эксперты по безопасности доказали, что проблема действительно есть, для исправления потребовался час работы программиста и еще четыре часа на Тестирование. Сколько же времени ушло впустую!
Заниматься анализом надо непосредственно перед поставкой программы. На завершающих стадиях разработки хорошо бы иметь обоснованное предположение о том, достаточно ли велика опасность написания эксплойта для ошибки, чтобы оправдать риск, связанный с переделками и, как следствие, нестабильностью продукта.
Распространено заблуждение, будто переполнение буфера в куче не так опасно, как буфера в стеке. Это совершенно неправильно. Большинство реализаций кучи страдают тем же фундаментальным пороком, что и стек, – пользовательские и управляющие данные хранятся вместе. Часто можно заставить менеджер кучи поместить четыре указанных противником байта по выбранному им же адресу. Детали атаки на кучу довольно сложны. Недавно Matthew «shok» Conover и Oded Horovitz подготовили очень ясную презентацию на эту тему под названием «Re–liable Windows Heap Exploits» («Надежный эксплойт переполнения кучи в Win–dows»), которую можно найти на странице http://cansecwest.com/csw04/csw04–Oded+Connover.ppt. Даже если сам менеджер кучи не поддается взломщику, в соседних участках памяти могут находиться указатели на функции или на переменные, в которые записывается информация. Когда–то эксплуатация переполнений кучи считалась экзотическим и трудным делом, теперь же это одна из самых распространенных атакуемых ошибок.
Греховность C/C++
В программах на языках C/C++ есть масса способов переполнить буфер. Вот строки, породившие finger–червя Морриса:
char buf[20] ;
gets (buf) ;
Не существует никакого способа вызвать gets для чтения из стандартного ввода без риска переполнить буфер. Используйте вместо этого fgets. Наверное, второй по популярности способ вызвать переполнение – это воспользоваться функцией strcpy (см. предыдущий пример). А вот как еще можно напроситься на неприятности:
char buf[20];
char prefix[] = «http://»;
strcpy(buf, prefix);
strncat(buf, path, sizeof(buf));
Что здесь не так? Проблема в неудачном интерфейсе функции strncat. Ей нужно указать, сколько символов свободно в буфере, а не общую длину буфера. Вот еще один распространенный код, приводящий к переполнению:
char buf[MAX_PATH];
sprintf(buf, «%s – %dn», path, errno);
Если не считать нескольких граничных случаев, функцию sprintf почти невозможно использовать безопасно. Для Microsoft Windows было выпущено извещение о критической ошибке, связанной с применением sprintf для отладочного протоколирования. Подробности см. в бюллетене MS04–011 (точная ссылка приведена в разделе «Другие ресурсы»).
А вот еще пример:
char buf [ 32] ;
strncpy(buf, data, strlen(data));
Что неверно? В последнем аргументе передана длина входного буфера, а не размер целевого буфера!
Еще один способ столкнуться с проблемой – по ошибке считать байты вместо символов. Если вы работаете с кодировкой ASCII, то между ними нет разницы, но в кодировке Unicode один символ представляется двумя байтами. Вот пример:
_snwprintf(wbuf, sizeof(wbuf), «%sn», input);
Следующее переполнение несколько интереснее:
bool CopyStructs(InputFile* pInFile, unsigned long count)
{
unsigned long i;
m_pStructs = new Structs[count];
for(i = 0; i < count; i++)
{
if(!ReadFromFile(pInFile, &(m_pStructs[i])))
break;
}
}
Как здесь может возникнуть ошибка? Оператор new[] в языке С++ делает примерно то же, что такой код:
ptr = malloc(sizeof(type) * count);
Если значение count может поступать от пользователя, то нетрудно задать его так, чтобы при умножении возникло переполнение. Тогда будет выделен буфер гораздо меньшего размера, чем необходимо, и противник сможет его переполнить. В компиляторе С++, который будет поставляться в составе Microsoft Visual Studio 2005, реализована внутренняя проверка для недопущения такого рода ошибок. Аналогичная проблема может возникнуть во многих реализациях функции calloc, которая выполняет примерно такую же операцию. В этом и состоит коварство многих ошибок, связанных с переполнением целых чисел: опасно не само это переполнение, а вызванное им переполнение буфера. Но подробнее об этом мы расскажем в грехе 3.
Вот как еще может возникать переполнение буфера:
#define MAX_BUF 256
void BadCode(char* input)
{
short len;
char buf[MAX_BUF];
len = strlen(input);
// конечно, мы можем использовать strcpy безопасно
if(len < MAX_BUF)
strcpy(buf, input);
}
На первый взгляд, все хорошо, не так ли? Но на самом деле здесь ошибка на ошибке. Детали мы отложим до обсуждения переполнения целых числе в грехе 3, а пока заметим, что литералы всегда имеют тип signed int. Если длина входных данных (строка input) превышает 32К, то переменная len станет отрицательна, она будет расширена до типа int с сохранением знака и окажется меньше MAX_BUF, что приведет к переполнению. Еще одна ошибка возникнет, если длина строки превосходит 64К. В этом случае мы имеем ошибку усечения: len оказывается маленьким положительным числом. Основной способ исправления – объявлять переменные для хранения размеров как имеющие тип size_t. Еще одна скрытая проблема заключается в том, что входные данные могут не заканчиваться нулем. Вот как может выглядеть исправленный код:
const size_t MAX_BUF = 256;
void LessBadCode(char* input)
{
size_t len;
char buf[MAX_BUF];
len = strlen(input);
// конечно, мы можем использовать strcpy безопасно
if(len < MAX_BUF)
strcpy(buf, input);
}
Родственные грехи
С этим грехом тесно связано переполнение целых чисел. Если вы пытаетесь устранить ошибки переполнения буфера путем использования функций работы со строками семейства strn… или вычисляете размер выделяемого из кучи буфера, то очень важно не допускать арифметических ошибок.
Ошибки при работе с форматной строкой могут дать такой же эффект, как переполнение буфера, хотя переполнением в строгом смысле не являются. Обычно такие ошибки вообще не связаны ни с какими буферами.
Вариантом переполнения буфера является запись в массив без контроля выхода за границы. Если противник сумеет прямо или косвенно подсунуть индекс массива и вы не проверите, что он принадлежит допустимому диапазону, то возможна запись по произвольному адресу в памяти. При этом не только изменяется поток выполнения программы, но могут быть затерты несмежные области памяти, а это сводит на нет все меры противодействия переполнению буфера.
Где искать ошибку
Вот на что нужно обращать внимание в первую очередь:
□ любые входные данные, будь то из сети, из файла или из командной строки;
□ передача данных из вышеупомянутых источников входных данных во внутренние структуры;
□ использование небезопасных функций работы со строками;
□ использование арифметических операций для вычисления размера буфера или числа свободных байтов в нем.
Выявление ошибки на этапе анализа кода
Обнаружить присутствие этого греха во время анализа кода может быть как совсем легко, так и очень сложно. Проще всего проанализировать все случаи употребления функций работы со строками. Надо иметь в виду, что вы можете найти много мест, где функции вызываются безопасно, но наш опыт показывает, что ошибки могут скрываться даже в правильных вызовах. Коэффициент регрессии, характерный для модификации кода с целью перехода исключительно на безопасные функции, обычно очень мал (от одной десятой до одной сотой величины, типичной для исправления ошибки), зато это позволит устранить возможность некоторых видов эксплойтов.
Добиться этого можно, например, поручив выполнение задачи компилятору. Если вы исключите объявления функций strcpy, strcat, sprintf и им подобных из заголовочных файлов, то компилятор укажет все места в коде, где они встречаются. Но имейте в виду, что некоторые приложения полностью или частично переопределяют библиотеку времени исполнения для языка С.
Сложнее отыскать переполнение кучи. Чтобы решить эту задачу, нужно помнить о возможности переполнения целых, о чем пойдет речь в грехе 3. Начать нужно с выявления всех мест, где производится выделение памяти, а затем проверить, с помощью каких арифметических операций вычислялся размер буфера.
Наилучший подход состоит в том, чтобы проследить, как используются все поступающие от пользователя данные, начиная с точки входа в приложение и далее по всем функциям. Очень важно знать, что именно может контролировать противник.
Тестирование
Одной из наиболее эффективных методик является рандомизированное тестирование (fuzz testing), когда на вход подаются полуслучайные данные. Попробуйте увеличить длину входных строк и понаблюдайте за поведением приложения. Обратите внимание на одну особенность: иногда множество неправильных значений входных данных довольно мало. Например, в одном месте программы проверяется, что длина входной строки должна быть меньше 260 байтов, а в другом месте выделяется буфер длиной 256. Если вы подадите на вход очень длинную строку, то она, конечно, будет отвергнута, но стоит попасть точно в неконтролируемый интервал–и можно писать эксплойт. Часто проблему можно найти, используя при тестировании степени двойки или степени двойки плюс–минус единица.
Стоит также поискать те места, где пользователь может задать длину чего–либо. Измените длину так, чтобы она не соответствовала строке, и особое внимание обращайте на возможность переполнения целого: опасность представляют случаи, когда длина +1 = 0.
Для рандомизированного тестирования нужно собрать специальную тестовую версию программы. В отладочные версии часто вставляют утверждения, которые изменяют поток выполнения программы и могут помешать обнаружить условия, при которых возможен экплойт. С другой стороны, современные компиляторы включают в отладочные версии хитроумный код для обнаружения порчи стека. В зависимости от используемого распределителя памяти и операционной системы вы можете также включить более строгую проверку целостности кучи.
Если вы используете утверждения для контроля входных данных, то имеет смысл перейти от такой формы:
assert(len < MAX_PATH);
к следующей
if(len >= MAX_PATH)
{
assert(false);
return false;
}
Всегда следует тестировать программу с помощью какой–либо утилиты обнаружения ошибок при работе с памятью, например AppVerifier для Windows (см. ссылку в разделе «Другие ресурсы»). Это позволит выявить ошибки, связанные с небольшим или трудноуловимым переполнением буфера.
Примеры из реальной жизни
Ниже приведены некоторые примеры переполнения буфера, взятые из базы данных типичных уязвимостей и брешей (CVE) на сайте http://cve.mitre.org. Интересно, что когда мы работали над этой книгой, в базе CVE по запросу «buffer overrim» находилось 1734 записи. Поиск по бюллетеням CERT, в которых документируются самые широко распространенные и серьезные уязвимости, по тому же запросу дал 107 документов.
CVE–1999–0042
Цитата из описания ошибки: «Переполнение буфера в реализации серверов IMAP и POP Вашингтонского университета». Эта же ошибка очень подробно документирована в бюллетене CERT за номером СА–1997–09. Переполнение происходит во время аутентификации для доступа к серверам, реализующим протоколы Post Office Protocol (POP) и Internet Message Access Protocol (IMAP). Связанная с ней уязвимость состоит в том, что сервер электронной почты не мог отказаться от избыточных привилегий, поэтому эксплойт давал противнику права пользователя root. Это переполнение поставило под удар довольно много систем.
Контрольная программа, созданная для поиска уязвимых версий этого сервера, обнаружила аналогичные дефекты в программе SLMail 2.5 производства Seattle Labs, о чем помещен отчет на странице www.winnetmag.com/Article/ArticleID/9223/ 9223.html.
CVE–2000–0389 – CVE–2000–0392
Из CVE–2000–0389: «Переполнение буфера в функции krb_rd_req в Kerberos версий 4 и 5 позволяет удаленному противнику получить привилегии root».
Из CVE–2000–0390: «Переполнение буфера в функции krb425_conv_principal в Kerberos 5 позволяет удаленному противнику получить привилегии root».
Из CVE–2000–0391: «Переполнение буфера в программе krshd, входящей в состав Kerberos 5, позволяет удаленному противнику получить привилегии root».
Из CVE–2000–0392: «Переполнение буфера в программе krshd, входящей в состав Kerberos 5, позволяет удаленному противнику получить привилегии root».
Эти ошибки в реализации системы Kerberos производства МТИ документированы в бюллетене CERT СА–2000–06 по адресу www.cert.org/advisories/CA–2000–06.html. Хотя исходные тексты открыты уже несколько лет и проблема коренится в использовании опасных функций работы со строками (strcat), отчет о ней появился только в 2000 году.
CVE–2002–0842, CVE–2003–0095, CAN–2003–0096
Из CVE–2002–0842:
Ошибка при работе с форматной строкой в одной модификации функции mod_dav, применяемой для протоколирования сообщений о плохом шлюзе (например, Oracle9i Application Server 9.0.2), позволяет удаленному противнику выполнить произвольный код, обратившись к URI, для которого сервер возвращает ответ «502 BadGateway». В результате функция dav_lookup_uri() в файле mod_dav.c возвращает спецификаторы форматной строки, которые потом используются при вызове ap_log_rerror().
Из CVE–2003–0095:
Переполнение буфера в программе ORACLE.EXE для Oracle Database Server 9i, 8i, 8.1.7 и 8.0.6 позволяет удаленному противнику выполнить произвольный код, задав при входе длинное имя пользователя. Ошибкой можно воспользоваться из клиентских приложений, самостоятельно выполняющих аутентификацию, что и продемонстрировано на примере LOADPSP.
Из CAN–2003–0096:
Многочисленные ошибки переполнения буфера в Oracle 9i Database Release 2, Release 1, 8i, 8.1.7 и 8.0.6 позволяют удаленному противнику выполнить произвольный код, (1) задав длинную строку преобразования в качестве аргумента функции TO_TIMESTAMP_TZ, (2) задав длинное название часового пояса в качестве аргумента функции TZ_OFFSET и (3) задав длинную строку в качестве аргумента DIRECTORY функции BFILENAME.
Эти ошибки документированы в бюллетене CERT СА–2003–05 по адресу www.cert.org/advisories/CA–2003–05.html. Их – в числе прочих – обнаружил Дэвид Литчфилд со своими сотрудниками из компании Next Generation Security Software Ltd. Попутно отметим, что не стоит объявлять свои приложения «не–взламываемыми», если за дело берется г–н Литчфилд.
CAN–2003–0352
Из описания в CVE:
Переполнение буфера в одном интерфейсе DCOM, используемом в системе RPC, применяемой в Microsoft Windows NT 4.0,2000, ХР и Server 2003, позволяет удаленному противнику выполнить произвольный код, сформировав некорректное сообщение. Этой ошибкой воспользовались черви Blaster/MSblast/LovSAN and Nachi/Welchia.
Это переполнение интересно тем, что привело к широкому распространению двух весьма разрушительных червей, что повлекло за собой глобальные неприятности в сети Интернет. Переполнялся буфер в куче, доказательством возможности эксплуатации ошибки стало появление очень стабильного червя. Ко всему прочему еще был нарушен принцип предоставления наименьших привилегий, этот интерфейс не должен был быть доступен анонимным пользователям. Интересно еще отметить, что предпринятые в Windows 2003 контрмеры свели последствия атаки к отказу от обслуживания вместо эскалации привилегий.
Подробнее об этой проблеме можно прочитать на страницах www.cert.org/ advisories/CA–2003–23.html и www.microsoft.com/technet/security/bulletin/MS03–039.asp.
Искупление греха
Путь к искуплению греха переполнения буфера долог и тернист. Мы обсудим несколько способов избежать этой ошибки, а также ряд приемов, позволяющих сократить ущерб от нее. Посмотрите, как можно улучшить свои программы.
Замена опасных функций работы со строками
Как минимум вы должны заменить небезопасные функции типа strcpy, strcat и sprintf их аналогами со счетчиком. Замену можно выбрать несколькими способами. Имейте в виду, что интерфейс старых вариантов функций со счетчиком оставляет желать лучшего, а кроме того, для задания параметров часто приходится заниматься арифметическими вычислениями. В грехе 3 вы увидите, что компьютеры не так хорошо справляются с математикой, как могло бы показаться. Из новых разработок стоит отметить функцию strsafe, Safe CRT (библиотеку времени исполнения для С), которая войдет в состав Microsoft Visual Studio (и очень скоро станет частью стандарта ANSI C/C++), и функции strlcat/strlcpy для *nix. Обращайте внимание на то, как каждая функция обрабатывает конец строки и усечение. Некоторые функции гарантируют, что строка будет завершаться нулем, но большинство старых функций со счетчиком таких гарантий не дают. Опыт группы разработки Microsoft Office по замене небезопасных функций работы со строками в Office 2003 показал, что коэффициент регресии (число новых ошибок в расчете на одно исправление) очень мал, так что пусть страх внести новые ошибки вас не останавливает.
Следите за выделениями памяти
Еще одна причина переполнения буфера – это арифметические ошибки. Прочитайте в грехе 3 о переполнении целых чисел и найдите в своем коде все места, где для вычисления размера буфера производятся арифметические вычисления.
Проверьте циклы и доступ к массивам
Переполнение возможно и в случае, когда неправильно проверяется условие выхода из цикла и не контролируется выход за границы массива перед записью в него. Это одна из самых трудных для обнаружения ошибок; вы увидите, что часто ошибка проявляется совсем не в том модуле, где была допущена.
Пользуйтесь строками в стиле С++, а не С
Это эффективнее простой замены стандартных С–функций, но может повлечь за собой кардинальную переработку кода, особенно если программа собиралась не компилятором С++. Вы должны хорошо представлять себе характеристики производительности STL–контейнеров. Вполне возможно написать очень эффективный код с использованием STL, но, как всегда, нежелание читать руководство (RTFM – Read The Fine Manual) может привести к коду, далекому от оптимального. Наиболее типичное усовершенствование такого рода – переход к использованию шаблонных классов std::string или std::wstring.
Пользуйтесь STL–контейнерами вместо статических массивов
Все вышеупомянутые проблемы относятся и к STL–контейнерам, например vector, но ситуация осложняется еще и тем, что не все реализации класса vector::iterator контролируют выход за границы контейнера. Указанная в заголовке мера может помочь, и автор полагает, что STL способствует быстрому написанию правильного кода, но имейте в виду, что это все же не панацея.
Пользуйтесь инструментами анализа
На рынке появляются прекрасные инструменты для анализа кода на языках C/C++ на предмет нарушения безопасности, в том числе Coverity, PREfast и Kloc–work. В разделе «Другие ресурсы» приведены ссылки. В состав Visual Studio .NET 2005 войдет программа PREfast и еще один инструмент анализа кода под названием Source code Annotation Language (SAL – язык аннотирования исходного текста), позволяющий обнаружить такие дефекты, как переполнение буфера. Проще всего проиллюстрировать SAL на примере. В показанном ниже фрагменте (примитивном) вы знаете, как соотносятся аргументы data и count: длина data составляет count байтов. Но компилятору об этом ничего не известно, он видит только типы char * and a size_t.
void *DoStuff(char *data, size_t count) {
static char buf[32];
return memcpy(buf, data, count);
}
На первый взгляд, код не содержит ничего плохого (если не считать, что мы возвращаем указатель на статический буфер, ну посмейтесь над нами). Однако если count больше 32, то возникает переполнение буфера. Если бы этот код был аннотирован с помощью SAL, то компилятор мог бы отловить эту ошибку:
void *DoStuff(__in_ecount(count) char *data, size_t count) {
static char buf[32];
return memcpy(buf, data, count);
}
Объясняется это тем, что теперь компилятор и/или PREfast знают о тесной связи аргументов data и count.
Дополнительные защитные меры
Дополнительные защитные меры – это как ремни безопасности в автомобиле. Часто они смягчают последствия столкновения, но в аварию попадать все равно не стоит. Важно понимать, что для всех основных способов минимизировать эффект от переполнения буфера условия, которые приводят к переполнению буфера, продолжают существовать, поэтому достаточно изощренная атака может обойти ваши контрмеры. Все же рассмотрим некоторые подходы.
Защита стека
Защиту стека первым применил Криспин Коуэн в своей программе Stack–guard, затем она была независимо реализована 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/ defeating–w2k3–stack–protection.pdf
□ «Non–stack Based Exploitation of Buffer Overrun Vulnerabilities on Windows NT/2000/ХР» by David Litchfield: www.ngssoftware.com/papers/non–stack–bo–windows.pdf
□ «Blind Exploitation of Stack Overflow Vulnerabilities» by Peter Winter–Smith: 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/cDc–351/
□ Microsoft Security Bulletin MS04–011/Security Update for Microsoft Windows (835732): www.microsoft.com/technet/security/Bulletin/MS04–011 .mspx
□ Microsoft Application Compatibility Analyzer: www.microsoft.com/windows/ appcompatibility/analyzer.mspx
□ Using the Strsafe.h Functions: http://msdn.microsoft.com/library/en–us/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 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) были описаны основные признаки ошибки, но о возможности записывать в память речи не было.