(800) 382-3419

Именно с этой проблемой сталкиваются специалисты, профессионально занимающиеся оценкой безопасности программного обеспечения. Люди все больше заботятся о создании и тестировании безопасных систем, но очень немногие источники рассматривают практику поиска уязвимостей. В конце концов, этот процесс требует глубокого технического понимания весьма сложных вопросов и должен включать системный подход к анализу приложения. Без формального рассмотрения того, как находить уязвимости, индустрия безопасности ПО не имеет способа устанавливать качество оценки безопасности программного обеспечения или обучать этому ремеслу следующее поколение специалистов. Мы написали эту книгу в надежде ответить на эти вопросы и помочь преодолеть разрыв между безопасной разработкой ПО и практическими проверками после реализации. Хотя книга в первую очередь ориентирована на консультантов и других специалистов по безопасности, значительная часть материала будет полезна и остальному ИТ-сообществу. Разработчики смогут лучше понять тонкости и нюансы работы языков и операционных систем, а также то, как эти особенности могут вносить уязвимости в приложение, которое иначе кажется безопасным. Специалисты по обеспечению качества (QA) смогут использовать некоторые рекомендации из этой книги, чтобы поддерживать целостность внутреннего ПО и снижать вероятность того, что их приложения окажутся поражены серьезной уязвимостью. Администраторы найдут полезные ориентиры для оценки влияния приложений на безопасность своих сетей и смогут использовать эти знания для более взвешенных решений о будущих развертываниях. Наконец, энтузиасты, которым просто интересно узнать больше об оценке приложений, найдут в этой книге бесценный ресурс (мы на это надеемся!) для начала работы в области анализа безопасности приложений или развития уже имеющихся навыков.

• Направление UNIX (главы 5 - 10, 13). Этот путь начинается с распространенных классов программных уязвимостей, таких как повреждение памяти, поток управления программой и специально сформатированные данные. Затем рассматриваются проблемы безопасности, ориентированные на UNIX, которые возникают из-за особенностей различных UNIX-подобных операционных систем. Завершается этот путь материалом о синхронизационных уязвимостях, характерных для большинства платформ.

• Направление Windows (главы 5 - 8, 11 - 13). Этот путь начинается примерно так же, как UNIX-направление, с платформенно-нейтральных проблем безопасности. Затем две главы специально рассматривают API Windows и связанные с ними уязвимости. Наконец, путь завершается распространенными синхронизационными уязвимостями.

• Веб-направление (главы 8, 13, 17, 18). Аудит веб-приложений требует понимания распространенных уязвимостей безопасности, а также веб-фреймворков и языков. Это направление рассматривает распространенные классы уязвимостей, относящиеся к веб-языкам, и завершается главами, посвященными собственно вебу. Хотя главы о UNIX и Windows здесь не перечислены, их чтение может быть необходимо в зависимости от среды развертывания веб-приложения.

• Направление сетевых приложений (главы 5 - 8, 13, 16). Эта последовательность глав лучше всего подходит для типов уязвимостей, с которыми вы, вероятно, столкнетесь в сетевых клиент-серверных приложениях. Обратите внимание: хотя глава 16 ориентирована на отдельные прикладные протоколы, в ней есть раздел с общими методами аудита прикладных протоколов. Как и в предыдущем направлении, главы о UNIX или Windows также могут оказаться уместными в зависимости от среды развертывания.

• Направление сетевого анализа (главы 5 - 8, 13 - 16). Это направление предназначено для анализа приложений сетевого анализа, таких как межсетевые экраны, IPS, снифферы, маршрутизирующее ПО и тому подобные системы. Материал включает стандартные классы уязвимостей, популярные сетевые технологии и распространенные уязвимости в таких продуктах. И снова главы о UNIX и Windows будут хорошим дополнением к этому направлению, если они применимы.

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

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

Уязвимости

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

Вы, несомненно, знакомы с программными ошибками; это ошибки, просчеты или недосмотры в программах, приводящие к неожиданному и обычно нежелательному поведению. Почти каждый пользователь компьютера терял важную работу из-за программной ошибки. В общем случае программные уязвимости можно рассматривать как подмножество более широкого явления программных ошибок. Уязвимости безопасности -- это ошибки с дополнительным скрытым сюрпризом: злоумышленник может использовать их для атак на программу и поддерживающие ее системы. Почти все уязвимости безопасности являются программными ошибками, но лишь некоторые программные ошибки оказываются уязвимостями безопасности. Чтобы ошибка считалась проблемой безопасности, она должна иметь какое-то значимое для безопасности воздействие или свойства; другими словами, она должна позволять атакующим делать то, что в норме они делать не могли бы. (Мы вернемся к этой теме в следующих главах, потому что распространенная ошибка -- ошибочно считать серьезный дефект безопасности безобидной программной ошибкой.)

Есть распространенное высказывание: безопасность -- это подмножество надежности. Как универсальная истина оно может не выдержать проверки, но полезное сравнение провести позволяет. Надежная программа -- это программа, относительно свободная от программных ошибок: она редко отказывает пользователям и корректно обрабатывает исключительные условия. Она написана "защитно", так что способна справляться с неопределенной средой выполнения и некорректными входными данными. Безопасная программа похожа на устойчивую программу: она способна отразить целенаправленную атаку нарушителей, которые пытаются манипулировать ее окружением и входными данными, чтобы использовать ее для какой-то вредоносной цели. Безопасность и надежность программного обеспечения также имеют сходные цели, поскольку обе требуют стратегий разработки, сосредоточенных на искоренении программных ошибок.

Примечание

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

Процесс атаки на уязвимость в программе называется эксплуатацией. Атакующие могут эксплуатировать уязвимость, хитрым образом запуская программу, изменяя или наблюдая ее окружение во время выполнения либо, если программа небезопасна по своей природе, просто используя ее по прямому назначению. Когда атакующие применяют внешнюю программу или сценарий для проведения атаки, такую атакующую программу часто называют эксплойтом или эксплойт-скриптом.

Политики безопасности

Как уже говорилось, атакующие могут эксплуатировать уязвимость, чтобы нарушить безопасность системы. Один полезный способ осмыслить "безопасность системы" -- считать, что безопасность системы определяется политикой безопасности. С этой точки зрения нарушение безопасности программной системы происходит тогда, когда нарушается политика безопасности этой системы.

Примечание

Мэтт Бишоп, профессор компьютерных наук в Калифорнийском университете в Дейвисе, -- признанный исследователь безопасности, который много лет изучает компьютерные уязвимости. Нет нужды говорить, что он много размышлял о компьютерной безопасности как с формальной академической, так и с технической точки зрения. Если эти темы вам интересны, обратитесь к его книге Computer Security: Art and Science (Addison-Wesley, 2003) и к материалам на его домашней странице: http://nob.cs.ucdavis.edu/~bishop/.

Для системы, состоящей из программного обеспечения, пользователей и ресурсов, существует политика безопасности -- попросту список того, что разрешено, и того, что запрещено. Например, такая политика может утверждать: "Неаутентифицированным пользователям запрещено использовать календарный сервис на тестовой машине". Проблема, позволяющая неаутентифицированным пользователям получить доступ к календарному сервису тестовой машины, явно нарушала бы политику безопасности.

Можно считать, что каждая программная система имеет политику безопасности. Это может быть формальная политика в виде письменных документов, а может быть неформальный, свободный набор ожиданий пользователей о том, какое поведение для этой системы является разумным. Для большинства программных систем люди обычно понимают, какое поведение представляет собой нарушение безопасности, даже если это не было явно сформулировано. Поэтому термин "политика безопасности" часто означает консенсус пользовательского сообщества о том, какое поведение системы разрешено, а какое запрещено. Такая политика может принимать несколько разных форм, описанных ниже:

• Для особенно чувствительной и строго ограниченной системы политика безопасности может быть формальной спецификацией ограничений, которые можно проверить относительно программного кода с помощью математического доказательства. Такой подход часто дорог и применим только к крайне контролируемой программной среде. Хотелось бы надеяться, что встроенные системы в таких устройствах, как светофоры, лифты, самолеты и аппаратура жизнеобеспечения, проходят такого рода проверку. К сожалению, этот подход оказывается чрезмерно дорогим или громоздким даже для многих подобных применений.

• Политика безопасности может быть формальным письменным документом с пунктами вроде: "C.2. Информация о кредитных картах (A.1.13) никогда не должна раскрываться третьей стороне (как определено в A.1.3) или передаваться по любым каналам связи без достаточного шифрования, указанного в приложении Q". Такой пункт мог бы быть взят из политики, написанной о программном обеспечении, возможно созданной в процессе разработки. Он также мог бы происходить из политик, связанных с ресурсами, которые использует программа, например из политики безопасности площадки, политики операционной системы (OS) или политики безопасности базы данных.

• Политика безопасности может состоять исключительно из неформального, слегка неоднозначного набора ожиданий людей относительно разумного поведения безопасности программы, например: "Да, дать преступной организации доступ к нашей базе данных кредитных карт, пожалуй, плохо".

Виртуальная машина Java (JVM) и .NET Common Language Runtime (CLR) в разной степени поддерживают безопасность доступа к коду (code access security, CAS). CAS дает возможность глубоко проверять пакет как при загрузке, так и во время выполнения. Эти проверки включают целостность байткода, происхождение программы и применение ограничений доступа к коду. Самые очевидные применения этих технологий -- песочницы для Java-апплетов и управляемых браузерных элементов .NET.

Хотя CAS можно использовать как платформу для строго формализованной модели безопасности, с ним связано несколько важных оговорок. Первая проблема в том, что большинство разработчиков не до конца понимает его применение и работу, поэтому в коммерческом ПО он используется редко. Вторая проблема в том, что безопасность, обеспечиваемая CAS, полностью зависит от безопасности нижележащих компонентов. И Java VM, и .NET CLR становились жертвами уязвимостей, которые могли позволить приложению выйти из песочницы виртуальной машины и выполнить произвольный код.

На практике политика безопасности программной системы, скорее всего, в основном неформальна и складывается из ожиданий людей. Однако она часто заимствует элементы из формальной документации процесса разработки и ссылается на политики безопасности площадки и ресурсов. Такое определение политики безопасности системы помогает прояснить понятие "безопасность системы". Суть в том, что безопасность находится в глазах смотрящего и в конечном счете сводится к требованиям и ожиданиям конечных пользователей.

Ожидания безопасности

Рассмотрение возможных ожиданий людей относительно безопасности программного обеспечения помогает определить, какие проблемы они сочтут нарушениями безопасности. Безопасность часто описывают как опирающуюся на три компонента: конфиденциальность, целостность и доступность. В следующих разделах возможные ожидания к безопасности ПО рассматриваются с точки зрения этих краеугольных камней.

Конфиденциальность

Конфиденциальность требует, чтобы информация оставалась закрытой. Сюда входит любая ситуация, в которой от программы ожидают сокрытия информации или даже сокрытия самого факта существования информации. Программные системы часто работают с данными, содержащими секреты: от разведывательных секретов государственного или регионального уровня до коммерческих тайн компаний и чувствительной персональной информации.

В программном обеспечении компаний и других организаций хранится множество секретов. Финансовая информация обычно должна оставаться конфиденциальной. Информация о планах и результатах деятельности может иметь стратегическое значение и потенциально полезна для незаконного конкурентного преимущества или преступной деятельности, например инсайдерской торговли. Поэтому бизнес также ожидает, что такие данные будут сохраняться в тайне. Данные, связанные с деловыми отношениями, контрактами, судебными процессами или любым другим чувствительным содержимым, несут ожидание конфиденциальности.

Если программная система хранит информацию о людях, ожидания конфиденциальности таких данных часто высоки. Из-за вопросов приватности организации и пользователи ожидают, что программная система будет тщательно контролировать, кто может просматривать сведения, относящиеся к людям. Если информация содержит финансовые данные или медицинские записи, неправомерное раскрытие данных может повлечь вопросы ответственности. От программ часто ожидают сохранения в тайне личной пользовательской информации: личных файлов, электронной почты, истории активности, учетных записей и паролей.

Во многих видах программного обеспечения секретом является сам программный код. Это может быть коммерческая тайна, например код для оценки потенциальной сделки на товарном рынке или новый 3D-графический движок. Даже если это не коммерческая тайна, код все равно может быть чувствительным, например код оценки кредитных рисков потенциальных заемщиков или алгоритм, лежащий в основе боевой системы онлайн-игры.

От программного обеспечения часто ожидают разделения информации на отсеки и гарантии того, что только аутентифицированные стороны смогут видеть информацию, на просмотр которой они уполномочены. Эти требования означают, что от программ часто ожидают использования технологий контроля доступа для аутентификации пользователей и проверки их полномочий при обращении к данным. Шифрование также используется для сохранения конфиденциальности данных при передаче или хранении.

Целостность

Целостность -- это достоверность и правильность данных. Она относится к ожиданиям людей относительно способности программного обеспечения предотвращать изменение данных. Целостность касается не только содержимого данных, но и источника этих данных. Программа может поддерживать целостность, предотвращая несанкционированные изменения источников данных. Другая программа может обнаруживать изменения целостности данных, фиксируя изменение некоторого фрагмента данных или изменение происхождения данных.

Целостность программного обеспечения часто включает разделение информации на отсеки, при котором программа использует технологии контроля доступа для аутентификации пользователей и проверки их полномочий до того, как им разрешается изменять данные. Аутентификация также является важным компонентом программ, от которых ожидают сохранения целостности источника данных, потому что она однозначно сообщает программе, кто является пользователем.

Обычно пользователи предъявляют к целостности ожидания, похожие на ожидания конфиденциальности. Любая проблема, позволяющая атакующим изменять информацию, которую им в иных условиях не разрешено изменять, считается дефектом безопасности. Любая проблема, позволяющая пользователям выдавать себя за других пользователей и манипулировать данными, также считается нарушением целостности данных.

Программные уязвимости могут быть особенно разрушительными при нарушениях целостности, поскольку изменение данных часто можно использовать для дальнейшего расширения доступа атакующих к программной системе и вычислительным ресурсам, на которых она размещена.

Доступность

Доступность -- это возможность использовать информацию и ресурсы. В общем случае она относится к ожиданиям пользователей относительно доступности системы и ее устойчивости к атакам типа "отказ в обслуживании" (denial-of-service, DoS).

Проблема, позволяющая пользователям легко вызвать аварийное завершение или нарушить работу программы, скорее всего, будет считаться уязвимостью, нарушающей ожидания пользователей в отношении доступности. Обычно сюда входят атаки, использующие специальные входные данные или нарушения окружения для отключения программы, а также атаки, сосредоточенные на исчерпании ресурсов программной системы, таких как процессорное время, дисковое пространство или пропускная способность сети.

Необходимость аудита

Большинство людей ожидает, что поставщики дают некоторую степень уверенности в целостности своего программного обеспечения. Печальная правда в том, что поставщики дают мало гарантий качества для какого бы то ни было ПО. Если сомневаетесь, просто прочитайте лицензионное соглашение конечного пользователя (EULA), сопровождающее почти каждую коммерческую программу. Однако компаниям выгодно сохранять клиентов довольными, поэтому большинство поставщиков внедряет собственные меры обеспечения качества. Эти меры обычно сосредоточены на вещах, которые легко продать рынку: функциях, доступности и общей стабильности; исторически такой фокус приводил к тому, что безопасность применялась бессистемно или иногда полностью игнорировалась.

Примечание

Некоторые отрасли действительно вводят собственные требования и стандарты безопасности, но обычно они связаны с регуляторными интересами и применяются только к отдельным специализированным средам и приложениям. Однако эта практика меняется: громкие инциденты подталкивают регуляторов и органы стандартизации отрасли к более проактивным требованиям безопасности.

Хорошая новость в том, что в последнее время отношение к безопасности меняется, и многие поставщики внедряют бизнес-процессы для более строгого тестирования безопасности. Все более обычными становятся разные подходы, включая автоматизированный анализ кода, модульное тестирование безопасности и ручной аудит кода. Как видно из названия, эта книга посвящена ручному аудиту кода.

Аудит приложения -- это процесс анализа кода приложения (в исходной или бинарной форме) для выявления уязвимостей, которые могут эксплуатировать атакующие. Проходя через этот процесс, можно находить и закрывать дыры в безопасности, которые иначе подвергали бы чувствительные данные и бизнес-ресурсы ненужному риску.

Помимо очевидного случая, когда компания разрабатывает внутреннее программное обеспечение, аудит кода имеет смысл и в нескольких других ситуациях. Таблица 1-1 суммирует самые распространенные из них.

Таблица 1-1. Ситуации, в которых нужен аудит кода

Как видно, аудит кода имеет смысл в довольно многих ситуациях. Однако, несмотря на спрос на людей с такими навыками, немногие специалисты обладают подготовкой и опытом, необходимыми для выполнения таких аудитов на высоком уровне. Мы надеемся, что эта книга поможет закрыть этот пробел.

Аудит и тестирование черного ящика

Тестирование черного ящика -- это метод оценки программной системы путем манипулирования только ее открытыми интерфейсами. Обычно этот процесс включает генерацию специально подготовленных входных данных, которые с большой вероятностью заставят приложение выполнить что-то неожиданное, например аварийно завершиться или раскрыть чувствительные данные. Например, тестирование HTTP-сервера методом черного ящика может включать отправку запросов с аномально большими размерами полей, что может вызвать ошибку повреждения памяти (подробнее она рассматривается далее в главе 5, "Повреждение памяти"). Такой тест может включать корректный запрос, например следующий (предположим, что последовательность "..." представляет гораздо более длинную серию символов "A"):

GET AAAAAAAAAAAAAAAAAAA...AAAAAAAAAAAAAAAAAAA HTTP/1.0

Или он может включать некорректный запрос, например такой (снова последовательность "..." представляет гораздо более длинную серию символов "A"):

GET / AAAAAAAAAAAAAAAAAAA...AAAAAAAAAAAAAAAAAAAA/1.0

Любое аварийное завершение, вызванное такими запросами, указывало бы на довольно серьезную ошибку в приложении. Этот подход становится еще привлекательнее, если учесть, что существуют инструменты для автоматизации процесса тестирования приложений. Такой процесс автоматизированного тестирования черного ящика называется fuzz-testing, а fuzzing-инструменты включают универсальные "глупые" фаззеры и "интеллектуальные" фаззеры, понимающие протокол. Поэтому не нужно вручную пробовать каждый случай, который приходит в голову; достаточно запустить инструмент, возможно с некоторыми собственными модификациями, и собрать результаты.

Преимущество тестирования приложения методом черного ящика в том, что его можно провести быстро и, возможно, почти сразу получить результаты. Однако не все так хорошо; у тестирования черного ящика есть несколько важных недостатков. По сути, оно сводится к тому, что вы бросаете в приложение кучу данных и надеетесь, что оно сделает что-то, чего делать не должно. Вы действительно не знаете, что приложение делает с этими данными, поэтому потенциально существуют сотни путей выполнения кода, которые вы не исследовали, потому что данные, отправленные приложению, эти пути не запускают. Например, возвращаясь к примеру с веб-сервером, представьте, что у него есть определенная внутренняя функциональность, если в строке запроса присутствуют определенные ключевые слова. Посмотрите на следующий фрагмент кода, обращая особое внимание на выделенные строки:

У этого веб-сервера есть специализированное нестандартное поведение: если строка запроса содержит последовательность mode=xxx, переменная окружения MODE устанавливается в значение xxx. Однако в этом специализированном поведении есть дефект реализации: переполнение буфера, вызванное неосторожным использованием функции sprintf(). Если вы не уверены, почему этот код опасен, не волнуйтесь: уязвимости переполнения буфера подробно рассматриваются в главе 5.

Эту ошибку можно увидеть сразу, изучив код, но инструмент черного ящика или fuzz-testing, вероятно, пропустил бы эту базовую уязвимость. Поэтому помимо простого запуска тестовых инструментов и фиксации результатов нужно уметь осмысленно оценивать конструкции кода. Именно поэтому важен аудит кода. Нужно уметь анализировать код и обнаруживать пути выполнения, которые автоматизированный инструмент может пропустить, а также находить уязвимости, которые автоматизированные инструменты поймать не способны.

К счастью, аудит кода в сочетании с тестированием черного ящика дает максимальные результаты в выявлении уязвимостей за минимальное время. Эта книга вооружает вас знаниями и приемами для тщательного анализа приложения на широкий спектр уязвимостей и дает понимание того, как использовать собственное понимание и творческий подход для обнаружения дефектов, уникальных для конкретного приложения.

Аудит кода и жизненный цикл разработки

Когда вы учитываете риски раскрытия приложения потенциально злонамеренным пользователям, ценность оценки безопасности приложения становится очевидной. Однако нужно точно знать, когда выполнять оценку. В общем случае аудит можно проводить на любом этапе жизненного цикла разработки систем (Systems Development Life Cycle, SDLC). Однако стоимость выявления и исправления уязвимостей может сильно различаться в зависимости от того, когда и как вы решите проводить аудит. Поэтому прежде чем начинать, рассмотрите следующие фазы SDLC:

1. Технико-экономическое обоснование. Эта фаза связана с выявлением потребностей, которым должен отвечать проект, и с определением того, является ли разработка решения технологически и финансово осуществимой.

2. Определение требований. На этой фазе проводится более глубокое изучение требований к проекту и устанавливаются цели проекта.

3. Проектирование. Решение проектируется, и принимаются решения о том, как система технически будет выполнять согласованные требования.

4. Реализация. Код приложения разрабатывается в соответствии с проектом, созданным на предыдущей фазе.

5. Интеграция и тестирование. Решение проходит некоторый уровень обеспечения качества, чтобы убедиться, что оно работает ожидаемым образом, и выявить ошибки в программном обеспечении.

6. Эксплуатация и сопровождение. Решение развернуто и уже используется; изменения, обновления и исправления вносятся в результате обратной связи от пользователей.

Любой процесс разработки программного обеспечения в той или иной степени следует этой модели. Классические модели водопада склонны к строгой интерпретации, при которой жизненный путь системы проходит через эту модель только один раз. Напротив, более новые методологии, например гибкая разработка, обычно сосредоточены на уточнении приложения через повторяющиеся итерации фаз SDLC. Поэтому способ применения модели SDLC может различаться, но базовые понятия и фазы достаточно согласованы для целей этого обсуждения. Эти различия можно использовать для классификации уязвимостей, а в следующих главах вы узнаете, на каких фазах лучше проводить разные классы проверок.

Классификация уязвимостей

Класс уязвимостей -- это набор уязвимостей, имеющих некоторую объединяющую общность: шаблон или концепцию, которая выделяет конкретную особенность, общую для нескольких разных программных дефектов. Конечно, такое определение может показаться немного запутанным, но суть в том, что классы уязвимостей -- это всего лишь мысленные инструменты для осмысления программных дефектов. Они полезны для понимания проблем и передачи этого понимания другим, но единой чистой таксономии для группировки уязвимостей в точные, непересекающиеся классы не существует. Одна уязвимость вполне может попадать в несколько классов, в зависимости от терминологии аудитора кода, системы классификации и точки зрения.

В этой книге не используется жесткая формальная таксономия для категоризации уязвимостей; вместо этого проблемы классифицируются последовательным и прагматичным образом, удобным для изложения материала. К некоторым программным уязвимостям лучше подходить с определенной точки зрения. Например, одни дефекты удобнее рассматривать, думая о программе как о взаимодействии высокоуровневых программных компонентов; другой тип дефектов удобнее понимать, представляя программу как последовательность системных вызовов. Независимо от подхода эта книга объясняет термины и понятия, которые вы встретите в литературе по безопасности, чтобы множество терминов и таксономий, используемых сообществом безопасности, оставалось для вас в некотором контексте.

При определении общих классов уязвимостей можно провести несколько общих разграничений, опираясь на обсуждение фаз SDLC. Два широко принятых класса уязвимостей включают уязвимости проектирования (фазы SDLC 1, 2 и 3) и уязвимости реализации (фазы SDLC 4 и 5). Кроме того, эта книга включает третью категорию: эксплуатационные уязвимости (фаза SDLC 6). Сообщество безопасности обычно признает уязвимости проектирования как дефекты в архитектуре и спецификациях программной системы; уязвимости реализации -- как низкоуровневые технические дефекты в фактическом построении программной системы. Категория эксплуатационных уязвимостей охватывает дефекты, возникающие при развертывании и настройке программного обеспечения в конкретной среде.

Уязвимости проектирования

Уязвимость проектирования -- это проблема, возникающая из фундаментальной ошибки или недосмотра в проекте программы. При дефекте проектирования программа небезопасна потому, что делает именно то, для чего была спроектирована; просто ее спроектировали так, чтобы она делала неправильную вещь! Такие дефекты часто возникают из-за предположений о среде, в которой программа будет работать, или о риске воздействия, которому компоненты программы подвергнутся в реальной производственной среде. Дефекты проектирования также называют высокоуровневыми уязвимостями, архитектурными дефектами или проблемами требований либо ограничений программы.

Быстрый взгляд на фазы SDLC напоминает, что проект программной системы определяется программными требованиями -- списком целей, которым система должна соответствовать, чтобы выполнить задачи своих создателей. Обычно инженер берет набор требований и строит проектные спецификации, сосредоточенные на том, как создать программу, удовлетворяющую этим целям. Требования обычно описывают, что программная система должна делать, например: "Позволить пользователю получить файл транзакций с сервера". Требования также могут задавать возможности, которыми программа должна обладать, например: "Она должна поддерживать 100 одновременных загрузок в час".

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

Когда люди говорят о дефекте проектирования, они обычно не проводят различия между проблемой требований к программе и проблемой спецификаций программы. Провести такое различие часто непросто, потому что многие высокоуровневые проблемы можно объяснить как недосмотр в требованиях или как ошибку в спецификациях.

Например, протокол TELNET спроектирован так, чтобы позволять пользователям подключаться к удаленной машине и работать с ней так, будто она подключена к локальному терминалу. С точки зрения проектирования у TELNET, пожалуй, есть уязвимость: он полагается на незашифрованную связь. В некоторых средах такая зависимость может быть приемлемой, если нижележащая сетевая среда считается доверенной. Однако в корпоративных сетях и Интернете незашифрованные коммуникации могут быть серьезной слабостью, потому что атакующие, находящиеся на маршруте передачи, могут наблюдать и перехватывать TELNET-сеансы. Если администратор подключается к маршрутизатору через TELNET и вводит имя пользователя и пароль для входа, сниффер может записать эти учетные данные администратора. В отличие от этого, протокол Secure Shell (SSH) служит той же базовой цели, что и TELNET, но устраняет угрозу прослушивания, потому что шифрует все коммуникации.

Уязвимости реализации

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

Эта книга включает много примеров уязвимостей реализации, потому что выявление таких технических дефектов -- одна из основных задач процесса анализа кода. Уязвимости реализации охватывают несколько широко известных классов уязвимостей, о которых вы, вероятно, слышали, например переполнение буфера и SQL-инъекцию.

Возвращаясь к примеру TELNET, уязвимости реализации можно найти и в конкретных версиях программ TELNET. Некоторые прежние реализации TELNET-демонов некорректно очищали переменные окружения пользователей, позволяя нарушителям использовать возможности динамической компоновки UNIX-машины для повышения своих привилегий на этой машине. Также существовали дефекты, позволявшие нарушителям выполнять переполнение буфера и атаки форматной строки против различных версий TELNET-демонов, часто вообще без аутентификации. Эти дефекты приводили к тому, что атакующие могли удаленно отдавать произвольные команды на машине от имени привилегированных пользователей. По сути, атакующие могли запустить небольшую программу-эксплойт против уязвимого TELNET-демона и сразу получить root-приглашение на сервере.

Эксплуатационные уязвимости

Эксплуатационные уязвимости -- это проблемы безопасности, возникающие из эксплуатационных процедур и общего использования программы в конкретной среде. Один способ отличить такие уязвимости состоит в том, что они не присутствуют в исходном коде рассматриваемой программы; скорее, они коренятся в том, как программа взаимодействует со своей средой. В частности, они могут включать проблемы настройки программы в ее среде, проблемы настройки поддерживающего программного обеспечения и компьютеров, а также проблемы, вызванные автоматизированными и ручными процессами вокруг системы. Эксплуатационные уязвимости могут включать даже некоторые типы атак на пользователей системы, например социальную инженерию и кражу. Эти проблемы возникают на фазе эксплуатации и сопровождения SDLC, хотя частично пересекаются с фазой интеграции и тестирования.

Возвращаясь к примеру TELNET, вы знаете, что у TELNET есть дефект проектирования из-за отсутствия шифрования. Допустим, вы рассматриваете программную систему для автоматической торговли ценными бумагами. Предположим, ей нужно каждую ночь обновлять набор весовых значений, чтобы корректировать торговую стратегию на следующий день. Документированная процедура обновления этих данных состоит в том, что администратор в конце каждого рабочего дня входит на машину с использованием TELNET и вводит новый набор значений через простую служебную программу. В зависимости от среды такая процедура может представлять серьезную эксплуатационную уязвимость из-за множества рисков, связанных с использованием TELNET, включая прослушивание и перехват соединения. Короче говоря, эксплуатационная процедура сопровождения программы дефектна, потому что подвергает систему потенциальному мошенничеству и атакам.

Серые зоны

Разграничение между уязвимостями проектирования и реализации обманчиво просто в терминах SDLC, но провести его не всегда легко. Многие уязвимости реализации можно также истолковать как ситуации, в которых проект не предвидел проблему или не учел ее должным образом. С другой стороны, можно утверждать, что низкоуровневые части программной системы тоже в каком-то смысле проектируются. Программист может проектировать множество программных компонентов при реализации спецификации, в зависимости от уровня подробности спецификации. Эти компоненты могут включать класс, функцию, сетевой протокол, виртуальную машину или, возможно, хитрую последовательность циклов и ветвлений. При отсутствии строгого различия в этой книге используется следующее определение уязвимости проектирования:

В общем случае, когда люди говорят об уязвимостях проектирования, они имеют в виду высокоуровневые проблемы архитектуры программы, требований, базовых интерфейсов и ключевых алгоритмов.

Расширяя определение уязвимостей проектирования, эта книга использует следующее определение уязвимости реализации:

Проблемы безопасности в проектировании низкоуровневых частей программы, таких как части отдельных функций и классов, обычно считаются уязвимостями реализации. Уязвимости реализации также включают более сложные логические элементы, которые обычно не рассматриваются в проектной спецификации. (Такие проблемы часто называют логическими уязвимостями.)

Аналогично, нет четкого различия между эксплуатационными уязвимостями и уязвимостями реализации или проектирования. Например, если программа устанавливается в среде небезопасным образом, легко можно утверждать, что это отказ проектирования или реализации. От приложения можно было бы ожидать разработки таким образом, чтобы оно не было уязвимо к подобным проблемам среды. При отсутствии строгого различия в этой книге используется следующее определение эксплуатационной уязвимости:

В общем случае ярлык "эксплуатационные уязвимости" используется для проблем, связанных с небезопасным развертыванием и настройкой программного обеспечения, ненадежными практиками управления и администрирования вокруг программы, проблемами поддерживающих компонентов, таких как серверы приложений и веб-серверы, а также прямыми атаками на пользователей программы.

Как видите, в понятиях уязвимостей проектирования, реализации и эксплуатации достаточно места для интерпретации и пересечения, поэтому не считайте эти определения безошибочной формальной системой для маркировки программных дефектов. Это просто полезный способ подходить к программным уязвимостям и изучать их.

Общие нити

До этого момента вы познакомились с некоторым контекстом процесса аудита, моделями безопасности и тремя распространенными классами уязвимостей. Эта линия обсуждения продолжается на протяжении всей остальной книги, по мере того как вы будете углубляться в детали конкретных технических проблем. А пока сделайте шаг назад и посмотрите на несколько общих нитей, лежащих в основе уязвимостей безопасности в программном обеспечении, сосредоточившись прежде всего на том, где и почему уязвимости наиболее вероятно проявляются в программе.

Ввод и поток данных

Большинство программных уязвимостей возникает из неожиданного поведения, вызванного реакцией программы на вредоносные данные. Поэтому первый вопрос, который нужно рассмотреть: как именно вредоносные данные принимаются системой и вызывают столь серьезное воздействие. Лучше всего объяснить это, начав с простого примера уязвимости переполнения буфера.

Рассмотрим UNIX-программу, содержащую переполнение буфера, которое запускается чрезмерно длинным аргументом командной строки. В этом случае вредоносные данные -- это пользовательский ввод, поступающий напрямую от атакующего через интерфейс командной строки. Эти данные проходят через программу, пока какая-то функция не использует их небезопасным образом, приводя к эксплуатируемой ситуации.

Для большинства уязвимостей вы найдете некоторый фрагмент вредоносных данных, который атакующий внедряет в систему для запуска эксплойта. Однако эти вредоносные данные могут вступить в игру гораздо более окольным путем, чем прямой пользовательский ввод. Данные могут поступать из нескольких разных источников и через несколько разных интерфейсов. Они также могут проходить через несколько компонентов системы и сильно изменяться, прежде чем достигнут места, где в конечном итоге вызовут эксплуатируемое состояние. Следовательно, при анализе программной системы один из самых полезных аспектов, который стоит рассматривать, -- это поток данных через различные компоненты системы.

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

Чтобы эксплуатировать эту уязвимость, вам пришлось бы создать новую встречу с описанием длиннее 1000 символов, а затем заставить приложение запланировать встречу. После этого нужно было бы дождаться создания ежемесячного отчета, чтобы увидеть, сработал ли эксплойт. Ваши вредоносные данные должны были бы пройти через несколько компонентов системы и пережить сохранение в базе данных, все это время избегая обнаружения другим пользователем системы. Соответственно, как проверяющий безопасность вы должны оценить осуществимость этого вектора атаки. Такая точка зрения предполагает анализ потока описания встречи от первоначального создания через несколько компонентов приложения и, наконец, до его использования в уязвимом коде генерации отчета.

Этот процесс трассировки потока данных является центральным как для анализа проектирования, так и для анализа реализации программного обеспечения. Данные, изменяемые пользователем, представляют серьезную угрозу для системы, а трассировка сквозного потока данных -- основной способ оценить эту угрозу. Обычно нужно определить, где данные, изменяемые пользователем, входят в систему через интерфейс к внешнему миру, например командную строку или веб-запрос. Затем вы изучаете разные способы, которыми такие данные могут перемещаться по системе, одновременно ища любой потенциально эксплуатируемый код, действующий на эти данные. Вероятно, данные пройдут через несколько компонентов программной системы и будут проверяться и изменяться в нескольких точках на протяжении своего жизненного цикла.

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

Отношения доверия

Разные компоненты программной системы в разной степени доверяют друг другу, и при анализе безопасности конкретной программной системы важно понимать эти отношения доверия. Отношения доверия неотделимы от потока данных, поскольку уровень доверия между компонентами часто определяет объем проверки, выполняемой над данными, которыми они обмениваются.

Проектировщики и разработчики часто считают интерфейс между двумя компонентами доверенным или назначают одноранговый либо поддерживающий программный компонент доверенным. Это означает, что они обычно полагают, будто доверенный компонент невосприимчив к вредоносному вмешательству, и чувствуют себя вправе делать предположения о данных и поведении этого компонента. Естественно, если это доверие ошибочно, а атакующий может получить доступ к доверенным сущностям или манипулировать ими, безопасность системы может посыпаться как домино.

Кстати о домино: при оценке отношений доверия в системе важно учитывать транзитивную природу доверия. Например, если ваша программная система доверяет определенному внешнему компоненту, а этот компонент, в свою очередь, доверяет определенной сети, ваша система косвенно доверилась этой сети. Если доверие компонента к сети плохо обосновано, он может стать жертвой атаки, которая в итоге поставит под угрозу ваше программное обеспечение.

Предположения и misplaced trust

Еще один полезный способ смотреть на программные дефекты -- думать о них как о следствии необоснованных предположений, которые программисты и проектировщики делают при создании ПО. Разработчики могут делать неверные предположения о многих аспектах программы, включая корректность и формат входящих данных, безопасность поддерживающих программ, потенциальную враждебность среды, возможности атакующих и пользователей и даже поведение и нюансы конкретных вызовов интерфейса прикладного программирования (API) или особенностей языка.

Концепция неуместных предположений тесно связана с концепцией misplaced trust -- ошибочно размещенного доверия, потому что чрезмерное доверие компоненту во многом равно необоснованному предположению об этом компоненте. В следующих разделах рассматривается несколько способов, которыми разработчики могут совершать ошибки, значимые для безопасности, делая необоснованные предположения и распространяя незаслуженное доверие.

Ввод

Как говорилось ранее, большинство программных уязвимостей запускается тем, что атакующие внедряют вредоносные данные в программные системы. Одна причина, по которой эти данные могут создавать такие проблемы, состоит в том, что программы часто слишком сильно доверяют своим коммуникационным партнерам и делают предположения о возможном происхождении и содержимом данных.

В частности, когда разработчики пишут код для обработки данных, они часто делают предположения о пользователе или программном компоненте, предоставляющем эти данные. При обработке пользовательского ввода разработчики часто предполагают, что пользователи вряд ли станут делать такие вещи, как ввод адреса улицы длиной 5000 символов, содержащего непечатаемые символы. Аналогично, если разработчики пишут код для программного интерфейса между двумя программными компонентами, они обычно делают предположения о том, что входные данные хорошо сформированы. Например, они могут не предусмотреть, что программа поместит в файл бинарную запись с отрицательной длиной или отправит сетевой запрос длиной четыре миллиарда байт.

В отличие от этого, атакующие, рассматривающие код обработки ввода, стараются учитывать любой возможный ввод, который можно подать, включая любой ввод, способный привести к несогласованному или неожиданному состоянию программы. Атакующие стараются исследовать каждый доступный интерфейс программы и специально ищут любые предположения, сделанные разработчиком. Для атакующего любая возможность предоставить неожиданный ввод -- золото, потому что такой ввод часто оказывает тонкое влияние на дальнейшую обработку, которого разработчики не ожидали. В общем случае, если вы можете внести непредвиденное изменение в свойства программы во время выполнения, вы часто можете найти способ использовать это для большего влияния на программу.

Интерфейсы

Интерфейсы -- это механизмы, с помощью которых программные компоненты взаимодействуют друг с другом и с внешним миром. Многие уязвимости вызваны тем, что разработчики не полностью понимают свойства безопасности этих интерфейсов и вследствие этого предполагают, что пользоваться ими могут только доверенные участники. Если программный компонент доступен по сети или через различные механизмы на локальной машине, атакующие могут получить возможность подключиться к этому компоненту напрямую и ввести вредоносные данные. Если компонент написан так, что предполагает доверенность своего партнера, приложение, вероятно, обработает ввод неправильно и эксплуатируемым образом.

Еще серьезнее эту уязвимость делает то, что разработчики часто неверно оценивают сложность доступа атакующего к интерфейсу и потому доверяют интерфейсу без достаточных оснований. Например, разработчики могут ожидать высокой степени безопасности, потому что использовали проприетарный и сложный сетевой протокол с нестандартным шифрованием. Они могут ошибочно предположить, что атакующие вряд ли создадут собственные клиенты и слои шифрования, а затем будут манипулировать протоколом неожиданными способами. К сожалению, такое предположение особенно ненадежно, поскольку многие атакующие испытывают особую радость от обратной разработки проприетарного протокола.

Подводя итог, разработчики могут ошибочно довериться интерфейсу по следующим причинам:

• Они выбирают способ раскрытия интерфейса, который не обеспечивает достаточной защиты от внешних атакующих.

• Они выбирают надежный способ раскрытия интерфейса, обычно сервис операционной системы, но используют или настраивают его неправильно. Атакующий также может эксплуатировать уязвимость базовой платформы, чтобы получить неожиданный контроль над этим интерфейсом.

• Они предполагают, что интерфейс слишком труднодоступен для атакующего, а это обычно опасная ставка.

Атаки через окружение

Программные системы не работают в вакууме. Они работают как одна или несколько программ, поддерживаемых более широкой вычислительной средой, которая обычно включает такие компоненты, как операционные системы, аппаратные архитектуры, сети, файловые системы, базы данных и пользователи.

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

Классический пример этой проблемы -- тип состояния гонки, часто встречающийся в UNIX-программах и называемый гонкой /tmp (произносится как "temp race"). Она возникает, когда программе нужно использовать временный файл, и она создает этот файл в публичном каталоге системы, расположенном в /tmp или /var/tmp. Если программа написана недостаточно аккуратно, атакующий может предугадать ее действия и устроить для нее ловушку в публичном каталоге. Если атакующий создаст символическую ссылку в правильном месте и в правильное время, программу можно обманом заставить создать временный файл в другом месте системы и под другим именем. Обычно это приводит к эксплуатируемому состоянию, если уязвимая программа выполняется с привилегиями root (администратора).

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

Исключительные условия

Уязвимости, связанные с обработкой исключительных условий, переплетены с уязвимостями данных и окружения. В сущности, исключительное условие возникает, когда атакующий может внешними средствами вызвать неожиданное изменение нормального потока управления программы. Такое поведение может включать асинхронное прерывание программы, например доставку сигнала. Оно также может включать потребление глобальных системных ресурсов для намеренного вызова состояния отказа в конкретном месте программы.

Например, UNIX-система отправляет сигнал SIGPIPE, если процесс пытается записать в закрытое сетевое соединение или канал; поведение по умолчанию при получении этого сигнала -- завершить процесс. Атакующий может заставить уязвимую программу записать в канал в удобный момент, а затем закрыть канал до того, как приложение сможет успешно выполнить операцию записи. Это приведет к сигналу SIGPIPE, который может заставить приложение прерваться и, возможно, оставить систему в целом в нестабильном состоянии. Более конкретный пример: демон состояния Network File System (NFS) в некоторых дистрибутивах Linux был уязвим к аварийному завершению, вызванному закрытием соединения в правильный момент. Эксплуатация этой уязвимости создавала нарушение функциональности NFS, сохранявшееся до тех пор, пока администратор не вмешивался и не перезапускал демон.

Итоги

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

В другом лагере находятся аудиторы кода, которым доставляет удовольствие находить самые неясные и сложные уязвимости. Эта группа склонна смотреть на анализ проектирования как на конструкцию из башни из слоновой кости, которая только мешает настоящей работе. Формализованный процесс анализа проектирования и его сосредоточенность на документации воспринимаются как барьер на пути к погружению в код.

Истина в том, что анализ проектирования находится где-то между взглядами этих двух лагерей и ценен для обоих. Анализ проектирования -- полезный инструмент для выявления уязвимостей в архитектуре приложения и расстановки приоритетов компонентов для анализа реализации. Однако он не заменяет анализ реализации; это всего лишь компонент полного процесса проверки. Он значительно облегчает выявление дефектов проектирования и обеспечивает более тщательный анализ безопасности программного проекта. В этом качестве он может сделать весь процесс проверки эффективнее и обеспечить наилучшую отдачу от вложенного времени.

Эта глава дает некоторый контекст по элементам проектирования программного обеспечения и уязвимостям проектирования, а также вводит процесс анализа, помогающий выявлять проблемы безопасности в программном проекте.

Основы проектирования программного обеспечения

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

Алгоритмы

Программную инженерию можно кратко описать как процесс разработки и реализации алгоритмов. С точки зрения проектирования этот процесс сосредоточен на разработке ключевых алгоритмов программы и структур данных, а также на задании логики предметной области. Чтобы понять требования безопасности и потенциальные уязвимости проекта системы, сначала нужно понять основные алгоритмы, из которых состоит система.

Логика предметной области

Логика предметной области (или бизнес-логика) задает правила, которым программа следует при обработке данных. Проект программной системы должен включать правила и процессы для основных задач, выполняемых программой. Один важный компонент проектирования ПО -- ожидания безопасности, связанные с пользователями и ресурсами системы. Например, рассмотрим банковское ПО со следующими правилами:

• Человек может перевести деньги со своего основного счета на любой допустимый счет.

• Человек может перевести деньги со своего счета денежного рынка на любой допустимый счет.

• Человек может переводить деньги со своего счета денежного рынка только один раз в месяц.

• Если баланс основного счета человека становится ниже нуля, деньги автоматически переводятся со счета денежного рынка для покрытия баланса, если такие средства доступны.

Этот пример прост, но видно, что клиенты банка могут обойти ограничение на один перевод в месяц для счетов денежного рынка. Они могут намеренно опустить основной счет ниже нуля, чтобы "освободить" деньги со своих счетов денежного рынка. Следовательно, в проекте этой системы есть недосмотр, который клиенты банка потенциально могут эксплуатировать.

Ключевые алгоритмы

Часто у программ есть требования к производительности, которые диктуют выбор алгоритмов и структур данных для управления ключевыми фрагментами данных. Иногда эти алгоритмические решения можно оценить с точки зрения проектирования и предсказать уязвимости безопасности, которые могут повлиять на систему.

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

Абстракция и декомпозиция

Любой текст о проектировании программного обеспечения неизбежно рассматривает две важнейшие концепции: абстракцию и декомпозицию. Вероятно, вы уже знакомы с ними, но если нет, следующие абзацы дадут краткий обзор.

Абстракция -- это метод уменьшения сложности системы, делающий ее более управляемой. Для этого вы выделяете только самые важные элементы и удаляете ненужные детали. Абстракции являются важнейшей частью того, как люди воспринимают окружающий мир. Они объясняют, почему вы можете увидеть символ вроде и связать его с улыбающимся лицом. Абстракции позволяют обобщать понятие, например лицо, и группировать связанные понятия, например улыбающиеся и хмурые лица.

В проектировании программного обеспечения абстракции -- это способ моделировать процессы, которые будет выполнять приложение. Они позволяют устанавливать иерархии связанных систем, понятий и процессов, изолируя логику предметной области и ключевые алгоритмы. По сути, процесс проектирования -- это всего лишь метод построения набора абстракций, которые затем можно развить в реализацию. Этот процесс становится особенно важным, когда программа должна учитывать интересы широкого круга пользователей или когда ее реализация должна быть распределена между командой разработчиков.

Декомпозиция (или факторизация) -- это процесс определения обобщений и классификаций, составляющих абстракцию. Декомпозиция может идти в двух разных направлениях. Декомпозиция сверху вниз, известная как специализация, -- это процесс разбиения более крупной системы на меньшие, более управляемые части. Декомпозиция снизу вверх, называемая обобщением, включает выявление сходств в ряде компонентов и разработку более высокоуровневой абстракции, применимой ко всем ним.

Базовые элементы структурной декомпозиции программного обеспечения могут различаться от языка к языку. Стандартная последовательность сверху вниз такова: приложение, модуль, класс и функция (или метод). Некоторые языки могут не поддерживать каждое различие в этом списке (например, C не имеет языковой поддержки классов); другие языки добавляют больше различий или используют немного другую терминологию. Для наших целей эти различия не так важны, но ради простоты это обсуждение в основном придерживается модулей и функций.

Отношения доверия

В главе 1, "Основы уязвимостей программного обеспечения", было введено понятие доверия и того, как оно влияет на безопасность системы. Эта глава развивает это понятие и утверждает, что каждая коммуникация между несколькими сторонами должна иметь связанную с ней некоторую степень доверия. Это называется отношением доверия. Для простых коммуникаций обе стороны могут предполагать полное доверие, то есть каждая общающаяся сторона предоставляет другим участникам коммуникации полный доступ к своей открытой функциональности. Однако с точки зрения безопасности нас больше интересуют ситуации, в которых общающиеся стороны должны ограничивать доверие друг к другу. Это означает, что стороны могут получить доступ только к ограниченному подмножеству функциональности друг друга. Ограничения, наложенные на каждую сторону коммуникации, определяют между ними границу доверия. Граница доверия различает области общего доверия, известные как домены доверия. (Не беспокойтесь, если эти понятия пока немного сбивают с толку; в следующем разделе приведены примеры.)

Проект программного обеспечения должен учитывать домены, границы и отношения доверия системы; модель доверия -- это абстракция, представляющая эти понятия и являющаяся компонентом политики безопасности приложения. Влияние этой модели заметно в том, как декомпозируется система, поскольку границы доверия часто также являются границами модулей. Модель часто требует, чтобы доверие не было абсолютным; вместо этого она поддерживает разные степени доверия, называемые привилегиями. Классический пример -- стандартные права доступа к файлам в UNIX, где пользователь может предоставить другим пользователям системы ограниченный объем доступа к файлу. В частности, пользователи могут указать, разрешено ли другим пользователям читать, записывать или выполнять рассматриваемый файл (или любую комбинацию этих разрешений), тем самым распространяя на других пользователей системы ограниченный объем доверия.

Простые границы доверия

В качестве примера отношения доверия рассмотрим базовую однопользовательскую ОС, например Windows 98. Для простоты предположим, что сеть не задействована. Windows 98 имеет базовую защиту памяти и некоторое представление о пользователях, но не предлагает реального контроля доступа или его принудительного соблюдения. Иными словами, если пользователи могут войти в систему Windows 98, они свободны изменять любые файлы или системные настройки по своему желанию. Поэтому от любого пользователя, который может интерактивно войти в систему, вы не ожидаете безопасности.

Можно определить, что между интерактивными пользователями одной и той же системы Windows 98 нет границ доверия. Однако вы делаете неявное предположение о том, кто имеет физический доступ к системе. Поэтому можно сказать, что граница доверия в этой ситуации определяет, какие пользователи имеют физический доступ к системе, а какие нет. Это оставляет один домен доверенных пользователей и неявный домен, представляющий всех недоверенных пользователей.

Чтобы немного усложнить этот пример, допустим, вы перешли на многопользовательскую ОС, например Windows XP Professional. Такое обновление приносит новый набор соображений. Вы ожидаете, что два пользователя с обычными привилегиями не должны иметь возможности манипулировать данными или процессами друг друга. Разумеется, это ожидание предполагает, что вы не работаете от имени административного пользователя. Теперь у вас есть ожидание конфиденциальности и целостности между двумя пользователями системы, что устанавливает их отношение доверия и еще одну границу доверия. Кроме того, нужно учитывать административного пользователя, что добавляет еще одну границу: неадминистративные пользователи не могут влиять на целостность или конфигурацию системы. Это ожидание является естественным развитием, необходимым для принудительного соблюдения границы между пользователями. В конце концов, если любой пользователь мог бы влиять на состояние системы, вы снова оказались бы в однопользовательской ОС. Рисунок 2-1 графически представляет это отношение доверия в многопользовательской ОС.

Рисунок 2-1. Простые границы доверия

Теперь сделайте шаг назад и подумайте о природе доверия. Каждая система в конечном итоге должна иметь некоторый абсолютно доверенный орган. Обойти это невозможно, потому что кто-то должен отвечать за состояние системы. Именно поэтому в UNIX есть учетная запись root, а в Windows -- учетная запись администратора. Конечно, к этому уровню полномочий можно применять разные средства контроля. Например, и UNIX, и Windows имеют способы предоставлять степени административных привилегий разным пользователям и для конкретных целей. Однако простой факт остается: в каждой границе доверия есть по крайней мере один абсолютный орган, который может принять ответственность.

Сложные отношения доверия

Пока что вы рассматривали довольно простые отношения доверия, чтобы получить представление о проблемных областях, с которыми нужно будет работать дальше. Однако некоторые тонкие детали были опущены. Чтобы сделать обсуждение немного реалистичнее, рассмотрим ту же систему, подключенную к сети.

После подключения системы к сети приходится начинать добавлять целый ряд различий. Возможно, нужно учитывать отдельные домены для локальных и удаленных пользователей системы, и, вероятно, понадобится домен для людей, которые имеют сетевой доступ к системе, но не являются "обычными" пользователями. Межсетевые экраны и шлюзы еще больше усложняют эти различия и позволяют проводить дополнительные разделения.

Должно быть очевидно, что определение и применение модели доверия может иметь огромное влияние на любой программный проект. Настоящая работа начинается еще до начала процесса проектирования. Фазы технико-экономического обоснования и сбора требований должны адекватно выявлять и определять ожидания пользователей в отношении безопасности и связанные факторы целевой среды. Итоговая модель должна быть достаточно устойчивой, чтобы удовлетворять этим потребностям, но не настолько сложной, чтобы ее было слишком трудно реализовать и применять. Таким образом, безопасность должна тщательно уравновешивать ясность и потребность в точности. Когда далее в этой главе вы будете рассматривать моделирование угроз, вы будете учитывать модели доверия, оценивая границы между разными компонентами системы и права разных сущностей в системе.

Цепочка доверия

В главе 1 также было введено понятие транзитивного доверия. По сути, оно означает: если компонент A доверяет компоненту B, компонент A должен неявно доверять всем компонентам, которым доверяет компонент B. Это понятие также можно назвать отношением цепочки доверия.

Цепочка доверия -- вполне жизнеспособная конструкция безопасности и ядро многих систем. Рассмотрим, как сертификаты распространяются и проверяются в типичном соединении Secure Sockets Layer (SSL) с веб-сервером. У вас есть локальная база подписей, определяющая поставщиков, которым вы доверяете. Эти поставщики затем могут выдать сертификат центру сертификации (certificate authority, CA), который затем может распространить доверие на другие центры. Наконец, сайт-хостинг имеет сертификат, подписанный одним из этих центров. При установлении SSL-соединения нужно пройти по этой цепочке доверия от CA к CA. Проход успешен только тогда, когда вы достигаете центра, находящегося в вашей доверенной базе.

Теперь предположим, что вы хотите выдать себя за веб-сайт с какой-то вредоносной целью. На мгновение оставим систему доменных имен (DNS) за кадром, потому что она часто является легкой целью. Вместо этого все, что вам нужно, -- найти способ манипулировать базой сертификатов где-нибудь в цепочке доверия. Это включает манипулирование клиентской базой сертификатов посетителей, прямую компрометацию целевого сайта или манипулирование любой базой CA в цепочке, включая корневой CA.

Полезно повторить последнюю часть, чтобы акцент был совершенно ясен. Транзитивная природа доверия, разделяемого каждым CA, означает, что компрометация любого CA позволяет атакующему успешно выдать себя за любой сайт. Неважно, скомпрометирован ли CA, выдавший настоящий сертификат, потому что подойдет любой сертификат, выданный действительным CA. Это означает, что целостность любой SSL-транзакции настолько сильна, насколько силен самый слабый CA. К сожалению, этот метод -- лучшее из доступного для установления идентичности хоста.

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

Глубокоэшелонированная защита

Глубокоэшелонированная защита -- это концепция наслаивания защитных мер так, чтобы компрометация одного аспекта системы смягчалась другими средствами контроля. Простые примеры такой защиты включают запуск служб и демонов от учетных записей с низкими привилегиями и изоляцию разных функций на разных аппаратных узлах. Более сложные примеры включают сетевые демилитаризованные зоны (DMZ), chroot-окружения, а также защиту стека и кучи.

Многоуровневые защитные меры нужно учитывать при расстановке приоритетов компонентов для проверки. Вероятно, вы назначите более низкий приоритет компоненту, обращенному к интрасети, который работает от учетной записи с низкими привилегиями, внутри chroot-окружения и скомпилирован с защитой буфера. Напротив, вы, скорее всего, назначите более высокий приоритет компоненту, обращенному в Интернет и вынужденному работать от имени root. Это не означает, что первый компонент безопасен, а второй нет. Вам просто нужно смотреть на факты и расставлять усилия так, чтобы они давали наибольший эффект. Приоритизация угроз подробнее обсуждается далее в этой главе, в разделе "Моделирование угроз".

Принципы проектирования программного обеспечения

Количество методологий разработки программного обеспечения, кажется, растет прямо пропорционально количеству разработчиков. Разные методологии подходят разным потребностям, а выбор для проекта зависит от целого ряда факторов.

К счастью, у каждой методологии есть некоторые общепринятые принципы. Четыре базовых принципа -- точность, ясность, слабая связанность и сильная связность (они обсуждаются в следующих разделах) -- применимы к любому программному проекту и являются хорошей отправной точкой для любого разговора о том, как проектирование может влиять на безопасность.

Точность

Точность относится к тому, насколько эффективно проектные абстракции удовлетворяют связанным требованиям. (Вспомните обсуждение требований в главе 1.) Точность включает как то, насколько правильно абстракции моделируют требования, так и то, насколько разумно их можно перевести в реализацию. Цель, конечно, состоит в том, чтобы дать наиболее точную модель с максимально прямой реализацией.

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

Расхождения между программным проектом и его реализацией приводят к слабостям проектной абстракции. Эти слабости -- плодородная почва для проникновения разных ошибок, включая уязвимости безопасности. Они вынуждают разработчиков делать предположения вне предполагаемого проекта, а неспособность передать эти предположения часто создает ситуации, склонные к уязвимостям. Следите за областями, где проект определен недостаточно или возлагает на программистов необоснованные ожидания.

Ясность

Программные проекты могут моделировать чрезвычайно сложные и часто запутанные процессы. Чтобы достичь цели ясности, хороший проект должен разумно декомпозировать проблему и предоставлять чистые, самоочевидные абстракции. Документация структуры также должна быть легко доступной и хорошо понятной всем разработчикам, участвующим в процессе реализации.

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

Слабая связанность

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

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

Сильная связность

Связность относится к внутренней согласованности модуля. Эта согласованность в первую очередь означает степень, в которой интерфейсы модуля обрабатывают связанный набор действий. Сильная связность побуждает модуль обрабатывать только тесно связанные действия. Побочный эффект поддержания сильной связности состоит в том, что она обычно поощряет сильную внутримодульную связанность (степень связанности между разными компонентами одного модуля).

Уязвимости безопасности, связанные со связностью, могут возникать, когда проект не декомпозирует модули вдоль границ доверия. Получающиеся уязвимости похожи на проблемы сильной связанности, за исключением того, что они возникают внутри одного и того же модуля. Часто это результат систем, которые не включили безопасность на ранних стадиях проектирования. Уделяйте особое внимание проектам, которые обращаются к нескольким доменам доверия внутри одного модуля.

Фундаментальные дефекты проектирования

Теперь, когда у вас есть базовое понимание, можно рассмотреть несколько примеров того, как фундаментальные концепции проектирования влияют на безопасность. В частности, нужно увидеть, как неправильное применение этих концепций может создавать уязвимости безопасности. Читая следующие примеры, вы быстро заметите, что они обычно возникают из сочетания нескольких проблем. Часто ошибка открыта для интерпретации и может сильно зависеть от точки зрения проверяющего. К сожалению, это часть природы дефектов проектирования. Обычно они влияют на систему на концептуальном уровне и могут быть трудны для классификации. Поэтому нужно сосредоточиться на влиянии проблемы на безопасность, а не застревать на категоризации.

Эксплуатация сильной связанности

В этом разделе рассматривается фундаментальный дефект проектирования, возникающий из-за неспособности правильно декомпозировать приложение вдоль границ доверия. Общая проблема известна как класс уязвимостей Shatter, впервые описанный в рамках независимого исследования Криса Пейджета. Конкретный путь атаки использует определенные свойства интерфейса прикладного программирования (API) графического интерфейса Windows. Следующее обсуждение опускает многие детали, чтобы подчеркнуть специфически проектную природу Shatter-уязвимостей. Глава 12, "Windows II: межпроцессное взаимодействие", дает гораздо более подробное обсуждение технических деталей, связанных с этим классом уязвимостей.

Программы Windows используют систему сообщений для обработки всех событий, связанных с GUI; у каждого рабочего стола есть одна очередь сообщений для всех связанных с ним приложений. Поэтому любые два процесса, работающие на одном рабочем столе, могут отправлять сообщения друг другу независимо от пользовательского контекста процессов. Это может создавать проблему, когда процесс с более высокими привилегиями, например служба, работает на рабочем столе обычного пользователя.

Windows API предоставляет функцию SetTimer() для планирования отправки сообщения WM_TIMER. Это сообщение может включать указатель на функцию, которая вызывается, когда обработчик сообщений по умолчанию получает WM_TIMER. Это создает ситуацию, в которой процесс может управлять вызовом функции в любом другом процессе, разделяющем с ним рабочий стол. Единственная оставшаяся задача атакующего -- понять, как предоставить код для выполнения в целевом процессе.

Windows API включает ряд сообщений для манипулирования содержимым оконных элементов. Обычно они используются для установки содержимого текстовых полей и меток, манипулирования содержимым буфера обмена и так далее. Однако атакующий может использовать эти сообщения для вставки данных в адресное пространство целевого процесса. Совмещая такой тип сообщения с сообщением WM_TIMER, атакующий может построить и запустить произвольный код в любом процессе на том же рабочем столе. Результат -- уязвимость повышения привилегий, которую можно использовать против служб, работающих на интерактивном рабочем столе.

После публикации этой уязвимости Microsoft изменила способ обработки сообщения WM_TIMER. Однако ключевая проблема в том, что коммуникацию через рабочий стол нужно считать потенциальным вектором атаки. Это становится понятнее, если учесть, что исходный дизайн системы сообщений был сильно сформирован заботами однопользовательской ОС. В таком контексте проект был точным, понятным и сильно связным.

Эта уязвимость показывает, почему трудно добавлять безопасность в существующий проект. Исходный дизайн сообщений Windows был разумен для своей среды, но появление многопользовательской ОС изменило ландшафт. Теперь очередь сообщений сильно связывает разные домены доверия на одном рабочем столе. Результат -- новые типы уязвимостей, в которых рабочий стол можно эксплуатировать как публичный интерфейс.

Эксплуатация транзитивного доверия

Любопытная проблема безопасности Solaris показывает, как атакующие могут манипулировать доверенным отношением между двумя компонентами. Некоторые версии Solaris включали RPC-программу automountd, работавшую от имени root. Эта программа позволяла пользователю root указать команду, запускаемую как часть операции монтирования, и обычно использовалась для обработки монтирования и размонтирования от имени ядра. Программа automountd не слушала IP-сеть и была доступна только через три защищенных loopback-транспорта. Это означало, что программа принимала команды только от пользователя root, что кажется довольно безопасным выбором интерфейса.

Другая программа, rpc.statd, работает от имени root и слушает интерфейсы Transmission Control Protocol (TCP) и User Datagram Protocol (UDP). Она используется как часть поддержки протокола Network File System (NFS), а ее назначение -- отслеживать NFS-серверы и отправлять уведомление, если они выходят из строя. Обычно демон блокировок NFS просит rpc.statd отслеживать серверы. Однако регистрация в rpc.statd требует, чтобы клиент сообщил, с каким хостом связаться и какой номер RPC-программы вызвать на этом хосте.

Поэтому атакующий может обратиться к rpc.statd машины и зарегистрировать программу automountd для получения уведомлений об авариях. Затем атакующий сообщает rpc.statd, что отслеживаемый NFS-сервер отказал. В ответ rpc.statd связывается с демоном automountd на локальной машине (через специальный loopback-интерфейс) и передает ему RPC-сообщение. Это сообщение не соответствует тому, чего ожидает automountd, но некоторыми манипуляциями можно добиться, чтобы оно декодировалось в допустимый запрос automountd. Запрос приходит от root через loopback-транспорт, поэтому automountd считает, что он пришел от модуля ядра. В результате он выполняет команду по выбору атакующего.

В этом случае атака на публичный интерфейс rpc.statd была полезна только для установления доверенной коммуникации с automountd. Она стала возможной потому, что между всеми процессами, работающими под одной учетной записью, существует неявное доверие. Эксплуатация этого доверия позволила удаленным атакующим отдавать команды процессу automountd. Наконец, предположения об источнике коммуникации заставили разработчиков быть снисходительными к формату, который принимает automountd. Эти проблемы, в сочетании с общим доверием между модулями, привели к удаленной уязвимости уровня root.

Обработка отказов

Правильная обработка отказов -- важный компонент ясной и точной удобности использования в программном проекте. От приложения просто ожидают корректной обработки нерегулярных условий и помощи пользователям в решении проблем. Однако условия отказа могут создавать ситуации, в которых удобство использования и безопасность кажутся противоположными. Иногда приходится идти на компромиссы в функциональности приложения, чтобы можно было обеспечить безопасность.

Рассмотрим сетевую программу, которая обнаруживает сбой или состояние отказа в данных, полученных от клиентской системы. Точная и ясная удобность использования диктует, что приложение должно попытаться восстановиться и продолжить обработку. Когда восстановление невозможно, приложение должно помочь пользователям диагностировать проблему, предоставив подробную информацию об ошибке.

Однако программа, ориентированная на безопасность, обычно выбирает совершенно другой подход: он может включать завершение клиентского сеанса и предоставление минимально необходимой обратной связи. Такой подход используется потому, что программа, спроектированная вокруг идеала безопасности, предполагает, что условия отказа являются результатом манипуляции атакующих с вводом или окружением программы. С этой точки зрения попытка обойти проблему и продолжить обработку часто прямо играет на руку атакующему. Прагматичная защитная реакция -- бросить происходящее, поднять страшную тревогу в журналах и прервать обработку. Хотя такая реакция может показаться нарушением некоторых принципов проектирования, это просто ситуация, в которой точность требований безопасности превосходит точность и ясность требований удобства использования.

Принудительное соблюдение политики безопасности

В главе 1 обсуждались ожидания безопасности и то, как они влияют на систему. Теперь можно взять эти понятия и развить более подробное понимание того, как ожидания безопасности принудительно реализуются в политике безопасности. Разработчики реализуют политику безопасности прежде всего путем выявления и принудительного соблюдения границ доверия. Как аудитор вы должны анализировать проект этих границ и код, реализующий их принудительное соблюдение. Чтобы проще рассматривать элементы политики безопасности, принудительное соблюдение разбито на шесть основных типов, обсуждаемых в следующих разделах.

Аутентификация

Аутентификация -- это процесс, с помощью которого программа определяет, кем пользователь себя называет, а затем проверяет достоверность этого утверждения. Программный компонент использует аутентификацию для установления идентичности партнера (клиента или сервера) при инициировании коммуникации. Классический пример -- требование к пользователю веб-сайта ввести имя пользователя и пароль. Аутентификация предназначена не только для людей-партнеров, как видно из предыдущего обсуждения SSL-сертификатов. В том примере системы аутентифицировали друг друга, чтобы безопасно работать через недоверенный интерфейс.

Распространенные уязвимости аутентификации

Один заметный проектный недосмотр -- не требовать аутентификацию в ситуации, где она необходима. Например, веб-приложение показывает сводку чувствительной корпоративной бухгалтерской информации, которая могла бы быть полезна для инсайдерской торговли. Раскрытие этой информации произвольным пользователям Интернета без запроса какой-либо аутентификации было бы дефектом проектирования. Обратите внимание, что проблемы "отсутствия аутентификации" не всегда очевидны, особенно когда вы имеете дело с одноранговыми модулями в большом приложении. Часто трудно определить, что атакующий может получить доступ к предположительно внутреннему интерфейсу между двумя компонентами.

Обычно лучшая практика -- централизовать аутентификацию в проекте, особенно в веб-приложениях. Некоторые веб-приложения требуют аутентификацию для пользователей, входящих через главную страницу, но не применяют аутентификацию на последующих страницах. Такое отсутствие аутентификации означает, что с приложением можно взаимодействовать, ни разу не вводя имя пользователя и пароль. Напротив, централизованная аутентификация смягчает эту проблему, проверяя каждый веб-запрос внутри защищенного домена.

Недостоверные учетные данные

Еще одна распространенная ошибка возникает, когда программе предъявляется некоторая аутентификационная информация, но этой информации нельзя доверять. Такая проблема часто появляется, когда аутентификация выполняется на стороне клиента, а атакующий может полностью контролировать клиентскую сторону соединения. Например, фреймворк SunRPC включает схему аутентификации AUTH_UNIX, которая по сути сводится к полному доверию клиентской системе. Клиент просто передает запись, сообщающую серверу, каковы идентификаторы пользователя и группы, а сервер принимает их как факт.

UNIX-системы раньше включали RPC-демон под названием rexd (remote execute daemon). Назначение этой программы состояло в том, чтобы позволить удаленному пользователю запускать программу в системе от имени локального пользователя. Если бы вы подключились к системе rexd и сказали программе rexd запустить команду /bin/sh от имени пользователя bin, программа запустила бы shell от имени bin и позволила бы вам с ним взаимодействовать. В этом почти все и заключалось, за исключением того, что нельзя было запускать программы от имени пользователя root. Обычно обход этого ограничения занимает всего несколько минут после того, как у вас уже есть shell от имени bin. Позднее в стандартной установке sadmind на Solaris был раскрыт удаленный дефект root-уровня: программа считала аутентификацию AUTH_UNIX достаточной проверкой для выполнения команд от имени клиента.

Примечание

Ошибка в sadmind документирована по адресу www.securityfocus.com/bid/2354/info.

Многие сетевые демоны используют исходный IP-адрес сетевого соединения или пакета для установления идентичности партнера. Само по себе это не является достаточными учетными данными и подвержено подделке. UDP тривиально подделывается, а TCP-соединения в разных ситуациях можно подделывать или перехватывать. UNIX предоставляет несколько демонов, уважающих концепцию доверенных хостов на основе исходного адреса. Эти демоны -- rshd и rlogind, и даже sshd можно настроить так, чтобы он уважал такие отношения доверия. Инициируя, подделывая или перехватывая TCP-соединение с доверенной машины на привилегированном порту, атакующий может эксплуатировать отношение доверия между двумя машинами.

Недостаточная проверка

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

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

Самодельная аутентификация с криптографическими примитивами -- еще одна проблема, с которой можно столкнуться. На концептуальном уровне собственная аутентификация кажется простой. Если у вас есть общий секрет, вы выдаете партнеру вызов. Затем партнер отправляет обратно значение, которое могло быть получено только из комбинации вызова и общего секрета. Если вы используете открытые и закрытые ключи, вы отправляете партнеру вызов, шифруя его открытым ключом партнера, и ожидаете ответ, доказывающий, что партнер смог его расшифровать.

Однако при создании протоколов аутентификации с нуля остается много места для ошибок. Томас Лопатик нашел забавную уязвимость в протоколе FWN/1 Firewall-1. Каждый партнер отправляет случайное число R1 и хеш этого случайного числа с общим ключом, Hash(R1+K). Принимающая сторона может посмотреть на отправленное случайное число, вычислить хеш и сравнить его с переданным значением. Проблема в том, что значения R1 и Hash(R1+K) можно просто повторно отправить серверу, потому что они созданы с использованием одного и того же общего симметричного ключа.

Авторизация

Авторизация -- это процесс определения того, разрешено ли пользователю системы выполнить конкретную операцию внутри домена доверия. Она работает вместе с аутентификацией как часть политики контроля доступа: аутентификация устанавливает, кем является пользователь, а авторизация определяет, что этому пользователю разрешено делать. Существует много формальных проектов систем контроля доступа, включая дискреционный контроль доступа, мандатный контроль доступа и ролевой контроль доступа. Кроме того, доступно несколько технологий для централизации контроля доступа в разных фреймворках, операционных системах и библиотеках. Из-за сложности разных схем контроля доступа лучше начать с рассмотрения авторизации с общей точки зрения.

Распространенные уязвимости авторизации

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

Небезопасные источники полномочий

Пропуск проверок авторизации -- очевидная проблема. Также можно столкнуться с ситуациями, в которых логика проверок авторизации непоследовательна или оставляет место для злоупотребления. Например, допустим, у вас есть простая система учета расходов, и у каждого пользователя в компании есть учетная запись. Система заранее запрограммирована корпоративной иерархией, поэтому знает, какие сотрудники являются менеджерами и кем они управляют. Основная логика управляется данными и выглядит примерно так:

Ввести новый расход; для каждого сотрудника, которым вы управляете: Просмотреть/утвердить расходы

Эта система довольно проста. При условии, что исходная корпоративная иерархия заполнена правильно, менеджеры могут просматривать и утверждать расходы своих подчиненных. Обычные сотрудники видят только пункт меню Ввести новый расход, потому что в системе они не указаны как управляющие другими сотрудниками.

Теперь предположим, что вы постоянно сталкиваетесь с ситуациями, когда сотрудники официально подчиняются одному человеку, но фактически по повседневным вопросам отчитываются перед другим менеджером. Чтобы решить эту проблему, вы позволяете каждому пользователю назначать другого пользователя своим "виртуальным" менеджером. Виртуальный менеджер пользователя получает права просмотра и утверждения расходов этого пользователя, как и официальный менеджер. На первый взгляд такое решение может выглядеть нормальным, но оно дефектно. Оно создает ситуацию, в которой сотрудники могут назначить любого коллегу своим виртуальным менеджером, включая самих себя. Получившийся виртуальный менеджер затем может утверждать расходы без дополнительных ограничений.

Эта простая система с очевидной проблемой может показаться искусственной, но она выведена из проблем, встречавшихся в реальных приложениях. По мере роста числа пользователей и групп в приложении и роста сложности системы проектировщикам становится легко упустить возможность потенциального злоупотребления логикой авторизации.

Подотчетность

Подотчетность относится к ожиданию, что система может идентифицировать и журналировать действия, выполняемые пользователями системы. Неотказуемость -- связанный термин, фактически являющийся подмножеством подотчетности. Он относится к гарантии, что система журналирует определенные действия пользователей так, чтобы пользователи позднее не могли отрицать их выполнение. Подотчетность вместе с авторизацией и аутентификацией устанавливает полную политику контроля доступа. В отличие от аутентификации и авторизации, подотчетность не принуждает конкретную границу доверия и не предотвращает компрометацию. Вместо этого подотчетность предоставляет данные, которые могут быть существенными при смягчении успешной компрометации и проведении криминалистического анализа. К сожалению, подотчетность -- одна из самых упускаемых частей безопасного проектирования приложений.

Распространенные уязвимости подотчетности

Самая распространенная уязвимость подотчетности -- неспособность системы журналировать операции с чувствительными данными. Фактически многие приложения вообще не предоставляют возможности журналирования. Конечно, многие приложения не обрабатывают чувствительные данные, требующие журналирования. Однако определять, требуется ли журналирование, должны администраторы или конечные пользователи, а не разработчики.

Следующая важная забота для подотчетности -- система, которая недостаточно защищает свои журнальные данные. Конечно, эта забота может также быть проблемой авторизации, конфиденциальности или целостности. В любом случае любая система, поддерживающая журнал, должна обеспечивать безопасность этого журнала. Например, ниже представлен простой текстовый журнал, в котором каждая строка включает временную метку, за которой следует запись журнала:

20051018133106 Logon Failure: Bob20051018133720 Logon Success: Jim20051018135041 Logout: Jim

Что произойдет, если включить в запись журнала строки, изменяемые пользователем? Что помешает пользователю намеренно отправить ввод, выглядящий как запись журнала? Например, предположим, что пользователь указал "Bob\n20051018133106 Logon Success: Greg" как имя для входа. Это похоже на безобидную шалость, но может быть использовано для вредоносной деятельности. Атакующие могут использовать поддельные записи, чтобы скрывать вредоносную активность или обвинять невиновного пользователя. Они также могут повредить журнал настолько, что он станет нечитаемым или недоступным для записи. Такое повреждение может создать состояние отказа в обслуживании или открыть пути к другим уязвимостям. Оно может даже предоставить эксплуатируемые пути в самой системе журналирования.

Манипулирование этим журналом -- не единственная проблема. Что происходит, когда атакующие могут его читать? Как минимум они узнают, в какое время каждый пользователь входил и выходил. Из этих данных они могут вывести шаблоны входа или заметить, какие пользователи имеют привычку забывать пароли. Такая информация может казаться безобидной, но она может быть полезна при подготовке более крупной атаки. Поэтому неавторизованные пользователи не должны иметь возможности читать или изменять содержимое системного журнала.

Конфиденциальность

Глава 1 описывала конфиденциальность как ожидание, что только уполномоченные стороны могут просматривать данные. Это требование обычно реализуется через механизмы контроля доступа, которые охватываются аутентификацией и авторизацией. Однако дополнительные меры необходимо принимать, когда коммуникация выполняется по небезопасному каналу. В таких случаях для принудительного соблюдения требований конфиденциальности часто используется шифрование.

Шифрование -- это процесс кодирования информации так, чтобы третья сторона не могла прочитать ее без специальных знаний, включающих процесс шифрования и обычно некоторую форму ключевых данных. Ключевые данные -- это фрагмент данных, известный только сторонам, уполномоченным на доступ к информации.

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

Ваша главная забота с точки зрения проектирования -- определить, правильно ли применяется конкретный криптографический протокол. Протокол должен быть достаточно сильным для данных, которые он защищает, и должен использоваться безопасным образом. Если вам нужна дополнительная информация о правильном использовании криптографии, можно прочитать Practical Cryptography (Wiley, 2003) Брюса Шнайера и Нильса Фергюсона. Если вас интересуют алгоритмы и реализация, обратите внимание на другую книгу Брюса Шнайера, Applied Cryptography (Wiley, 1996).

Алгоритмы шифрования

У шифрования длинная история, уходящая к древним культурам. Однако поскольку нас интересуют современные криптографические протоколы, которые можно использовать для эффективной защиты передачи данных, эта глава сосредоточена на двух основных классах шифрования: симметричном и асимметричном.

Симметричное шифрование (или шифрование с общим ключом) относится к алгоритмам, в которых все уполномоченные стороны используют один и тот же ключ. Симметричные алгоритмы обычно являются самыми простыми и эффективными алгоритмами шифрования. Их главная слабость в том, что они требуют, чтобы несколько сторон имели доступ к одному и тому же общему секрету. Альтернатива -- генерировать и обмениваться уникальным ключом для каждого коммуникационного отношения, но это решение быстро приводит к несостоятельной ситуации управления ключами. Кроме того, асимметричное шифрование не имеет способа проверить отправителя сообщения среди любой группы пользователей общего ключа.

Асимметричное шифрование (или шифрование с открытым ключом) относится к алгоритмам, в которых у каждой стороны есть разный набор ключей для доступа к одним и тем же зашифрованным данным. Это делается с использованием пары открытого и закрытого ключа для каждой стороны. Любые стороны, желающие общаться, должны заранее обменяться своими открытыми ключами. Затем сообщение шифруется путем сочетания открытого ключа получателя и закрытого ключа отправителя. Получившееся зашифрованное сообщение можно расшифровать только с помощью закрытого ключа получателя.

Таким образом, асимметричное шифрование упрощает управление ключами, не требует раскрытия закрытых ключей и неявно проверяет отправителя сообщения. Однако эти алгоритмы сложнее и обычно вычислительно затратны. Поэтому асимметричные алгоритмы обычно используются для обмена симметричным ключом, который затем применяется на протяжении коммуникационного сеанса.

Блочные шифры

Блочные шифры -- это алгоритмы симметричного шифрования, которые работают с блоками данных фиксированного размера и функционируют в нескольких режимах. Однако нужно знать некоторые соображения по их использованию. Одно соображение -- шифрует ли блочный шифр каждый блок независимо или использует выход предыдущего блока при шифровании текущего. Шифры, шифрующие блоки независимо, гораздо более уязвимы к криптоаналитическим атакам, и их следует избегать при любой возможности. Поэтому шифр в режиме сцепления блоков шифротекста (cipher block chaining, CBC) -- единственный подходящий шифр фиксированных блоков для общего использования. Он выполняет операцию XOR с предыдущим блоком данных, что дает пренебрежимо малые накладные расходы производительности и гораздо более высокую безопасность по сравнению с режимами, обрабатывающими блоки независимо.

Потоковые шифры

Один из самых неудобных аспектов блочных шифров состоит в том, что они должны обрабатывать фрагменты данных фиксированного размера. Любые фрагменты данных больше размера блока должны быть разбиты, а все, что меньше, должно быть дополнено. Это требование может добавлять сложность и накладные расходы в код, обрабатывающий что-то вроде стандартного TCP-сокета.

К счастью, блочные шифры могут работать в режимах, позволяющих им обрабатывать фрагменты данных произвольного размера. В таком режиме блочный шифр действует как потоковый шифр. Шифр в режиме счетчика (counter, CTR) -- лучший выбор для потокового шифра. Его характеристики производительности сопоставимы с режимом CBC, но он не требует дополнения или фрагментации.

Векторы инициализации

Вектор инициализации (initialization vector, IV) -- это "фиктивный" блок данных, используемый для запуска блочного шифра. IV необходим, чтобы заставить шифр производить уникальный поток выходных данных независимо от одинакового ввода. IV не нужно держать в секрете, хотя он должен отличаться при каждой новой инициализации шифра с тем же ключом. Повторное использование IV вызывает утечку информации в CBC-шифре только в ограниченном числе сценариев; однако оно серьезно ухудшает безопасность других блочных шифров. Как общее правило, повторное использование IV следует считать уязвимостью безопасности.

Алгоритмы обмена ключами

Протоколы обмена ключами могут становиться сложными, поэтому этот раздел дает лишь несколько простых моментов, которые нужно держать в голове. Во-первых, реализация должна использовать стандартный протокол обмена ключами, например RSA, Diffie-Hellman или El Gamal. Эти алгоритмы прошли широкую проверку и дают наилучшую степень уверенности.

Следующая забота состоит в том, чтобы обмен ключами выполнялся безопасным образом; это означает, что обе стороны коммуникации должны предоставлять некоторые средства идентификации для предотвращения атак "человек посередине". Все упомянутые ранее алгоритмы обмена ключами предоставляют связанные алгоритмы подписи, которые можно использовать для проверки обеих сторон соединения. Эти алгоритмы требуют, чтобы обе стороны уже обменялись открытыми ключами или чтобы эти ключи были доступны через некоторый доверенный источник, например сервер инфраструктуры открытых ключей (Public Key Infrastructure, PKI).

Распространенные уязвимости шифрования

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

Ненужное хранение чувствительных данных

Часто проект хранит чувствительные данные без реальной причины, обычно из-за неправильного понимания требований системы. Например, проверка пароля не требует хранения пароля в извлекаемой форме. Можно безопасно хранить хеш пароля и использовать его для сравнения. Если это сделано правильно, такой метод предотвращает раскрытие настоящего пароля. (Не беспокойтесь, если вы не знакомы с хешами; они вводятся далее в этой главе, в разделе "Хеш-функции".)

Пароли в открытом тексте -- один из самых типичных случаев ненужного хранения данных, но далеко не единственный пример этой проблемы. Некоторые проекты приложений не классифицируют чувствительную информацию должным образом или просто хранят ее без понятной причины. Настоящая проблема в том, что любой проект должен правильно классифицировать чувствительность своих данных и хранить чувствительные данные только тогда, когда это абсолютно необходимо.

Отсутствие необходимого шифрования

В общем случае система не обеспечивает достаточную конфиденциальность, если она спроектирована для передачи открытой информации через публично доступное хранилище, сети или незащищенные сегменты общей памяти. Например, использование TELNET для обмена чувствительной информацией почти наверняка было бы проектной уязвимостью, связанной с конфиденциальностью, потому что TELNET не шифрует свой канал связи.

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

Недостаточное или устаревшее шифрование

Безусловно возможно использовать шифрование, которое по проекту недостаточно сильно, чтобы обеспечить требуемый уровень безопасности данных. Например, одиночное 56-битное шифрование Digital Encryption Standard (DES), вероятно, плохой выбор в нынешнюю эпоху дешевых многогигагерцовых компьютеров. Помните, что атакующие могут записывать зашифрованные данные, и если эти данные достаточно ценны, они могут переждать, пока вычислительная мощность вырастет. В конце концов они смогут купить 128-q-битный квантовый компьютер в Radio Shack, и ваши данные станут их (при условии, что ученые вылечат проблему старения к 2030 году и все будут жить вечно).

Если отложить шутки в сторону, важно помнить, что реализации шифрования со временем стареют. Компьютеры становятся быстрее, а математики находят хитрые новые дыры в алгоритмах так же, как аудиторы кода находят их в программном обеспечении. Всегда отмечайте алгоритмы и размеры ключей, недостаточные для данных, которые они защищают. Конечно, эта забота является движущейся целью, поэтому лучшее, что можно сделать, -- следить за актуальными рекомендованными стандартами. Организации вроде National Institute for Standards and Technology (NIST; www.nist.gov) хорошо публикуют общепринятые критерии для алгоритмов и размеров ключей.

Обфускация данных и шифрование данных

Некоторые приложения -- и даже общеотраслевые стандарты безопасности -- похоже, не различают обфускацию данных и шифрование данных. Проще говоря, данные обфусцированы, когда у атакующих есть доступ ко всей информации, необходимой для восстановления закодированных чувствительных данных. Такая ситуация обычно возникает, когда метод кодирования данных не включает уникальный ключ или ключ хранится в том же домене доверия, что и данные. Два распространенных примера методов кодирования, не включающих уникальный ключ, -- текстовое кодирование ROT13 и простые XOR-механизмы.

Проблема ключей, хранящихся в том же контексте, что и данные, немного более запутанна, но не обязательно менее распространена. Например, многие приложения обработки платежей хранят чувствительную информацию держателей счетов в своих базах данных в зашифрованном виде, но всем обрабатывающим приложениям нужны ключи. Это требование означает, что кража резервных носителей может не дать атакующим данные счетов, но компрометация любого платежного сервера может дать им ключ вместе с зашифрованными данными. Конечно, можно добавить еще один ключ для защиты первого ключа, но всем обрабатывающим приложениям все равно понадобится доступ. Можно наслаивать сколько угодно ключей, но в итоге это всего лишь техника обфускации, потому что каждому обрабатывающему приложению нужно расшифровывать чувствительные данные.

Примечание

Требование безопасности данных PCI (Payment Card Industry) 1.0 является частью общеотраслевого стандарта, помогающего обеспечить безопасную обработку данных платежных карт и транзакций. Эти требования -- дальновидный шаг для отрасли, и многие из них согласуются с лучшими практиками безопасности. Однако стандарт содержит требования, создающие именно ту проблему конфиденциальности, которая описана в этой главе. В частности, требования разрешают хранить зашифрованные данные и ключ в одном контексте, если ключ зашифрован другим ключом, находящимся в том же контексте.

Последний момент: безопасность через сокрытие (или обфускацию) за последние годы заслужила плохую репутацию. Сама по себе это недостаточная техника защиты данных от атакующих; она просто не обеспечивает достаточно сильный уровень конфиденциальности. Однако на практике обфускация может быть ценным компонентом любой политики безопасности, потому что отпугивает случайных любопытствующих и часто может замедлить целеустремленных атакующих.

Целостность

Глава 1 определяла целостность как ожидание, что только уполномоченные стороны способны изменять данные. Это требование, как и конфиденциальность, обычно реализуется через механизмы контроля доступа. Однако дополнительные меры необходимо принимать, когда коммуникация выполняется по небезопасному каналу. В таких случаях для обеспечения целостности данных используются некоторые криптографические методы, обсуждаемые в следующих разделах.

Хеш-функции

Криптографическая целостность данных обеспечивается разными методами, хотя хеш-функции лежат в основе большинства подходов. Хеш-функция (или "функция дайджеста сообщения") принимает вход переменной длины и генерирует выход фиксированного размера. Эффективность хеш-функции измеряется прежде всего тремя требованиями. Первое -- она не должна быть обратимой, то есть определение входа только на основе выхода должно быть вычислительно неосуществимым. Это требование известно как требование "отсутствия прообраза" (no pre-image). Второе требование -- функция не должна иметь второго прообраза, то есть при наличии входа и выхода генерация другого входа с тем же выходом должна быть вычислительно неосуществимой. Последнее и самое сильное требование -- хеш должен быть относительно свободен от коллизий, то есть намеренная генерация одинакового выхода для разных входов должна быть вычислительно неосуществимой.

Хеш-функции дают основу большинства программных средств защиты целостности. Их можно использовать для связывания произвольного набора данных с уникальным значением фиксированного размера. Эта связь может использоваться, чтобы не хранить чувствительные данные и значительно уменьшить объем хранения, требуемый для проверки фрагмента данных. Самые простые формы хеш-функций -- процедуры циклического избыточного контроля (cyclic redundancy check, CRC). Они быстры и эффективны и дают умеренную степень защиты от непреднамеренного изменения данных. Однако CRC-функции неэффективны против намеренного изменения, что делает их непригодными для целей безопасности. Популярные CRC-функции включают CRC-16, CRC-32 и Adler-32.

Следующий шаг после CRC-функций -- криптографические хеш-функции. Они гораздо более вычислительно затратны, но дают высокую степень защиты от намеренного и непреднамеренного изменения. Популярные хеш-функции включают SHA-1, SHA-256 и MD5. (Проблемы с MD5 подробнее обсуждаются далее в этой главе, в разделе "Атаки с подменой".)

Значения соли

Значения соли во многом похожи на векторы инициализации. "Соль" -- это случайное значение, добавляемое к сообщению, чтобы два сообщения не создавали одно и то же значение хеша. Как и IV, значение соли не должно дублироваться между сообщениями. Значение соли должно храниться вместе с хешем, чтобы дайджест можно было корректно восстановить для сравнения. Однако, в отличие от IV, значение соли в большинстве обстоятельств следует защищать.

Значения соли чаще всего используются для предотвращения атак на дайджесты сообщений, основанных на предварительном вычислении. Большинство методов хранения паролей используют соленое значение хеша для защиты от этой проблемы. В атаке предварительного вычисления атакующие строят словарь всех возможных значений дайджеста, чтобы определить исходное значение данных. Этот метод работает только для довольно небольших диапазонов входных значений, таких как пароли; однако он может быть чрезвычайно эффективным.

Рассмотрим значение соли из 32 случайных битов, примененное к произвольному паролю. Такая соль увеличивает размер словаря предварительного вычисления паролей в четыре миллиарда раз относительно исходного значения (2^32). Получившийся словарь предварительного вычисления, вероятно, был бы слишком большим даже для небольшого подмножества паролей. Rainbow tables, разработанные Филиппом Окслином, -- реальный пример того, как отсутствие значения соли оставляет хеши паролей уязвимыми к атакам предварительного вычисления. Rainbow tables можно использовать для взлома большинства хешей паролей за секунды, но техника работает только если хеш не включает значение соли. Дополнительную информацию о rainbow tables можно найти на сайте проекта RainbowCrack: http://www.antsight.com/zsl/rainbowcrack/.

Проверка отправителя

Хеш-функции предоставляют метод проверки содержимого сообщения, но не могут проверить источник сообщения. Проверка источника сообщения требует включения некоторой формы закрытого ключа в операцию хеширования; такой тип функции известен как код аутентификации сообщения на основе хеша (hash-based message authentication code, HMAC). MAC -- это функция, возвращающая значение фиксированной длины, вычисленное из ключа и сообщения переменной длины.

HMAC -- относительно быстрый метод проверки содержимого и отправителя сообщения с использованием общего секрета. К сожалению, у HMAC та же слабость, что и у любой системы с общим ключом: атакующий может выдать себя за любую сторону разговора, скомпрометировав ключ только одной стороны.

Криптографические подписи

Криптографическая подпись -- это метод связывания дайджеста сообщения с конкретным открытым ключом путем шифрования дайджеста сообщения открытым и закрытым ключом отправителя. Затем любой получатель может расшифровать дайджест сообщения с помощью открытого ключа отправителя и сравнить получившееся значение с вычисленным дайджестом сообщения. Такое сравнение доказывает, что отправитель сообщения должен был иметь доступ к закрытому ключу.

Распространенные уязвимости целостности

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

Атаки с подменой

Широко используемые хеш-функции должны проходить серьезное публичное изучение. Однако со временем в них обычно появляются слабости, которые могут привести к эксплуатируемым уязвимостям. Атака с подменой обычно является одной из первых слабостей, обнаруживаемых в стареющей хеш-функции. Эта атака использует склонность слабой хеш-функции генерировать коллизии на определенных диапазонах входа. Делая это, атакующий может создать два входа, которые генерируют одно и то же значение.

Например, допустим, у вас есть банковское приложение, принимающее запросы на перевод средств. Приложение получает запрос и, если средства доступны, подписывает перевод и передает его дальше. Если хеш-функция уязвима, атакующие могут сгенерировать два перевода средств, создающие один и тот же дайджест. Первый запрос будет иметь небольшое значение, а второй -- гораздо большее. Затем атакующие могут открыть счет с минимальным балансом и добиться утверждения меньшего перевода. После этого они передадут больший запрос следующей системе и закроют свои счета до того, как кто-либо поймет, что произошло.

Атаки с подменой стали популярной темой в последнее время, потому что SHA-1 и MD5 начинают показывать признаки износа. Потенциал коллизионных уязвимостей в MD5 был выявлен еще в 1996 году, но только в августе 2004 года Сяоюнь Ван, Дэнго Фэн, Сюэцзя Лай и Хунбо Юй опубликовали работу, описывающую успешные коллизии с алгоритмом MD5. В марте 2005 года за этой работой последовала публикация Арьена Ленстры, Сяоюнь Ван и Бенне де Вегера. Они успешно сгенерировали сталкивающуюся пару сертификатов X.509 с разными открытыми ключами, то есть в формате сертификатов, используемом в SSL-транзакциях. Позднее, в марте 2006 года, Властимил Клима опубликовал алгоритм, способный находить MD5-коллизии за чрезвычайно короткое время.

Семейство алгоритмов SHA также находится под пристальным вниманием. Был выявлен ряд потенциальных атак против SHA-0; однако SHA-0 быстро был заменен SHA-1 и никогда не получил значительного развертывания. Исследования атак SHA-0 дали основу для выявления уязвимостей в алгоритме SHA-1, хотя на момент написания этой книги никто успешно не сгенерировал SHA-1-коллизию. Однако эти проблемы заставили несколько крупных органов стандартизации (например, американский NIST) начать постепенный отказ от SHA-1 в пользу SHA-256 (также известного как SHA-2).

Конечно, находить случайные коллизии намного труднее, чем находить коллизии, пригодные для атаки с подменой. Однако по своей природе криптографические алгоритмы следует выбирать с расчетом на то, что их безопасность будет жизнеспособна значительно дольше срока жизни применимой системы. Это рассуждение объясняет сдвиг последних лет от хеш-алгоритмов, ранее считавшихся относительно безопасными. Влияние этого сдвига видно даже в приложениях хеширования паролей, которые напрямую не подвержены атакам на основе коллизий, но также переводятся на более сильные хеш-функции.

Доступность

Глава 1 определяла доступность как способность использовать ресурс тогда, когда это ожидается. Это ожидание доступности чаще всего связывают с надежностью, а не с безопасностью. Однако есть целый ряд ситуаций, в которых доступность системы следует рассматривать как требование безопасности.

Распространенные уязвимости доступности

С отказом доступности связан только один общий тип уязвимости -- уязвимость отказа в обслуживании (denial-of-service, DoS). DoS-уязвимость возникает, когда атакующий может сделать систему недоступной, выполнив некоторое непредусмотренное действие.

Влияние DoS-атаки может сильно зависеть от ситуации, в которой она происходит. Критическая система может включать ожидание постоянной доступности, и простои будут представлять неприемлемый бизнес-риск. Это часто относится к ключевым бизнес-системам, таким как централизованные системы аутентификации или флагманские веб-сайты. В обоих случаях успешная DoS-атака может прямо соответствовать значительной потере выручки из-за неспособности бизнеса нормально функционировать без системы.

Недостаток доступности также представляет риск безопасности, когда простой вынуждает удовлетворять требования менее безопасным образом. Например, рассмотрим систему точек продаж (point-of-sale, PoS), которая обрабатывает все транзакции по кредитным картам через центральный сервер сверки. Когда сервер сверки недоступен, PoS-система должна локально ставить все транзакции в очередь и выполнять их позднее. У атакующего может быть множество причин вызвать DoS между PoS-системой и сервером сверки. Состояние DoS может позволить атакующему совершать покупки с украденными или недействительными кредитными картами либо может раскрыть поставленную в очередь информацию держателей карт на менее безопасной PoS-системе.

Моделирование угроз

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

В этой главе используется конкретный тип моделирования угроз, состоящий из пятифазного процесса:

• Сбор информации

• Моделирование архитектуры приложения

• Выявление угроз

• Документирование результатов

• Приоритизация анализа реализации

Этот процесс наиболее эффективно применять на фазе проектирования (или рефакторинга) разработки и обновлять по мере внесения изменений на более поздних фазах разработки. Однако его можно полностью интегрировать и на более поздних фазах SDLC. Его также можно применять после разработки для оценки потенциальной экспозиции приложения. Выбранная фаза зависит от ваших собственных требований, но помните, что анализ проектирования -- лишь компонент полной проверки приложения. Поэтому убедитесь, что вы учитываете требования к выполнению анализа реализации и эксплуатационного анализа итоговой системы.

Такой подход к моделированию угроз должен помочь установить рамку для связи многих уже изученных понятий. Этот процесс также может служить дорожной картой для применения многих концепций в оставшейся части книги. Однако нужно сохранять готовность адаптировать подход и изменять эти техники по мере необходимости, чтобы они соответствовали разным ситуациям. Помните: процессы и методологии могут быть хорошими слугами, но плохими хозяевами.

Примечание

Этот процесс моделирования угроз был первоначально представлен в книге Writing Secure Code, 2nd Edition (Microsoft Press, 2002) Майкла Ховарда и Дэвида Ле Блана. Позднее он был расширен и уточнен в книге Threat Modeling (Microsoft Press, 2004) Фрэнка Свидерски и Виндо Снайдер.

Сбор информации

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

• Активы. Активы включают все в системе, что может иметь ценность для атакующих. Это могут быть данные, содержащиеся в приложении или подключенной базе данных, например таблица базы данных с учетными записями и паролями пользователей. Активом также может быть доступ к некоторому компоненту приложения, например возможность выполнить произвольный код на целевой системе.

• Точки входа. Точки входа включают любой путь, через который атакующий может получить доступ к системе. Они включают любую функциональность, раскрытую через такие средства, как слушающие порты, конечные точки Remote Procedure Call (RPC), отправленные файлы или любая активность, инициируемая клиентом.

• Внешние сущности. Внешние сущности взаимодействуют с системой через ее точки входа. Эти сущности включают все классы пользователей и внешние системы, взаимодействующие с приложением.

• Внешние уровни доверия. Внешние уровни доверия относятся к привилегиям, предоставленным внешней сущности, как обсуждалось ранее в этой главе в разделе "Отношения доверия". Сложная система может иметь несколько уровней внешнего доверия, связанных с разными сущностями, тогда как простое приложение может иметь не более чем понятия локального и удаленного доступа.

• Основные компоненты. Основные компоненты определяют структуру проекта приложения. Компоненты могут быть внутренними для приложения или представлять внешние модульные зависимости. Процесс моделирования угроз включает декомпозицию этих компонентов для изоляции их соображений, связанных с безопасностью.

• Сценарии использования. Сценарии использования охватывают все потенциальные применения системы. Они включают список как авторизованных, так и неавторизованных сценариев.

Интервью с разработчиками

Во многих ситуациях можно сэкономить много времени, обратившись, так сказать, прямо к первоисточнику. Поэтому если у вас есть доступ к разработчикам, обязательно используйте его в своих интересах. Конечно, такой вариант может быть недоступен. Например, независимый исследователь уязвимостей редко имеет доступ к разработчикам приложения.

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

Документация разработчиков

Хорошо документированное приложение может сделать процесс проверки быстрее и тщательнее; однако у этого удобства есть один важный подвох. Всегда следует осторожно относиться к любой проектной документации существующей реализации. Причина такой осторожности обычно не в нечестных или некомпетентных разработчиках; просто в процессе реализации меняется слишком много вещей, чтобы результат когда-либо идеально совпал со спецификациями.

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

Помня об этой оговорке, вам все равно нужно знать, как выжать максимум из полученной документации. В общем случае вам нужно все, до чего можно добраться: проектная документация (диаграммы, спецификации протоколов, документация API и т. п.), документация развертывания (руководства по установке, примечания к выпуску, дополнительная информация о конфигурации и т. д.) и документация конечного пользователя. При проверках бинарных файлов (и некоторого исходного кода) документация конечного пользователя -- все, что можно получить, но не недооценивайте ее ценность. Эта документация является литературой, "обращенной к клиенту", поэтому обычно она довольно точна и может дать процессно-ориентированный взгляд, который облегчает понимание системы.

Документация стандартов

Если вас просят исследовать приложение, использующее стандартизованные сетевые протоколы или форматы файлов, хорошее понимание структуры этих протоколов и форматов файлов необходимо, чтобы знать, как приложение должно функционировать и какие недостатки могут существовать. Поэтому полезно получить любые опубликованные стандарты и связанную документацию, созданную исследователями и авторами. Обычно документы стандартов, связанных с Интернетом, доступны как requests for comments (RFC, доступны на www.ietf.org/rfc/). Открытые реализации тех же стандартов могут быть особенно полезны для прояснения неоднозначностей, с которыми можно столкнуться при исследовании технологии, используемой целевым приложением.

Профилирование исходного кода

Доступ к исходному коду может быть чрезвычайно полезен при сборе информации о приложении. На этой фазе не нужно уходить слишком глубоко, но наличие исходного кода может ускорить значительную часть начального процесса моделирования. Исходный код можно использовать для первичной проверки документации, а общую структуру приложения можно определить по иерархиям классов и модулей в коде. Когда исходный код не выглядит иерархически организованным, можно посмотреть на запуск приложения, чтобы определить, как основные компоненты различаются при инициализации. Также можно выявлять точки входа, бегло просматривая код в поиске распространенных функций и объектов, таких как listen() или ADODB.

Профилирование системы

Профилирование системы требует доступа к функциональной установке приложения, что дает возможность проверить обзор документации и выявить элементы, которые документация пропустила. Модели угроз, выполняемые строго по документации, должны пропустить этот шаг и полностью проверять модель во время анализа реализации.

Для профилирования приложения можно использовать разные методы. Вот несколько распространенных техник:

• Структура файловой системы. Посмотрите на структуру файловой системы приложения и отметьте любую важную информацию. Эта информация включает выявление структуры разрешений, перечисление всех исполняемых модулей и выявление любых релевантных файлов данных.

• Повторное использование кода. Ищите компоненты приложения, которые могли прийти из другой библиотеки или пакета, например встроенные веб-серверы или библиотеки шифрования. Эти компоненты могут иметь собственную уникальную поверхность атаки и требовать дальнейшей проверки.

• Импорты и экспорты. Перечислите таблицы импорта и экспорта функций для каждого модуля. Внимательно ищите любые библиотеки, используемые для установления или управления внешними соединениями либо RPC-интерфейсами.

• Песочница. Запускайте приложение в песочнице, чтобы выявить каждый объект, к которому оно обращается, и каждое действие, которое оно выполняет. Используйте сниффер и прокси приложений, чтобы записать любой сетевой трафик и изолировать коммуникацию. В средах Windows для этой активности полезны утилиты Filemon, Regmon, WinObj и Process Explorer (с www.sysinternals.com).

• Сканирование. Исследуйте приложение на любых слушающих портах, RPC-интерфейсах или похожих внешних интерфейсах. Попробуйте получать баннеры, чтобы проверить используемые протоколы и выявить требования аутентификации. Для HTTP-приложений попробуйте обходить ссылки и выявлять как можно больше уникальных точек входа.

Моделирование архитектуры приложения

После того как у вас появилась некоторая исходная информация, нужно начать исследовать архитектуру приложения. Эта фаза включает знакомство с тем, как структурировано программное обеспечение и какие компоненты могут влиять на его общую безопасность. Эти шаги помогают выявить проектные вопросы и понять, где сосредоточить усилия во время анализа реализации. Вы строите это знание, просматривая существующую документацию модели приложения и разрабатывая новые модели по мере необходимости. Каждое программное обеспечение в некоторой степени моделируется во время разработки; единственная разница в том, фиксируются ли модели когда-либо формально. Поэтому нужно понимать распространенные типы моделирования и то, как можно разработать собственные.

Unified Markup Language

Unified Markup Language (UML) -- это спецификация, разработанная Object Management Group (OMG; www.omg.org/uml/) для описания многих разных аспектов работы приложения на довольно высоком уровне. Она включает диаграммы для описания потока информации, взаимодействия между компонентами, разных состояний, в которых может находиться приложение, и многого другого. На этой фазе особый интерес представляют диаграммы классов, диаграммы компонентов и сценарии использования. Следующий список кратко описывает эти типы диаграмм, чтобы дать представление о том, что они пытаются передать. Если вы незнакомы с UML, настоятельно рекомендуется взять одну из множества доступных книг по этой теме. Из-за сложности UML его глубокое объяснение далеко выходит за рамки этой главы.

Примечание

UML прошел несколько ревизий. Текущий принятый стандарт -- UML 2.0.

• Диаграммы классов. Диаграмма классов -- это UML-диаграмма для моделирования объектно-ориентированного (OO) решения. Каждый класс объектов представлен прямоугольником, включающим методы и атрибуты класса. Отношения между объектами затем представлены линиями между классами. Линии со стрелками на одном конце определяют родителей в иерархии наследования; линии без украшений (без стрелок) с числами у концов указывают отношение кардинальности.

Диаграммы классов могут быть полезны, когда вы пытаетесь понять отношения в сложном модуле. По сути, они явно показывают, как смоделировано приложение и как классы взаимодействуют друг с другом. Однако реалистично вы не будете встречать их слишком часто, если не выполняете внутренние проверки кода. Анализируя OO-решение, можно приблизительно построить диаграммы классов. Хотя это может казаться пустой тратой времени, они могут быть полезны, когда нужно вернуться и позднее проверить то же ПО или когда вы выполняете начальную высокоуровневую проверку, а затем передаете разные задачи аудита кода другим участникам команды.

• Диаграммы компонентов. Диаграммы компонентов делят решение на составляющие компоненты, а соединители показывают, как они взаимодействуют друг с другом. Компонент определяется как непрозрачная подсистема, предоставляющая независимую функцию для решения. Примеры компонента включают базу данных, некоторый парсер, систему заказов и так далее. Диаграмма компонентов дает менее сложный взгляд на систему, чем диаграммы классов, потому что компоненты обычно представляют завершенную самодостаточную подсистему, часто реализованную множеством классов и модулей.

Диаграмма компонентов раскрывает интерфейсы (обозначаемые выступающими окружностями) и использует интерфейсы других компонентов (обозначаемые пустым полукругом). Компоненты связываются через эти раскрытия интерфейсов или посредством линий ассоциации, которые показывают, что два компонента изначально взаимосвязаны и не полагаются на раскрытые интерфейсы. Диаграммы компонентов также позволяют соединять два компонента через реализацию. Реализация просто означает, что функциональность, требуемая одним компонентом, является подмножеством функциональности, раскрытой интерфейсом другого компонента. Реализация представляется пунктирной линией.

В оценке диаграмма компонентов может быть ценной для определения высокоуровневого взгляда на систему и ее межкомпонентные отношения. Она особенно полезна, когда вы пытаетесь разработать начальный контекст модели угроз, потому что устраняет значительную часть сложности системы и позволяет сосредоточиться на общей картине.

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

Диаграммы потоков данных

Ряд инструментов диаграммирования может помочь понять систему, но диаграмма потоков данных (data flow diagram, DFD) -- одна из самых эффективных для целей безопасности. Эти диаграммы используются для отображения того, как данные перемещаются через систему, и для выявления любых затронутых элементов. Если все сделано правильно, процесс DFD-моделирования учитывает не только функциональность приложения, раскрытую напрямую внешним источникам, но и функциональность, раскрытую косвенно. Этот процесс моделирования также учитывает смягчающие факторы в проекте системы, например дополнительные меры безопасности, принудительно соблюдающие границы доверия. Рисунок 2-2 показывает пять основных элементов DFD, которые суммированы в следующем списке:

Рисунок 2-2. Элементы DFD

• Процессы. Процессы -- это непрозрачные логические компоненты с хорошо определенными требованиями к входу и выходу. Они представлены окружностью, а группы связанных процессов представлены окружностью с двойной границей. Несколько групп процессов можно далее декомпозировать в дополнительных DFD для каждого отдельного процесса. Хотя процессы обычно не являются активами, в некоторых контекстах они могут ими быть.

• Хранилища данных. Хранилища данных -- это информационные ресурсы, используемые системой, например файлы и базы данных. Они представлены открытыми прямоугольными блоками. Обычно все, что представлено таким образом в DFD, считается системным активом.

• Внешние сущности. Эти элементы, ранее описанные в разделе "Сбор информации", -- это "акторы" и удаленные системы, которые взаимодействуют с системой через ее точки входа. Они представлены закрытыми прямоугольниками. Выявление внешних сущностей помогает быстро изолировать точки входа системы и определить, какие активы доступны извне. Внешние сущности также могут представлять активы, которые нужно защищать, например удаленный сервер.

• Поток данных. Поток данных представлен стрелками. Он показывает, какие данные отправляются через какие части системы. Эти элементы могут быть полезны для обнаружения того, какие пользовательские данные могут достигать определенных компонентов, чтобы нацелить их в анализе реализации.

• Граница доверия. Границы доверия -- это границы между разными сущностями в системе или между целыми системами. Они представлены пунктирной линией между двумя компонентами.

Рисунок 2-3 показывает, как можно использовать элементы DFD для моделирования системы. Он представляет упрощенную модель базового веб-приложения, позволяющего пользователям входить в систему и получать доступ к ресурсам, хранящимся в базе данных. Конечно, DFD выглядят по-разному на разных уровнях приложения. Простая высокоуровневая DFD, инкапсулирующая большую систему, называется контекстной диаграммой. Пример веб-сайта является контекстной диаграммой, потому что представляет высокоуровневую абстракцию, инкапсулирующую сложную систему.

Рисунок 2-3. Контекстная диаграмма DFD

Однако ваш анализ обычно требует дальнейшей декомпозиции системы. Каждый следующий уровень декомпозиции нумеруется, начиная с нуля. Диаграмма уровня 0 выявляет основные подсистемы приложения. Основные подсистемы в этом веб-приложении различаются по состоянию аутентификации пользователя. Это различие представлено на диаграмме уровня 0 на рисунке 2-4.

Рисунок 2-4. DFD-диаграмма уровня 0 процесса входа

В зависимости от сложности системы может понадобиться продолжить декомпозицию. Рисунок 2-5 -- диаграмма уровня 1 процесса входа веб-приложения. Обычно вы переходите дальше диаграмм уровня 0 только при моделировании сложных подсистем. Однако эта диаграмма уровня 1 дает полезную отправную точку для использования DFD с целью изоляции уязвимостей проектирования.

Рисунок 2-5. DFD-диаграмма уровня 0 процесса входа

При подготовке к анализу реализации можно использовать эти диаграммы для моделирования поведения приложения и изоляции компонентов. Например, рисунок 2-6 показывает процесс входа, слегка измененный. Видите, где уязвимость? Способ обработки недействительного входа изменен так, что теперь процесс входа возвращает результат каждой фазы напрямую клиенту. Измененный процесс уязвим, потому что атакующие могут выявлять действительные имена пользователей без успешного входа, что может быть чрезвычайно полезно при попытке brute-force-атаки на систему аутентификации.

Рисунок 2-6. DFD, показывающая уязвимость входа

Диаграммируя эту систему, можно легче выявить ее компоненты безопасности. В этом примере это помогло изолировать уязвимость в том, как система выполняет аутентификацию. Конечно, пример входа все еще довольно прост; более сложная система может иметь несколько уровней сложности, которые нужно инкапсулировать в нескольких DFD. Вероятно, вы не захотите моделировать все эти уровни, но следует декомпозировать разные компоненты до точки, где изолируются соображения, значимые для безопасности. К счастью, существуют инструменты, помогающие в этом процессе. Приложения диаграммирования, такие как Microsoft Visio, полезны, а Microsoft Threat Modeling Tool особенно помогает в этом процессе.

Выявление угроз

Выявление угроз -- это процесс определения экспозиции безопасности приложения на основе ваших знаний о системе. Эта фаза строится на работе, выполненной на предыдущих фазах, применяя ваши модели и понимание системы для определения того, насколько она уязвима для внешних сущностей. На этой фазе используется новый инструмент моделирования под названием деревья атак (или деревья угроз), который предоставляет стандартизованный подход к выявлению и документированию потенциальных векторов атаки в системе.

Построение дерева атак

Структура дерева атак довольно проста. Оно состоит из корневого узла, описывающего цель атакующего, и ряда дочерних узлов, указывающих способы достижения этой цели. Каждый уровень дерева разбивает шаги на более подробные элементы, пока у вас не появляется реалистичная карта того, как атакующий может эксплуатировать систему. Используя пример простого веб-приложения из предыдущего раздела, предположим, что оно используется для хранения персональной информации. Рисунок 2-7 показывает высокоуровневое дерево атак для этого приложения.

Рисунок 2-7. Пример дерева атак

Как видно, корневой узел находится сверху, а под ним несколько дочерних узлов. Каждый дочерний узел формулирует методологию атаки, которую можно использовать для достижения цели, указанной в корневом узле. Этот процесс по необходимости дальше декомпозируется в дочерние узлы, которые в итоге определяют атаку. Глядя на эту диаграмму, вы должны начать замечать сходство между деревьями атак и DFD. В конце концов, дерево атак не создается в вакууме. Лучше всего строить его, проходя по DFD и используя дерево атак для фиксации конкретных опасений. Например, обратите внимание, как ветвь, ведущая к дочернему узлу 1.2.1, следует тому же шаблону рассуждения, который ранее использовался при анализе DFD дефектного процесса входа.

Как и с DFD, продолжать декомпозицию деревьев атак нужно только вдоль путей, значимых для безопасности. Нужно использовать собственное суждение и определять, какие пути являются разумными векторами атаки, а какие маловероятны. Однако прежде чем перейти к этой теме, обратимся к следующему разделу с более подробным описанием структуры дерева атак.

Типы узлов

Возможно, вы заметили странные отметки на линиях, соединяющих каждый узел с его потомками (например, узлы 1.2.1.1 и 1.2.1.2). Дуга между этими соединителями узлов указывает, что дочерние узлы являются AND-узлами, то есть для продолжения оценки вектора должны быть выполнены оба условия дочерних узлов. Узел без дуги -- это просто OR-узел, то есть по любой ветви можно пройти без дополнительного условия. Обращаясь к рисунку 2-7, посмотрите на вектор brute-force-входа в узле 1.2.1. Чтобы пройти дальше этого узла, нужно выполнить условия в двух дочерних узлах:

• Определить имя пользователя

• Определить пароль пользователя

Ни один шаг нельзя опустить. Имя пользователя без пароля бесполезно, и пароль без связанного имени пользователя столь же бесполезен. Поэтому узел 1.2.1 является AND-узлом.

Напротив, OR-узлы описывают случаи, в которых цель может быть достигнута выполнением любого одного из дочерних узлов. Поэтому для продолжения оценки дочерних узлов должно быть выполнено условие всего одного узла. Снова обращаясь к рисунку 2-7, посмотрите на цель "Войти как целевой пользователь" в узле 1.2. Эта цель может быть достигнута любым из следующих подходов:

• Brute-force-вход

• Кража учетных данных пользователя

Чтобы войти как пользователь, не нужно достигать обеих целей; нужно достичь только одной. Поэтому это OR-узлы.

Текстовое представление

Деревья атак можно представлять текстом так же, как и графикой. Текстовые версии передают ту же информацию, что и графические, но иногда их не так легко визуализировать (хотя они компактнее). Следующий пример показывает, как можно представить дерево атак с рисунка 2-7 в текстовом формате:

1. Противник получает доступ к персональной информации пользователя OR 1.1 Получить прямой доступ к базе данных 1.1.1 Эксплуатировать дыру в системном приложении или ядре 1.2 Войти как целевой пользователь OR 1.2.1 Brute-force-вход AND 1.2.1.1 Определить имя пользователя 1.2.1.2 Определить пароль пользователя 1.2.2 Украсть учетные данные пользователя 1.3 Перехватить пользовательский сеанс 1.3.1 Украсть cookie пользовательского сеанса 1.4 Пассивно перехватить персональные данные AND 1.4.1 Определить начало соединения пользователя 1.4.2 Прослушивать сетевой трафик в поиске персональных данных

Как видно, присутствует вся та же информация. Сначала цель корневого узла указывается как заголовок дерева атак, а его непосредственные потомки нумеруются и располагаются с отступом под заголовком. Каждый новый уровень снова получает отступ и нумеруется под родительским узлом таким же образом. Ключевые слова AND и OR используются, чтобы показать, являются ли узлы AND- или OR-узлами.

Смягчение угроз

Часть ценности дерева атак состоит в том, что оно позволяет отслеживать потенциальные угрозы. Однако отслеживание угроз не особенно полезно, если нет способа определить, как они смягчаются. К счастью, деревья атак включают специальный тип узла для решения этой задачи: круглый узел. Рисунок 2-8 показывает пример дерева атак с добавленными смягчающими факторами.

Рисунок 2-8. Дерево атак с узлами смягчения

В это дерево атак добавлены три узла смягчения, помогающие понять, что эти векторы менее вероятны как пути атаки, чем несмягченные ветви. Пунктирные линии, использованные в одном узле смягчения, являются сокращенным способом обозначить ветвь как маловероятный вектор атаки. Это не удаляет ветвь, но побуждает направить внимание в другое место.

Последнее замечание о смягчении: не стоит искать его слишком рано. Выявление смягчающих факторов полезно, потому что может предотвратить преследование маловероятного вектора атаки. Однако нельзя позволить ложному чувству безопасности усыпить вас и заставить пропустить вероятную ветвь. Поэтому рассматривайте смягчение внимательно и обязательно выполняйте некоторую проверку, прежде чем добавлять его в дерево атак.

Документирование результатов

Теперь, когда исследовательская работа выполнена, нужно задокументировать обнаруженное. На фазе документации вы пересмотрите угрозы, найденные на предыдущей фазе, и представите их формальным образом. Для каждой обнаруженной угрозы нужно дать краткое резюме вместе с рекомендациями по устранению угрозы. Чтобы увидеть, как работает этот процесс, используйте угрозу "Brute-force-вход" (узел 1.2.1) из примерного дерева атак. Эта угроза может позволить атакующему войти с учетными данными другого пользователя. Документация резюме угрозы выглядела бы примерно как таблица 2-1.

Таблица 2-1. Резюме угрозы

Вся информация об угрозе brute-force-входа аккуратно суммирована в таблице. В следующей части этой фазы вы расширите эту таблицу, включив дополнительную информацию о риске угрозы.

Рейтинги риска DREAD

Реальные приложения обычно гораздо больше и сложнее как в проекте, так и в реализации, чем примеры, используемые в этой главе. Увеличение размера и сложности создает широкий спектр векторов атаки в разных классах пользователей. В результате обычно можно составить длинный список потенциальных угроз и возможных рекомендаций для их смягчения. В идеальном мире проектировщики могли бы систематически разбираться с каждой угрозой и исправлять потенциальные проблемы, закрывая каждый вектор атаки по мере необходимости. Однако определенные бизнес-реалии могут не позволить смягчить каждый выявленный вектор, и почти наверняка не все сразу. Очевидно, нужна какая-то приоритизация, чтобы помочь разобраться с более серьезными векторами до того, как беспокоиться о менее важных. Назначая угрозе рейтинг серьезности, можно ранжировать каждую найденную угрозу на основе риска, который она представляет для безопасности приложения и связанных систем. Затем этот рейтинг можно использовать как ориентир для разработчиков, помогая решать, какие проблемы имеют приоритет.

Угрозы можно оценивать множеством разных способов. Самое важное -- включить экспозицию угрозы (насколько легко ее эксплуатировать и кому доступен вектор) и объем ущерба при успешной эксплуатации. Помимо этого, можно добавить компоненты, более релевантные вашей среде и бизнес-процессам. Для целей моделирования угроз в этой главе используется рейтинговая система DREAD, разработанная Microsoft. Ни одна модель не идеальна, но эта дает довольно хороший баланс общепринятых характеристик угроз. Эти характеристики кратко суммированы ниже:

• Потенциал ущерба. Каковы последствия, если угроза успешно эксплуатирована?

• Воспроизводимость. Насколько легко воспроизвести рассматриваемую атаку?

• Эксплуатируемость. Насколько трудно выполнить атаку?

• Затронутые пользователи. Если успешная атака выполнена, сколько пользователей будет затронуто и насколько они важны?

• Обнаруживаемость. Насколько трудно заметить уязвимость?

Каждой категории можно назначить оценку от 1 до 10 (1 -- самая низкая, 10 -- самая высокая). Затем оценки категорий суммируются и делятся на 5 для общего рейтинга угрозы. Рейтинг 3 или ниже можно считать угрозой низкого приоритета, от 4 до 7 -- угрозой среднего приоритета, а 8 или выше -- угрозой высокого приоритета.

Примечание

Модель DREAD также полезна для оценки уязвимостей реализации и эксплуатационных уязвимостей. Фактически DREAD можно использовать как универсальную систему оценки на протяжении всей проверки приложения.

Одно из преимуществ рейтинговой системы DREAD состоит в том, что она дает диапазон детализации, который можно использовать при представлении результатов лицам, принимающим бизнес-решения. Можно дать им краткую оценку угрозы, только с общим рейтингом угрозы и категорией, к которой она относится. Можно также представить более подробную информацию, например отдельные оценки по пяти категориям угроз. Можно даже дать им полный отчет, включая документацию модели и объяснение того, как вы пришли к оценкам по каждой категории. Независимо от выбора полезно иметь информацию на каждом уровне детализации при презентации клиентам или высшему руководству.

Таблица 2-2 -- пример применения рейтинга DREAD к угрозе brute-force-входа.

Таблица 2-2. Резюме угрозы с рейтингом DREAD

Автоматическая документация моделирования угроз

Как видно, процесс моделирования угроз включает довольно много документации (как текста, так и диаграмм). К счастью, Фрэнк Свидерски (соавтор ранее упомянутой книги Threat Modeling) разработал инструмент, помогающий создавать различные документы моделирования угроз. Он доступен для бесплатной загрузки по адресу http://msdn.microsoft.com/security/securecode/threatmodeling/. Инструмент упрощает создание DFD, сценариев использования, резюме угроз, резюме ресурсов, предположений реализации и многих других документов, которые вам понадобятся. Кроме того, документация организована в древовидную структуру, по которой легко перемещаться и которую легко поддерживать. Инструмент может выводить всю вашу документацию как HTML или в другой выбранной форме вывода, используя обработку Extensible Stylesheet Language Transformations (XSLT). Настоятельно рекомендуется познакомиться с этим инструментом для документации моделирования угроз.

Приоритизация анализа реализации

Теперь, когда вы завершили и оценили резюме угроз, наконец можно обратить внимание на структурирование анализа реализации. При разработке модели угроз вы должны были декомпозировать приложение по разным факторам, включая модули, объекты и функциональность. Эти деления должны отражаться в поле Affected Components каждого отдельного резюме угрозы. Следующий шаг -- составить список компонентов на подходящем уровне декомпозиции; какой именно уровень подходит, определяется размером приложения, числом проверяющих, доступным временем проверки и похожими факторами. Однако обычно лучше начинать с высокого уровня абстракции, чтобы рассматривать лишь несколько компонентов. Помимо имен компонентов, в списке нужен еще один столбец для оценок риска, связанных с каждым компонентом.

После получения этого списка компонентов вы просто определяете, к какому компоненту относится резюме угрозы, и добавляете оценку риска этого резюме к связанному компоненту. После суммирования списка резюме у вас будет оценка риска, связанного с каждым компонентом. В общем случае оценку следует начинать с компонента с наивысшей оценкой и продолжать от более высоких оценок к более низким. Также может понадобиться исключить некоторые компоненты из-за ограничений времени, бюджета или других факторов. Поэтому лучше начинать исключение с компонентов с самыми низкими оценками. Этот процесс оценки можно применить к следующему уровню декомпозиции для крупного приложения; хотя это уже начинает переходить в процесс анализа реализации, который подробно рассматривается в главе 4, "Процесс анализа приложения".

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

Итоги

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

Важно не относиться к процессу анализа проектирования как к изолированному компоненту. Результаты анализа проектирования должны естественно переходить в процесс анализа реализации, подробно обсуждаемый в главе 4.

Ответственность за предотвращение таких уязвимостей может находиться где-то между разработчиком и административным персоналом, который развертывает и сопровождает систему. Коробочное коммерческое ПО может возлагать большую часть нагрузки эксплуатационной безопасности на конечных пользователей. И наоборот, встречаются специализированные системы, особенно встроенные устройства и turnkey-системы, настолько плотно упакованные, что разработчики контролируют каждый аспект их конфигурации.

Эта глава сосредоточена на выявлении нескольких типов эксплуатационных уязвимостей и профилактических мер. Конкретные примеры должны помочь понять тонкие шаблоны, способные приводить к таким уязвимостям. Цель -- помочь вам понять, как выявлять эти типы уязвимостей, а не представить энциклопедию потенциальных проблем. Технологии разнообразны и часто меняются, но с небольшой практикой вы сможете замечать общие черты любой эксплуатационной уязвимости, что поможет выработать собственные техники выявления уязвимостей в проверяемых системах.

Экспозиция

При анализе безопасности приложения нужно учитывать влияние среды развертывания. Это может быть просто для внутреннего приложения с известной целью. Популярное коммерческое ПО, напротив, может быть развернуто на множестве операционных систем с неизвестными сетевыми профилями. Рассматривая эксплуатационные уязвимости, нужно выявлять эти вопросы и убеждаться, что они адекватно учтены. Следующие разделы вводят элементы среды приложения, определяющие степень его экспозиции перед разными классами пользователей, которые имеют доступ к приложению и, следовательно, способны его атаковать.

Поверхность атаки

Глава 2, "Анализ проектирования", рассматривала понятия моделирования угроз: активы и точки входа. Эти понятия можно использовать для определения поверхности атаки приложения -- совокупности всех точек входа, предоставляющих доступ к активу. Пока неважно, как этот доступ смягчается; нужно только знать, где находится поверхность атаки.

Для целей этой главы обсуждение моделей доверия и угроз упрощено, потому что эксплуатационные уязвимости обычно возникают, когда поверхность атаки раскрыта без необходимости. Поэтому полезно свернуть сложности в понятие поверхности атаки и просто искать, где ее можно устранить.

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

Небезопасные настройки по умолчанию

Небезопасные настройки по умолчанию -- это просто предварительно сконфигурированные параметры, создающие ненужный риск в развернутом приложении. Такая проблема обычно возникает потому, что поставщик ПО или устройства пытается сделать развертывание максимально простым и безболезненным, что снова возвращает к конфликту между удобством использования и безопасностью.

Любой читатель, у которого есть коммерческая беспроводная точка доступа, вероятно, сталкивался с той же проблемой. Большинство таких устройств предварительно настроены без какой-либо защиты соединения. Обоснование состоит в том, что беспроводная безопасность глючна и трудна в настройке. В какой-то степени это, вероятно, правда, но альтернатива -- раскрыть свои беспроводные коммуникации всем в радиусе нескольких сотен ярдов. Большинство людей предпочли бы потерпеть неудобство борьбы с настройкой, чем раскрыть свои беспроводные коммуникации.

Как проверяющего вас должны больше всего заботить два типа уязвимых настроек по умолчанию. Первый -- настройки приложения по умолчанию, включающие любые параметры, которые могут снизить безопасность или увеличить поверхность атаки приложения без явного согласия пользователя. Эти параметры подробнее обсуждаются далее в главе, но несколько очевидных установочных соображений -- запрос паролей вместо установки значений по умолчанию, включение более безопасных режимов коммуникации и принудительное соблюдение корректного контроля доступа.

Также нужно учитывать настройки по умолчанию базовой платформы и операционной системы. Примеры такой меры включают обеспечение того, что установка задает адекватные разрешения файлов и объектов, или ограничение глаголов, разрешенных в веб-запросе. Процесс может стать немного сложным, если приложение переносимо между разными целями установки, поэтому учитывайте все потенциальные среды развертывания. Фактически один из основных факторов небезопасных настроек по умолчанию в приложении состоит в том, что программа спроектирована и построена для работы на множестве разных операционных систем и сред; безопасная настройка в одной операционной системе может быть не такой безопасной в другой.

Контроль доступа

Глава 2 вводила контроль доступа и то, как он влияет на проект приложения. Однако эффекты контроля доступа не заканчиваются на проектировании. Внутренне приложение может управлять собственными специфическими для приложения механизмами контроля доступа или использовать возможности, предоставляемые платформой. Внешне приложение полностью зависит от средств контроля доступа, предоставляемых хостовой ОС или платформой (эта тема глубже рассматривается далее в главе 9, "Unix I: привилегии и файлы", и главе 11, "Windows I: объекты и файловая система").

Многие разработчики довольно часто пишут сценарии, поэтому на вашей системе, вероятно, установлено несколько движков сценариев. В Windows-системе вы могли заметить, что большинство установок сценарных сред по умолчанию помещаются в каталог прямо от корня. Например, в типичной установке интерпретатора Python на Windows путь установки по умолчанию -- C:\Python24, поэтому он устанавливается прямо от корневого каталога основного жесткого диска (C:). Сам по себе этот путь установки не является проблемой, пока вы не учтете разрешения по умолчанию на системном диске Windows. Эти разрешения позволяют любому пользователю записывать в каталог, созданный от корня (наследование разрешений подробнее объясняется в главе 11). Перейдя в C:\Python24, вы найдете python.exe (среди прочего), а если посмотреть импортируемые динамические библиотеки (DLL), используемые python.exe, вы увидите в списке msvcr71.dll.

Примечание

Для тех, кто незнаком с базовой компоновкой бинарных файлов Windows: импорт -- это требуемая библиотека, содержащая процедуры, необходимые приложению для корректной работы. В этом примере python.exe нужны процедуры, реализованные в библиотеке msvcr71. Точные функции, требуемые python.exe, также указаны в секции imports.

Глава 11 объясняет детали того, как Windows обрабатывает импорты. Для этого обсуждения важно, что вы можете написать собственную msvcr71.dll и сохранить ее в каталоге C:\Python24, после чего она будет загружена, когда кто-либо запустит python.exe. Это возможно потому, что загрузчик Windows ищет именованные DLL в текущем каталоге до поиска в системных каталогах. Однако эта возможность Windows может позволить атакующему запускать код в контексте учетной записи с более высокими привилегиями, что было бы особенно полезно на терминальном сервере или в любой общей вычислительной среде.

Та же проблема может возникнуть с любым приложением, наследующим разрешения от корневого диска. Настоящая проблема в том, что исторически разработчики Windows часто не знали о встроенных механизмах контроля доступа. Это естественно, если учесть, что Windows изначально была однопользовательской ОС и с тех пор развилась в многопользовательскую систему. Поэтому такие проблемы могут возникать, когда разработчики незнакомы с дополнительными соображениями безопасности или пытаются поддерживать совместимость между разными версиями или платформами.

Ненужные сервисы

Вы, вероятно, слышали поговорку "праздные руки -- игрушка дьявола". Можно не соглашаться с ней в целом, но к ненужным сервисам она определенно применима. Ненужные сервисы включают любую функциональность, предоставляемую вашим приложением, которая не требуется для его работы. Эти возможности часто не настроены, не проверены или не защищены корректно.

Такие проблемы обычно возникают из небезопасных настроек по умолчанию, но могут быть вызваны "мышлением кухонной раковины" -- термином для разработчиков и администраторов, которые включают каждую возможную возможность на случай, если она понадобится позже. Хотя такой подход может казаться удобным, он способен привести к кошмару безопасности.

При проверке приложения убедитесь, что можете обосновать необходимость каждого включенного и раскрытого компонента. Это обоснование особенно критично, когда вы проверяете развернутое приложение или turnkey-систему. В таком случае нужно смотреть на систему целиком и выявлять все, что не нужно.

Уязвимости HTR в Internet Information Services (IIS) -- классический пример ненужного раскрытия уязвимого сервиса. HTR -- сценарная технология, которую Microsoft продвигала первой и которая так и не получила большого распространения; это можно объяснить выпуском более мощной Active Server Pages (ASP) вскоре после HTR. Любой запрос к IIS-серверу на имя файла с расширением .htr обрабатывается HTR-фильтром Internet Server API (ISAPI).

Примечание

ISAPI-фильтры -- это расширяющие модули IIS, способные обслуживать запросы на основе расширений файлов.

С 1999 по 2002 год ряд исследователей выявил HTR-уязвимости, варьировавшиеся от произвольного чтения файлов до выполнения кода. Однако ни одна из этих уязвимостей не была бы значимой, если бы этот редко используемый обработчик просто был отключен в конфигурации по умолчанию.

Защищенные каналы

Защищенный канал -- это любое средство коммуникации, обеспечивающее конфиденциальность между общающимися сторонами. Обычно этот термин используется применительно к зашифрованным соединениям; однако даже именованный канал можно считать защищенным каналом, если контроль доступа используется правильно. В любом случае важно, чтобы только правильные стороны могли просматривать или изменять значимые данные в канале, конечно при условии, что стороны уже каким-либо способом аутентифицированы.

Иногда необходимость защищенных каналов можно определить во время проектирования приложения. Вы можете знать до развертывания, что все коммуникации должны вестись через защищенные каналы, и приложение должно быть спроектировано и реализовано именно так. Однако чаще проект приложения должен учитывать диапазон возможных требований развертывания.

Самый базовый пример уязвимости защищенного канала -- просто не использовать защищенный канал тогда, когда он нужен. Рассмотрим типичное веб-приложение, в котором вы аутентифицируетесь с помощью пароля, а затем передаете ключ сеанса для каждой последующей транзакции. (Эта тема подробнее объясняется в главе 17, "Веб-приложения".) Вы ожидаете, что проверки пароля будут выполняться через Secure Sockets Layer (SSL), но что насчет последующих обменов? В конце концов, атакующие хотели бы получить ваш пароль, но они все равно могут получить неограниченный доступ к вашему сеансу, если добудут cookie сеанса.

Этот пример показывает, что необходимость защищенных каналов может быть несколько тонкой. Все согласятся с необходимостью защищать пароли, но ключ сеанса может не считаться столь же важным, что иногда совершенно приемлемо. Например, большинство веб-провайдеров электронной почты используют защищенный обмен паролем, но все оставшиеся транзакции отправляют session cookie в открытом виде. Эти поставщики предлагают бесплатную услугу с минимальной гарантией безопасности, поэтому это приемлемый бизнес-риск. Однако для банковского приложения вы ожидали бы, что все транзакции происходят через защищенный канал.

Подмена и идентификация

Подмена происходит всякий раз, когда атакующий может эксплуатировать слабость в системе, чтобы выдать себя за другого человека или другую систему. Глава 2 объясняла, что аутентификация используется для идентификации пользователей приложения и потенциально подключенных систем. Однако развертывание приложения может вводить некоторые дополнительные вопросы, которые проект приложения не может решить напрямую.

Наиболее распространенный стандарт TCP/IP не предоставляет метода предотвращения того, чтобы один хост выдавал себя за другой. Расширения и протоколы более высоких уровней (например, IPsec и SSL) решают эту проблему, но на самом базовом уровне нужно предполагать, что любое сетевое соединение потенциально может быть подделано.

Возвращаясь к примеру SSL, предположим, что сайт разрешает только HTTPS-соединения. Обычно сертификат для установления соединений будет подписан доверенным центром, уже указанным в базе сертификатов вашего браузера. Когда вы переходите на сайт, имя в сертификате сравнивается с DNS-именем сервера; если они совпадают, у вас есть разумная степень уверенности, что сайт не был подделан.

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

Однако если тот же сайт находится в публичном Интернете с сертификатом, подписанным разработчиком, больше нереалистично предполагать, что вы сможете доставить этот сертификат всем потенциальным клиентам. Поэтому клиент не имеет способа узнать, можно ли доверять сертификату. Если пользователи переходят на сайт, они получают сообщение об ошибке, что сертификат не подписан доверенным центром; единственный вариант -- принять недоверенный сертификат или завершить соединение. Атакующий, способный подделать сервер, может эксплуатировать эту ситуацию для проведения атак "человек посередине", а затем перехватывать сеансы или красть учетные данные.

Сетевые профили

Сетевой профиль приложения -- важнейшее соображение при анализе эксплуатационной безопасности. Протоколы вроде Network File System (NFS) и Server Message Block (SMB) приемлемы внутри корпоративного межсетевого экрана и обычно являются абсолютной необходимостью. Однако те же типы протоколов становятся неприемлемой ответственностью, когда они раскрыты за пределами межсетевого экрана. Разработчики приложений часто не знают точную среду, в которой приложение может быть развернуто, поэтому им нужно выбирать разумные настройки по умолчанию и предоставлять адекватную документацию по вопросам безопасности.

В общем случае выявлять эксплуатационные уязвимости в сетевом профиле проще для развернутого приложения. Можно просто посмотреть, какова среда, и определить любые неприемлемые риски, а также какие защиты уже применены. Очевидные защиты включают развертывание серверов, обращенных в Интернет, внутри демилитаризованных зон (DMZ) и обеспечение того, что наборы правил межсетевого экрана настолько строги, насколько разумно возможно.

Уязвимости сетевого профиля труднее рассматривать, когда среда неизвестна. Как проверяющий, вы должны определить наиболее враждебную потенциальную среду для системы, а затем анализировать систему с точки зрения этой среды. Также нужно убедиться, что конфигурация по умолчанию поддерживает развертывание в такой среде. Если нет, нужно убедиться, что документация и установщик ясно и конкретно рассматривают эту проблему.

Особые соображения для веба

World Wide Web -- точнее, сервисы HTTP и HTTPS -- стал одной из самых повсеместных платформ для разработки приложений. Распространение веб-сервисов и приложений почти в одиночку отвечает за рост осведомленности о сетевой безопасности и уязвимостях. По этой причине веб-безопасность заслуживает некоторых специальных соображений.

Методы HTTP-запросов

Веб-приложение может быть жестко ограничено в том, какие запросы и операции разрешены; однако на практике это ограничение часто не применяется. Например, сервер может поддерживать ряд HTTP-методов, но приложению нужны только HTTP-запросы GET, POST и HEAD. При анализе развернутого или встроенного веб-приложения нужно убедиться, что разрешены только необходимые методы запросов. В частности, задайте вопрос, должны ли быть разрешены запросы TRACE, OPTIONS и CONNECT. Если вы незнакомы с этими методами, гораздо больше информации можно найти в главе 17.

Индексация каталогов

Многие веб-серверы включают индексацию каталогов по умолчанию. Эта настройка не влияет на каталоги, предоставляющие индексный файл; однако она может раскрывать ценную информацию в каталогах без индекса. Часто такие каталоги содержат include-файлы и конфигурационные файлы или другие важные детали структуры приложения, поэтому индексация каталогов должна быть отключена по умолчанию.

Обработчики файлов

Когда вы пытаетесь запустить файл, очевидно, если правильный обработчик не установлен. Сервер просто не запускает файл, а вместо этого напрямую возвращает исходный код или бинарный файл. Однако неправильная конфигурация обработчика может возникать в ряде менее очевидных ситуаций. Когда машины пересобираются или заменяются, правильные обработчики могут не быть установлены до развертывания приложения. Разработчики также могут вводить соглашения для именования include-файлов другими расширениями. Например, include-файлы Classic ASP и PHP: Hypertext Processor (PHP) часто называются с расширением .inc, которое не интерпретируется обработчиками по умолчанию в PHP или ASP. Поскольку include-файл не предназначен для прямого запроса, разработчики и администраторы могут не понимать, что он уязвим.

Обе ситуации могут привести к раскрытию исходного или бинарного файла, что позволяет атакующим загрузить сырой исходный или бинарный код и получить подробную информацию о внутренней структуре приложения. Кроме того, PHP и другие сценарные языки часто используют include-файлы для предоставления учетных данных базы данных и другой чувствительной информации, что может делать уязвимости раскрытия исходного кода особенно опасными.

К этой проблеме нужно подходить с трех сторон. Во-первых, разработчикам нужно выбрать набор расширений, используемых для всех исходных и бинарных файлов. Во-вторых, веб-сервер должен быть настроен с обработчиками для всех подходящих типов файлов и расширений. Наконец, в веб-дереве должны находиться только те файлы, которые должны извлекаться веб-запросами. Include-файлы и поддерживающие библиотеки следует размещать вне веб-дерева. Этот последний шаг предотвращает прямой запрос атакующими файлов, предназначенных только для включения.

Важное расширение последнего шага применимо, когда веб-приложения работают с контентом, загруженным клиентами. Приложения часто позволяют клиентам загружать файлы, но это имеет потенциально опасные последствия, особенно если каталог, куда загружаются файлы, находится внутри веб-дерева. В таком случае клиенты могут получить возможность запросить только что загруженный файл; если файл связан с обработчиком, они могут добиться произвольного выполнения. В качестве примера рассмотрим PHP-приложение, которое хранит загруженные файлы в /var/www/webapp/tmpfiles/, доступном для просмотра через HTTP URI /webapp/tmpfiles/. Если клиент загрузит файл с именем evil.php, а затем запросит /webapp/tmpfiles/evil.php в браузере, веб-сервер, скорее всего, распознает файл как PHP-приложение и выполнит код внутри PHP-тегов файла.

Аутентификация

Веб-приложения могут не выполнять аутентификацию внутренне; этот процесс может обрабатываться внешне через протокол HTTP-аутентификации, аутентифицирующий reverse proxy или систему единого входа (single sign-on, SSO). При таком типе аутентификации особенно важно убедиться, что внешний механизм аутентификации настроен правильно и выполняет аутентификацию безопасным образом. Например, reverse-proxy-устройство может добавлять заголовки, включающие текущее имя учетной записи и пользовательскую информацию. Однако атакующие могут обнаружить путь запроса, который не проходит через reverse proxy, что позволит им устанавливать заголовки учетной записи как угодно и выдавать себя за любого пользователя системы.

Установки сайтов по умолчанию

Некоторые веб-серверы включают ряд примерных сайтов и приложений как часть установки по умолчанию. Цель -- предоставить некоторый ориентир для настройки сервера и разработки модулей. Однако на практике такие примерные сайты являются довольно серьезным случаем ненужных сервисов и небезопасных настроек по умолчанию. Многочисленные проблемы безопасности были вызваны установкой примерных веб-приложений и функций. Например, веб-сценарные технологии ColdFusion раньше по умолчанию устанавливали несколько примерных приложений, позволявших клиентам загружать файлы и запускать произвольный код в системе.

Примечание

Эта ошибка ColdFusion связана с частью предыдущего обсуждения подмены и идентификации. Примерные приложения были доступны только клиентам, подключавшимся с той же машины, где был установлен ColdFusion. Однако способ проверки того, подключается ли клиент локально, состоял в проверке HTTP-переменной HOST, которая полностью контролируется клиентом. В результате любой клиент мог заявить, что подключается локально, и получить доступ к примерным сценариям с опасной функциональностью. Эта ошибка документирована по адресу www.securityfocus.com/bid/3154/info.

Чрезмерно подробные сообщения об ошибках

Большинство веб-серверов возвращают довольно подробные сообщения об ошибках, помогающие диагностировать любые возникшие проблемы. Платформы веб-приложений также предоставляют подробную информацию об исключениях, чтобы помогать разработчикам отлаживать код. Эти возможности необходимы при разработке системы, но могут быть серьезной эксплуатационной уязвимостью в развернутой системе.

Основная нагрузка по отчетам об ошибках для конечных пользователей должна лежать на разработчиках приложения. Уровень приложения имеет правильный контекст для определения того, какую информацию уместно показывать конечным пользователям. Конфигурация базовой платформы всегда должна выполняться исходя из предположения, что приложение фильтрует и отображает любую информацию об ошибках для конечных пользователей. Так развернутая система может быть настроена на сообщение клиентским пользователям минимально необходимой информации и перенаправление любых требуемых деталей в системный журнал.

Публичные административные интерфейсы

Веб-администрирование стало популярным для веб-приложений и сетевых устройств. Эти административные интерфейсы часто удобны, но редко реализованы с учетом потенциально злонамеренных пользователей. Они могут использовать слабые пароли по умолчанию, не выполнять достаточную аутентификацию или иметь любое число других уязвимостей. Поэтому при возможности они должны быть доступны только через ограниченные сетевые сегменты и никогда не должны раскрываться на соединениях, обращенных в Интернет.

Защитные меры

Ряд дополнительных защитных мер может влиять на общую безопасность приложения. На языке консультантов их часто называют смягчающими факторами или компенсирующими средствами контроля; в общем случае они используются для применения концепции глубокоэшелонированной защиты, упомянутой в главе 2. Эти меры могут применяться во время или после процесса разработки, но обычно существуют вне самого программного обеспечения.

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

Меры разработки

Защитные меры разработки сосредоточены на использовании платформ, библиотек, параметров компилятора и аппаратных возможностей, которые снижают вероятность эксплуатации кода. Эти техники обычно не влияют на то, как пишется код, хотя часто влияют на выбор одной платформы вместо другой. Поэтому такие меры рассматриваются как эксплуатационные, а не как меры реализации.

Невыполняемый стек

Классическое переполнение буфера стека, вполне возможно, является самой часто используемой программной уязвимостью в истории, поэтому поставщики оборудования наконец пытаются предотвращать их на самом низком возможном уровне, принудительно применяя защиту невыполняемости к страницам памяти. Эта техника не нова, но наконец становится обычной в недорогом массовом оборудовании, таком как потребительские ПК.

Невыполняемый стек может усложнить эксплуатацию уязвимости управления памятью, но не обязательно устраняет ее, потому что эксплойт может не требовать запуска кода со стека. Он может просто включать исправление стековой переменной или выполнение кода через атаку в стиле return-to-libc. Эти уязвимости подробнее рассматриваются в главе 5, "Повреждение памяти", но пока важно понимать, где находятся общие слабости.

Защита стека

Цель классического переполнения стека -- перезаписать указатель инструкции. Защита стека предотвращает этот эксплойт, помещая случайное значение, называемое "canary", между стековыми переменными и указателем инструкции. Когда функция возвращается, canary проверяется, чтобы убедиться, что он не изменился. Таким образом приложение может определить, произошло ли переполнение стека, и выбросить исключение вместо запуска потенциально вредоносного кода.

Как и невыполняемый стек, защита стека имеет свои слабости. Она также не защищает от исправления стековых переменных (хотя некоторые реализации переупорядочивают переменные, чтобы снизить вероятность этой проблемы). Механизмы защиты стека также могут иметь проблемы с кодом, выполняющим определенные типы динамических манипуляций стеком. Например, LibSafePlus не может защитить код, использующий вызов alloca() для изменения размера стека; эта проблема также может быть недокументированной проблемой в других реализациях. Хуже того, некоторые защиты стека уязвимы к атакам, напрямую нацеленным на механизмы их реализации. Например, раннюю реализацию защиты стека Microsoft можно было обойти, записав данные за canary и поверх текущего обработчика исключений.

Ни одна форма защиты стека не совершенна, и у каждой реализации есть типы переполнений, которые нельзя обнаружить или предотвратить. Нужно смотреть на доступные варианты и определять преимущества и недостатки. Еще одно соображение: нередко команда разработки включает защиту стека, после чего приложение перестает работать правильно. Эта проблема возникает из-за переполнений стека где-то в приложении, которые могут быть или не быть эксплуатируемыми. К сожалению, разработчики могут столкнуться с такими трудностями при отслеживании ошибок, что решат полностью отключить защиту. Возможно, нужно учитывать такую возможность, когда вы рекомендуете защиту стека как простое исправление.

Защита кучи

Большинство программных куч состоит из двусвязного списка фрагментов памяти. Типовой эксплойт кучи пытается перезаписать указатели списка, чтобы произвольные данные можно было записать куда-то в адресном пространстве. Самая простая форма защиты кучи включает проверку, что указатели списка ссылаются на допустимые фрагменты кучи, до выполнения любого управления списком.

Простая защита кучи довольно легко реализуется и дает небольшие накладные расходы производительности, поэтому в последние годы стала распространенной. В частности, недавние версии ОС Microsoft включают ряд механизмов проверки согласованности кучи, чтобы помочь минимизировать ущерб от перезаписей кучи. GNU libc также имеет некоторые возможности защиты от распространенных техник эксплуатации; процедуры управления памятью проверяют значения связанного списка и в некоторой степени валидируют размер фрагментов. Хотя эти механизмы -- шаг в правильном направлении, переполнения кучи все еще можно эксплуатировать, манипулируя данными приложения, а не структурами кучи.

Рандомизация размещения адресного пространства

Когда приложение запускается в большинстве современных операционных систем, загрузчик каждый раз организует программу и требуемые библиотеки в памяти по одним и тем же адресам. Обычно стек и куча программы помещаются в одинаковые места для каждой запускаемой программы. Такая практика полезна атакующим, эксплуатирующим уязвимость повреждения памяти: они могут с высокой точностью предсказать расположение ключевых структур данных и компонентов программы, которыми хотят манипулировать или злоупотребить. Технологии рандомизации размещения адресного пространства (address space layout randomization, ASLR) стремятся убрать это преимущество у атакующих, рандомизируя место загрузки разных компонентов программы в память при каждом запуске приложения. Структура данных, находящаяся по адресу 0x12345678 при одном запуске программы, при следующем запуске может находиться по адресу 0xABCD5678. Поэтому атакующие больше не могут использовать жестко закодированные адреса для надежной эксплуатации дефекта повреждения памяти, нацеливаясь на конкретные структуры в памяти. ASLR особенно эффективна при использовании с другими схемами защиты памяти; комбинация нескольких мер может превратить ошибку, которую раньше легко эксплуатировали, в очень трудную цель. Однако ASLR ограничена диапазоном допустимых адресов, поэтому атакующий может выполнить повторяющуюся последовательность попыток эксплуатации и в конце концов добиться успеха.

Зарегистрированные указатели функций

У приложений могут быть долгоживущие указатели функций в стабильных местах адресного пространства процесса. Иногда эти указатели определяются во время компиляции и никогда не меняются для данного бинарного файла; обработчики исключений -- один из самых распространенных примеров. Эти свойства делают долгоживущие указатели функций идеальной целью для эксплуатации определенных классов уязвимостей. Многие типы уязвимостей похожи тем, что позволяют записать только небольшое значение в одно произвольное место, например атаки против функций управления кучей.

Регистрация указателей функций -- одна попытка предотвратить успешную эксплуатацию таких типов уязвимостей. Она реализуется путем оборачивания вызовов указателей функций в некоторую форму проверки на неавторизованное изменение. Точные детали проверки могут различаться по силе и способу выполнения. Например, компилятор может поместить допустимые обработчики исключений на страницу памяти только для чтения, а обертка может просто выполнять прямое сравнение с этой страницей, чтобы определить, поврежден ли указатель.

Виртуальные машины

Платформа виртуальной машины (VM) может многое сделать для улучшения базовой безопасности приложения. Java и .NET Common Language Runtime (CLR) -- две популярные VM-среды, но технология еще шире распространена. Большинство популярных сценарных языков (например, Perl, Python и PHP) сначала компилируются в байткод, который затем интерпретируется виртуальной машиной.

Среды виртуальных машин обычно являются лучшим выбором для большинства распространенных задач программирования. Они в целом предоставляют такие возможности, как буферы и строки с размером, предотвращающие большинство атак на управление памятью. Они также могут включать дополнительные схемы защиты, например code access security (CAS), упомянутую в главе 1. Эти подходы обычно позволяют разработчикам быстрее создавать более безопасные приложения.

Недостаток виртуальных машин в том, что их неявная защита останавливается на низкоуровневых уязвимостях. VM-среды обычно не имеют дополнительных защит от эксплуатации уязвимостей вроде состояний гонки, манипуляции форматированными данными и внедрения сценариев. Они также могут предоставлять пути к низкоуровневым уязвимостям нижележащей платформы или иметь собственные уязвимости.

Меры на уровне хоста

Защиты на уровне хоста включают возможности ОС или поддерживающие приложения, способные улучшить безопасность программного обеспечения. Они могут развертываться вместе с приложением или быть дополнительными мерами, установленными конечными пользователями или администраторами. Эти дополнительные защитные меры могут быть полезны для предотвращения, выявления и смягчения успешных эксплойтов, но помните, что такие приложения являются программным обеспечением. Они могут содержать уязвимости в своих реализациях и вводить новую поверхность атаки в систему.

Разрешения объектов и файловой системы

Управление разрешениями -- первое и самое очевидное место, где стоит пытаться уменьшить поверхность атаки. Иногда оно выполняется программно, например разрешения на объект общей памяти или примитив синхронизации процессов. Однако с эксплуатационной точки зрения вас интересуют разрешения, изменяемые во время и после установки приложения.

Как обсуждалось ранее в этой главе, назначение разрешений может быть сложным. Настройки платформы по умолчанию могут не обеспечивать адекватную безопасность, или разработчик может не понимать, как решение повлияет на безопасность приложения. Обычно нужно выполнить хотя бы поверхностный обзор всех файлов и объектов, включенных в установку программного обеспечения.

Ограниченные учетные записи

Ограниченные учетные записи часто используются для запуска приложения с публично доступным сервисом. Намерение при использовании такого типа учетной записи -- не предотвратить компрометацию, а снизить ее воздействие. Поэтому такие учетные записи имеют ограниченный доступ к системе и могут наблюдаться более пристально.

В системах Windows ограниченная учетная запись обычно не получает сетевого доступа к системе, не принадлежит к группам пользователей по умолчанию и может использоваться с ограниченными токенами. Судхакар Говиндаваджхала и Эндрю У. Аппель из Принстонского университета опубликовали интересную работу "Windows Access Control Demystified", в которой перечисляют ряд соображений и сценариев повышения привилегий для разных групповых привилегий и сервисных учетных записей. Эта работа доступна по адресу http://www.cs.princeton.edu/~sudhakar/papers/winval.pdf.

Ограниченные учетные записи обычно не имеют shell по умолчанию в UNIX-системах, поэтому атакующие не могут войти с такой учетной записью, даже если успешно установят пароль через какой-либо дефект приложения. Кроме того, они обычно имеют мало привилегий в системе или вообще их не имеют, поэтому если каким-то образом смогут получить интерактивный shell, они не смогут выполнить операции с серьезными последствиями. Тем не менее сам факт доступа атакующих к системе часто опасен, потому что они могут использовать систему как "трамплин" к другим ранее недоступным хостам или выполнять локальные атаки на скомпрометированной системе для повышения привилегий.

Ограниченные учетные записи полезны, но их можно развернуть небрежно. Нужно убедиться, что ограниченные учетные записи не содержат ненужных прав или привилегий. Также хорошо следовать правилу "одна учетная запись -- один сервис" из-за неявного общего доверия между всеми процессами, работающими под одной учетной записью, как обсуждалось в главе 2.

Chroot-изоляции

Операционные системы UNIX используют команду chroot, чтобы изменить корневой каталог нового выполняемого процесса. Обычно эта команда используется при запуске системы или при сборке программного обеспечения. Однако у chroot есть и полезное применение в безопасности: не-root-процесс можно фактически заключить в выбранную часть файловой системы, запустив его с командой chroot.

Такой подход особенно эффективен из-за использования файловой системы в UNIX как основного интерфейса для всей системной активности. Атакующий, эксплуатировавший заключенный процесс, все равно ограничен содержимым изолированной файловой системы, что предотвращает доступ к большинству критических системных активов.

chroot-изоляция может значительно улучшить безопасность, но есть оговорки. Любой процесс, работающий с привилегиями root, обычно может выйти из изолированной среды, используя другие системные механизмы, например отладочный API PTRACE, установку системных переменных через sysctl или эксплуатацию какого-либо другого способа, позволяющего системе запустить новый произвольный процесс, не ограниченный chroot-изоляцией. В результате chroot-изоляции эффективнее при использовании с ограниченной учетной записью. Кроме того, chroot-изоляция не ограничивает сетевой доступ сверх обычных разрешений учетной записи, что все еще может оставлять достаточно поверхности атаки для последующей атаки, нацеленной на демоны, слушающие адрес localhost.

Системная виртуализация

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

К счастью, на помощь приходит виртуализация. Виртуализация позволяет нескольким операционным системам совместно использовать один хост-компьютер. Если все сделано правильно, каждый хост изолирован от другого и не может влиять на целостность других хостов иначе как через стандартные сетевые интерфейсы. Таким образом, один хост может обеспечивать высокий уровень сегментации и при этом эффективно использовать ресурсы.

Виртуализация не нова; она десятилетиями существует в области мэйнфреймов. Однако большинство недорогих микрокомпьютеров не поддерживало функции, необходимые для настоящей аппаратной виртуализации -- эти функции известны как требования виртуализации Попека и Голдберга. Настоящая аппаратная виртуализация включает возможности, которые оборудование должно предоставлять, чтобы виртуализировать доступ без необходимости программной эмуляции. Программная виртуализация, конечно, работает, но только недавно массовое оборудование стало достаточно мощным для поддержки крупномасштабной виртуализации.

Однако виртуализация продолжит расти. Новые массовые процессоры от поставщиков вроде Intel и AMD теперь имеют полноценную поддержку аппаратной виртуализации, а программная виртуализация стала более обычной. Теперь можно увидеть ряд специальных случаев, когда специализированные операционные системы и программы распространяются как дисковые образы виртуальных машин. Эти концепции развивались более десяти лет через исследования экзоядер и паравиртуализации, а коммерческие продукты становятся доступными только сейчас.

Для аудиторов виртуализация имеет преимущества и недостатки. Она может позволить распространять приложение в строго настроенной среде или, наоборот, навязать пользователям плохо настроенный черный ящик. Лучший подход -- относиться к виртуализированной системе так же, как к любой другой системе, и уделять особое внимание всем местам, где виртуальная сегментация нарушается. Однако по мере роста популярности виртуализация почти наверняка будет вводить новые и уникальные вопросы безопасности.

Усиленная защита ядра

Все операционные системы должны предоставлять некоторый механизм для взаимодействия пользовательских приложений с ядром. Этот интерфейс обычно называется шлюзом системных вызовов, и он должен быть единственным интерфейсом для манипулирования базовыми системными объектами. Шлюз системных вызовов -- полезная граница доверия, поскольку он предоставляет узкое место входа в операции ядра. Затем модуль ядра может перехватывать запрошенные операции (или последующие вызовы), чтобы предоставить уровень контроля доступа, значительно более детальный, чем обычные разрешения объектов.

Например, у вас может быть демон, который нужно запускать от имени root, но этот демон не должен иметь возможности обращаться к произвольным файлам или загружать модули ядра. Такие ограничения можно обеспечить только дополнительными мерами внутри ядра. Дополнительный набор разрешений можно сопоставить с исполняемым файлом и пользователем, связанными с процессом. В этом случае модуль ядра отклонит вызов, если исполняемый файл и пользователь соответствуют ограниченному демону. Такой подход является примером простого типа усиленной защиты ядра; однако для разных операционных систем доступны несколько надежных реализаций. SELinux -- популярный модуль для систем Linux и BSD, а Core Force (от Core Security) -- бесплатно доступный вариант для систем Windows 2000 и XP.

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

Межсетевые экраны на уровне хоста

Межсетевые экраны на уровне хоста в последние годы стали чрезвычайно популярны. Они часто позволяют тонко контролировать сетевой трафик, включая конфигурацию по процессам и пользователям. Этот дополнительный уровень защиты может помочь компенсировать любую упущенную сетевую поверхность атаки. Такие межсетевые экраны также могут смягчать эффект атаки, ограничивая сетевой доступ частично скомпрометированной системы.

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

Антивредоносные приложения

Антивредоносные приложения включают антивирусное и антишпионское ПО. Обычно это системы на основе сигнатур, пытающиеся выявлять поведение и атрибуты, связанные с вредоносным ПО. Они могут даже включать некоторую степень усиленной защиты ядра, хостового межсетевого экрана и мониторинга изменений. Однако в основном такие приложения полезны для выявления известных вредоносных программ. Обычно они менее ценны при обработке более специализированных атак или неизвестного вредоносного ПО.

Антивредоносные приложения обычно мало влияют на аудит программных систем. Главное соображение состоит в том, что на развернутой системе должно быть установлено и правильно настроено соответствующее ПО.

Мониторинг изменений файлов и объектов

Некоторые приложения безопасности имеют методы мониторинга изменений системных объектов, таких как конфигурационные файлы, системные бинарные файлы и чувствительные ключи реестра. Такой мониторинг может быть эффективным способом выявить компрометацию, поскольку в результате эксплойта часто изменяется чувствительная часть системы. Более надежные системы мониторинга фактически поддерживают дайджесты (или хеши) чувствительных файлов и системных объектов. Затем их можно использовать для помощи в криминалистическом анализе данных в случае серьезной компрометации.

Мониторинг изменений по своей природе является довольно реактивным процессом, поэтому обычно он не полезен для предотвращения компрометации. Однако он может оказаться бесценным для выявления успешной компрометации, определения ее масштаба и смягчения последствий. Самое важное соображение для аудиторов: большинство систем мониторинга изменений по умолчанию настроено на мониторинг только базовых системных объектов. Добавление мониторинга компонентов, специфичных для приложения, обычно требует изменений конфигурации по умолчанию.

IDS/IPS на уровне хоста

Хостовые системы обнаружения вторжений (intrusion detection systems, IDS) и системы предотвращения вторжений (intrusion prevention systems, IPS) обычно находятся где-то между хостовыми межсетевыми экранами и антивредоносными приложениями. Они могут включать возможности обоих типов, а также усиленную защиту ядра и мониторинг изменений файлов. Детали сильно различаются от продукта к продукту, но обычно эти системы можно рассматривать как некоторую комбинацию мер на уровне хоста, представленных до этого момента.

Сетевые меры

Целую книгу можно было бы посвятить теме безопасной сетевой архитектуры. В конце концов, безопасность -- лишь один маленький фрагмент головоломки. Хорошая сетевая схема должна учитывать ряд вопросов помимо безопасности, например стоимость, удобство использования и производительность. К счастью, по этой теме доступно много справочного материала, поэтому это обсуждение ограничено несколькими базовыми понятиями в следующих разделах. Если вы незнакомы с сетевыми основами, начните с небольшого исследования TCP/IP, модели Open Systems Interconnection (OSI) и сетевой архитектуры.

Сегментация

Любое обсуждение сетевой безопасности нужно начинать с сегментации. Сетевая сегментация описывает, как коммуникация по сети делится на группы на разных уровнях. TCP/IP-сети обычно сегментируются только по двум причинам: безопасность и производительность. Для целей этого обсуждения нас больше всего интересует влияние сетевой сегментации на безопасность.

Сетевую сегментацию можно рассматривать как метод принудительного соблюдения границ доверия. Именно поэтому безопасность является важной заботой при разработке сетевой архитектуры. Также следует учитывать, какой уровень OSI используется для обеспечения границы безопасности. В общем случае лучше начинать с максимально низкого возможного уровня. Затем каждый более высокий уровень должен усиливать границу, когда это уместно. Однако вы всегда сталкиваетесь с практическими ограничениями того, сколько сетевой безопасности можно обеспечить, и с ограничениями того, что можно принудительно соблюсти на каждом уровне.

Уровень 1: физический

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

К сожалению, быстрый рост беспроводных сетей заставил многих пересмотреть понятие безопасности физического уровня. Когда вы развертываете беспроводную сеть, вы раскрываете поверхность атаки потенциально каждому в радиусе передачи. С подходящей антенной и приемником атакующий может находиться в миле или дальше. Если рассмотреть эту возможность вместе с сомнительной защитой исходного стандарта Wired Equivalent Privacy (WEP), становится очевидно, что безопасность физического уровня может усложниться.

Уровень 2: канальный

Сегментация на канальном уровне связана с предотвращением подмены хостов и прослушивания трафика (захвата данных, передаваемых другими хостами). Системы на этом уровне идентифицируются через Media Address Control (MAC)-адреса, а Address Resolution Protocol (ARP) используется для выявления MAC-адресов, связанных с подключенными хостами. Затем коммутация используется для маршрутизации трафика только к подходящему хосту.

Однако сетевые коммутаторы сильно различаются по возможностям и качеству. Они могут быть уязвимы к разным атакам подмены ARP, позволяющим атакующим выдавать себя за другую систему или прослушивать трафик, предназначенный другим системам. Фильтрация адресов может использоваться для улучшения безопасности на этом уровне, но на нее никогда нельзя полагаться как на единственную меру.

Беспроводные среды также создают потенциальные вопросы на этом уровне, потому что добавляют шифрование и аутентификацию, чтобы компенсировать неспособность адекватно сегментировать физический уровень. При выборе протокола беспроводной защиты есть несколько вариантов. Хотя существуют проприетарные стандарты, открытые стандарты популярнее, поэтому этот раздел сосредоточен на них.

WEP был исходным стандартом беспроводной аутентификации и шифрования; однако его проект оказался уязвим к криптоаналитическим атакам, которые дополнительно усугублялись слабостями ряда реализаций. Wi-Fi Protected Access (WPA) -- более надежный стандарт, предоставляющий более безопасную обработку ключей при тех же базовых возможностях шифрования, что и WEP (что позволяет ему работать на существующем оборудовании). Однако WPA предназначался только как промежуточная мера и был заменен WPA2, который сохраняет основные улучшения WPA в обработке ключей и добавляет более сильное шифрование и возможности дайджеста.

Уровень 3: сетевой

Безопасность и сегментация на сетевом уровне обычно обрабатываются через IP-фильтрацию и, в некоторых случаях, протокол IP Security (IPsec). Любое содержательное обсуждение IPsec выходит за рамки этой книги, но важно точно отметить, что это такое. IPsec -- компонент спецификации IPv6, перенесенный обратно в текущий IPv4. Он предоставляет автоматическое шифрование и аутентификацию для TCP/IP-соединений на сетевом уровне. Хотя IPsec имеет привлекательные возможности безопасности, его принятие было медленным, и для многих областей, для которых он предназначался, были разработаны другие технологии. Однако принятие продолжает расти, и правильно развернутая среда IPsec чрезвычайно эффективна в предотвращении ряда сетевых атак, включая большинство атак прослушивания и подмены.

IP-фильтрация -- довольно простой метод разрешения или запрета пакетов только на основе протокола, адресов и портов. Этот метод позволяет сегментировать трафик согласно его функции, а не только источнику и назначению. Такой тип фильтрации легко реализовать, он обеспечивает быструю пропускную способность и имеет довольно низкие накладные расходы. На этом этапе IP-фильтрация практически является стандартной возможностью, ожидаемой почти в любой сетевой системе, например маршрутизаторе или ОС. Недостаток IP-фильтрации в том, что она не поддерживает состояние соединения. Она не может различать, какая сторона устанавливает соединение, или связана ли коммуникация с активным соединением. Поэтому простой IP-фильтр должен разрешать входящий трафик на любой порт, где он разрешает исходящий трафик.

Уровень 4: транспортный

Транспортный уровень -- это то, о чем думает большинство людей, обсуждая архитектуру сетевой безопасности. Этот уровень достаточно низок, чтобы быть общим для всех TCP/IP-приложений, но достаточно высок, чтобы можно было определить состояние соединения. Добавление состояния позволяет межсетевому экрану определить, какая сторона инициирует соединение, и устанавливает фундаментальное понятие внутренней и внешней сети.

Межсетевые экраны, то есть устройства, фильтрующие трафик на сетевом и транспортном уровнях, являются основным методом сегментации сети для целей безопасности. Самый простой межсетевой экран имеет только два интерфейса: внутренний и внешний. Самый простой метод firewalling -- запретить весь входящий трафик и разрешить весь исходящий. Большинство хостовых и персональных межсетевых экранов настроены так по умолчанию.

Однако межсетевые экраны становятся интересными, когда вы используете их для разделения сети согласно функциональным требованиям. Например, допустим, вы знаете, что сотрудникам в вашей сети нужен только исходящий веб-доступ. Можно разрешить только TCP-порты 80 и 443 наружу и запретить все остальное. Корпоративный веб-сайт размещен локально, поэтому нужно добавить TCP-порт 80 внутрь к веб-серверу. (Примечание: ряд других вероятных сервисов, в особенности DNS, проигнорирован, чтобы сохранить пример простым.) Однако вам не нравится идея иметь отверстие прямо во внутреннюю сеть через TCP-порт 80. Решение -- развернуть веб-сервер внутри демилитаризованной зоны (DMZ). DMZ использует третий интерфейс межсетевого экрана, содержащий собственный набор правил. Сначала предположим, что DMZ настроена на запрет любых соединений по умолчанию, что позволяет начать с чистого листа. Затем нужно переместить веб-сервер в DMZ, удалить правило запрета входящего трафика для порта 80 и заменить его правилом, разрешающим входящий трафик из внешней сети к веб-серверу в DMZ на TCP-порт 80. Рисунок 3-1 показывает пример такой сети.

Рисунок 3-1. Простой пример DMZ

Этот пример, хотя и прост, передает основы сегментации транспортного уровня. Важно понять, что сеть должна быть сегментирована по функциям настолько, насколько разумно возможно. Продолжая пример, что если веб-сервер поддерживается базой данных на отдельной системе? База данных может содержать особенно чувствительную информацию клиентов, которую не следует размещать внутри DMZ. Однако перенос базы данных во внутреннюю сеть требует открытия соединения из DMZ во внутреннюю сеть, что тоже может быть неприемлемым риском. В таком случае может понадобиться добавить вторую DMZ, содержащую уровень данных для веб-фронтенда.

При анализе уже развернутого приложения нужно учитывать эти соображения среды. Всегда будут законные причины, не позволяющие развертыванию иметь идеальную сегментацию. Однако вы должны знать об этих способствующих факторах и определить, сегментирована ли среда адекватно требованиям безопасности приложения.

Уровни 5 и 6: сеансовый и представления

Некоторые уровни модели OSI не сопоставляются чисто с TCP/IP; например, сеансовый уровень и уровень представления обычно поднимаются в прикладной уровень TCP/IP. Однако вместе эти уровни дают полезное различение для некоторых прикладных протоколов. Платформенно-специфические возможности, такие как RPC-интерфейсы и именованные каналы, обычно принимаются как протоколы сеансового уровня и уровня представления. Безопасность на этих интерфейсах обычно обрабатывается программно и должна реализовываться через родные механизмы контроля доступа платформы.

Secure Socket Layer/Transport Layer Security (SSL/TLS) -- еще один протокол, который уместнее обсуждать в терминах сеансового уровня или уровня представления. Раздел "Защищенные каналы" ранее в этой главе обсуждал, как SSL можно использовать для создания защищенного зашифрованного канала. SSL/TLS также поддерживает аутентификацию на основе сертификатов, что может уменьшить поверхность атаки приложения, принудительно выполняя аутентификацию ниже прикладного уровня.

Уровень 7: прикладной

Безопасность прикладного уровня -- интересная смесь, и большая часть этой книги посвящена ей. Однако прокси прикладного уровня прямо попадают в категорию эксплуатационных защитных мер. Если вы провели сколько-нибудь времени в сетевой безопасности, вы, вероятно, слышали многочисленные обсуждения ценности гетерогенных (или смешанных) сетей. С положительной стороны, гетерогенная среда гораздо менее подвержена атакам "серебряной пули", при которых атакующий может скомпрометировать большую часть сети, используя одну уязвимость. Однако гомогенной средой обычно проще и дешевле управлять.

Шлюзы прикладного уровня интересны тем, что добавляют дополнительное сетевое разнообразие как раз в нужном месте. Некоторые из первых популярных прикладных шлюзов были просто проверяющими HTTP reverse proxy. Они стояли перед склонными к уязвимостям веб-серверами и отклоняли некорректный веб-трафик, что давало умеренную защиту от атак на веб-серверы. Более новые шлюзы веб-приложений добавили ряд возможностей, включая общесайтовую аутентификацию, обнаружение эксплойтов и детальные наборы правил.

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

Network Address Translation (NAT)

Network Address Translation (NAT) предоставляет метод сопоставления набора внутренних адресов с другим набором внешних адресов. Изначально он был разработан для более эффективного использования адресного пространства IPv4 путем сопоставления большего числа частных внутренних сетевых адресов с гораздо меньшим числом внешних адресов.

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

NAT может предлагать дополнительную защиту, но в общем случае это не его назначение. В зависимости от реализации NAT-устройства могут допускать атаки, устанавливающие внутренние соединения, подделывающие внутренние адреса или раскрывающие адреса в частной сети. Поэтому на NAT нельзя полагаться в одиночку; его следует рассматривать как дополнительную меру.

Виртуальные частные сети (VPN)

Виртуальная частная сеть (virtual private network, VPN) предоставляет виртуальный сетевой интерфейс, подключенный к удаленной сети через зашифрованный туннель. Этот подход стал популярным и быстро заменяет деловые dial-in-подключения и выделенные линии. Преимущество VPN в том, что он предоставляет интерфейс, почти идентичный интерфейсу напрямую подключенного пользователя, что удобно для конечных пользователей и сетевых администраторов.

Главный недостаток VPN состоит в том, что клиентская система обычно находится вне физического контроля сетевых администраторов, что создает потенциал для гораздо большей поверхности атаки, чем у обычной внутренней системы. VPN-сегменты нужно контролировать внимательнее, а администраторы должны вводить дополнительные меры предосторожности для клиентов. Обычно эти меры включают запрет VPN-клиентам доступа к их локальной сети (split tunneling) во время подключения и ограничение доступа к определенным внутренним ресурсам через VPN.

Сетевые IDS/IPS

Сетевые IDS и IPS -- это устройства, которые пытаются выявлять вредоносный сетевой трафик и потенциально завершать или запрещать соединение на основе обнаруженной враждебной активности. Первые системы были в основном сигнатурными движками, которые искали конкретный трафик, связанный с известными атаками. Более новые системы пытаются выявлять аномальные шаблоны трафика и уведомлять о них администраторов наряду с известными враждебными шаблонами.

Существует довольно много литературы и споров о правильном подходе к развертыванию и настройке IDS и IPS. Детали зависят от сетевой среды. Однако лучшие общепринятые практики требуют сначала сегментировать сеть, чтобы изолировать разные функциональные области и точки наибольшего риска. Затем датчики IDS развертываются так, чтобы использовать сегментацию для выявления потенциальных атак или компрометаций.

Итоги

Безопасность приложения выходит за пределы кода и охватывает эксплуатационную среду и режим, в котором функционируют приложения. В этой главе вы рассмотрели внешние системные детали, влияющие на то, насколько безопасно приложение в среде развертывания. При проведении аудита приложения нужно учитывать целевую среду развертывания (если она доступна) и параметры конфигурации приложения по умолчанию. Небезопасное или ненужное раскрытие приложения может привести к уязвимостям, полностью независимым от программного кода.

Создание эксплойтов и аудит ПО -- два разных, но весьма взаимодополняющих набора навыков. Аудитор с хорошим пониманием разработки эксплойтов эффективнее, поскольку это знание полезно для определения разницы между безобидной ошибкой и настоящей уязвимостью. Существует много хорошо задокументированных техник эксплуатации уязвимостей повреждения памяти, и эта глава дает краткое введение в некоторые базовые подходы для архитектуры Intel x86 (хотя концепции применимы ко всем архитектурам). Наряду с техниками эксплуатации вы узнаете больше деталей о технологиях противодействия эксплойтам и стратегиях определения эксплуатируемости. Материал не предназначен быть исчерпывающим руководством по эксплуатации уязвимостей повреждения памяти, но он дает фон, необходимый для понимания и оценки многих уязвимостей, рассматриваемых в этой книге.

Примечание

Читателям, заинтересованным в более глубоком изучении эксплуатации уязвимостей повреждения памяти, стоит взять The Shellcoder's Handbook (Wiley, 2004) Jack Koziol и др. или Exploiting Software (Addison-Wesley, 2004) Greg Hoglund и Gary McGraw. Также можно найти множество онлайн-ресурсов о техниках эксплуатации, например журнал phrack (www.phrack.org) и журнал Uninformed (www.uninformed.org).

Переполнения буфера

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

Переполнения буфера -- самый распространенный тип повреждения памяти. Если вы не знакомы с тем, как эксплуатируются такие ошибки, они почти кажутся нелогичными и каким-то образом дают атакующему полный доступ к уязвимой системе. Но как они работают? Почему они настолько угрожают целостности системы? И почему операционные системы просто не защищают память от повреждения полностью? Чтобы ответить на эти вопросы, нужно быть знакомым с внутренним устройством программ и с тем, как CPU и ОС управляют процессами.

Примечание

Некоторые уязвимости в этой книге являются более сложными уязвимостями повреждения памяти и технически не являются переполнениями буфера, но имеют многие из тех же характеристик. Это обсуждение эксплуатируемости в значительной степени применимо к таким проблемам, особенно к разделу "Оценка воздействия повреждения памяти" далее в этой главе.

Раскладка памяти процесса

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

• Код программы. Этот раздел содержит исполняемые инструкции программы, которые процессор может интерпретировать и выполнять. Код программы включает скомпилированный код запущенной программы и дополнительный код, расположенный в разделяемых библиотеках, которые использует программа. Разделяемые библиотеки обычно не отображаются в память непрерывно с основным кодом программы.

• Данные программы. Этот раздел используется для хранения переменных программы, не являющихся локальными для функций. Он включает как глобальные, так и статические переменные. Раздел данных обычно содержит динамическую область памяти, называемую "кучей программы", для хранения динамически выделяемых переменных.

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

Хотя это высокоуровневый взгляд на организацию памяти процесса, он показывает, как воздействие уязвимости переполнения буфера меняется в зависимости от того, где расположен буфер. Следующие разделы рассматривают распространенные и уникальные шаблоны атак, связанные с каждым расположением.

Переполнения стека

Переполнения стека -- это переполнения буфера, в которых целевой буфер расположен в runtime-стеке программы. Они лучше всего изучены и исторически были самым прямолинейным типом переполнений буфера для эксплуатации. Этот раздел рассматривает основы runtime-стека программы, а затем показывает, как атакующие эксплуатируют стековые переполнения буфера.

Абстрактный тип данных "стек"

С точки зрения общей computer science стек -- это абстрактный тип данных (ADT), используемый для упорядоченного хранения и извлечения серии элементов данных. Пользователям структуры данных "стек" обычно доступны две операции для манипуляции стеком:

• **push()** Операция push добавляет элемент на вершину стека.

• **pop()** Операция pop удаляет и возвращает верхний элемент стека.

Стек -- это структура данных last-in, first-out (LIFO). Можно думать о нем как о физической стопке тарелок. Можно положить тарелку на верх стопки -- операция push() -- и можно взять тарелку с верха стопки -- операция pop(). Однако нельзя напрямую убрать тарелку из середины стопки, не убрав сначала тарелки над ней.

Runtime-стек

У каждого процесса есть runtime-стек, который также называют "стеком программы", "стеком вызовов" или просто "стеком". Runtime-стек предоставляет основу, необходимую для функций, используемых в каждом структурном языке программирования. Функции можно вызывать в произвольном порядке, они могут быть рекурсивными и взаимно рекурсивными. Runtime-стек поддерживает эту функциональность с помощью записей активации, которые фиксируют цепочку вызовов от функции к функции, чтобы по ней можно было пройти назад при возврате функций. Запись активации также включает данные, которые нужно выделять каждый раз при вызове функции, например локальные переменные, сохраненное машинное состояние и параметры функции.

Поскольку runtime-стеки являются неотъемлемой частью работы программ, они реализуются с помощью CPU, а не как чистая программная абстракция. Обычно у процессора есть специальный регистр, указывающий на вершину стека; он изменяется с помощью машинных инструкций push() и pop(). На CPU Intel x86 этот регистр называется ESP (ESP означает "extended stack pointer").

На большинстве современных CPU стек растет вниз. Это означает, что стек начинается с высокого адреса виртуальной памяти и растет в сторону более низкого адреса. Операция push вычитает из указателя стека, так что указатель стека движется к нижнему концу памяти процесса. Соответственно, операция pop прибавляет к указателю стека, перемещая его обратно к верхней части памяти.

Каждый раз, когда вызывается функция, программа создает новый стековый фрейм, который является просто зарезервированным блоком непрерывной памяти, используемым функцией для хранения локальных переменных и информации о внутреннем состоянии. Этот блок памяти зарезервирован для исключительного использования функцией до ее возврата, после чего он удаляется со стека. Чтобы понять этот процесс, рассмотрите следующий фрагмент программы:

Когда происходит вход в function_A(), стековый фрейм выделяется и помещается на вершину стека, как показано на рисунке 5-1.

Рисунок 5-1. Стек во время выполнения function_A()

Эта диаграмма является упрощенным видом стека программы, но на ней видна базовая раскладка стекового фрейма, когда функция main() вызвала function_A().

Примечание

Рисунки 5-1 и 5-2 сначала могут выглядеть запутанно, потому что стек, кажется, растет вверх, а не вниз; однако это не ошибка. Если представить адресное пространство памяти, начинающееся с 0 и продолжающееся вниз до 0xFFFFFFFF, более низкий адрес памяти ближе к 0 и поэтому выглядит выше на диаграмме.

Рисунок 5-2. Стек во время выполнения function_B()

Рисунок 5-2 показывает, как выглядел бы стек после того, как function_A() вызвала function_B().

Когда function_B() завершается, она возвращается обратно в function_A(). Стековый фрейм function_B() снимается с вершины стека, и стек снова выглядит так, как на рисунке 5-1. Это просто означает, что значение ESP восстанавливается к значению, которое было у него при вызове function_B().

Примечание

Диаграммы стека на рисунках 5-1 и 5-2 являются упрощенными представлениями. На самом деле main() -- не первая функция в стеке вызовов. Обычно до main() вызываются функции, которые настраивают окружение процесса. Например, Linux-системы glibc обычно начинаются с функции _start(), которая вызывает _libc_start_main(), а та, в свою очередь, вызывает main().

Каждая функция управляет собственным стековым фреймом, размер которого зависит от числа локальных переменных и размера каждой переменной. Локальные переменные нужно напрямую получать по мере необходимости функции, а делать это только инструкциями push и pop было бы неэффективно. Поэтому многие программы используют еще один регистр, называемый "указателем фрейма" или "базовым указателем". На CPU Intel x86 этот регистр называется EBP (EBP означает "extended base pointer"). Этот регистр указывает на начало стекового фрейма функции. К каждой переменной в данном фрейме можно обратиться, сославшись на область памяти с фиксированным смещением от базового указателя. Использование базового указателя необязательно и иногда опускается, но для целей этого обсуждения можно считать, что он присутствует.

Критически важная деталь, которую ранее обошли стороной, -- это информация о внутреннем состоянии, записываемая в каждом стековом фрейме. Информация состояния, хранимая на стеке, различается между архитектурами процессоров, но обычно включает указатель фрейма предыдущей функции и адрес возврата. Значение адреса возврата сохраняется, чтобы при возврате текущей выполняющейся функции CPU знал, где продолжать выполнение. Конечно, указатель фрейма также должен быть восстановлен, чтобы обращения к локальным переменным оставались согласованными после того, как функция вызвала подфункцию, выделившую собственный стековый фрейм.

Соглашения вызова функций

Соглашение вызова описывает, как параметры функции передаются в функцию и какое обслуживание стека должно выполняться вызывающей и вызываемой функциями. Раздел "Runtime-стек" ранее в этой главе рассматривает самый популярный тип соглашения вызова; однако соглашения вызова различаются в зависимости от архитектур процессоров, ОС и компиляторов.

Компиляторы могут переключаться между соглашениями вызова для целей оптимизации; например, одно популярное оптимизированное соглашение вызова x86 -- fastcall. Fastcall по возможности передает параметры функции в регистрах, что может ускорить доступ к переменным и уменьшить накладные расходы на обслуживание стека. У каждого компилятора немного своя версия fastcall.

Возможности языка также могут вводить разные соглашения вызова. Типичной функции-члену класса C++ нужен доступ к указателю this экземпляра класса. В системах Windows x86 указатель this передается в регистре ECX для функций с фиксированным числом параметров. В отличие от этого, компилятор GCC C++ передает указатель this как последний параметр, помещенный на стек.

Указатель стека также должен быть восстановлен в прежнее состояние, но эта задача не выполняется неявно: вызываемая функция должна сбросить указатель стека в подходящее место перед возвратом. Это необходимо, потому что сохраненные указатель фрейма и адрес возврата восстанавливаются с вершины стека. Указатель фрейма восстанавливается с помощью инструкции pop, которая неявно использует указатель стека; инструкция ret, используемая для возврата из функции, также неявно использует ESP для получения адреса возврата.

Следовательно, каждая функция, выделяющая собственный стековый фрейм, должна сохранять собственный указатель фрейма. Листинг 5-1 показывает типичный пролог функции на машинах Intel для сохранения указателя фрейма.

Листинг 5-1. Пролог функции

Пролог не требует, чтобы вызывающая функция специально помещала адрес возврата на стек; эта задача выполняется инструкцией call. Поэтому раскладка стека при вызове function_B() выглядит как на рисунке 5-3.

Рисунок 5-3. Подробная раскладка стека

Примечание

Вы можете заметить, что пролог в листинге 5-1 включает кажущуюся бесполезной инструкцию (mov edi, edi). На самом деле эта инструкция является заполнителем, добавленным для облегчения runtime-патчинга при системном мониторинге и отладке.

Эксплуатация переполнений стека

Как видно, локальные переменные находятся очень близко друг к другу; фактически они расположены в памяти непрерывно. Поэтому если в программе есть уязвимость, позволяющая записывать данные за пределы локального стекового буфера, эти данные перезаписывают соседние переменные. Эти соседние переменные могут включать другие локальные переменные, информацию состояния программы и даже аргументы функции. В зависимости от того, сколько байтов можно записать, атакующие также могут повредить переменные и информацию состояния в предыдущих стековых фреймах.

Примечание

Компиляторы иногда добавляют padding между одной переменной и следующей, в зависимости от нескольких факторов, таких как уровни оптимизации и размеры переменных. Для целей этого обсуждения можно считать переменные непрерывными.

Для начала рассмотрим простой случай записи поверх локальной переменной. Опасность записи поверх локальной переменной в том, что можно произвольно изменить значение переменной способом, который приложение не предполагало. Такое изменение состояния часто может иметь нежелательные последствия. Рассмотрите пример в листинге 5-2.

Листинг 5-2. Ошибочный расчет длины на единицу

Предположим, что переменная authenticated расположена в верхней части стекового фрейма, то есть по более высокому адресу памяти, чем переменная buffer. Стек функции выглядит как на рисунке 5-4.

Рисунок 5-4. Стековый фрейм authenticate() до эксплуатации

Примечание

Рисунок 5-4 демонстрирует одну возможную раскладку для листинга 5-2; однако по исходному коду нельзя окончательно определить, как переменные внутренне упорядочены в стековом фрейме. Компилятор может (и часто делает это) переупорядочивать переменные для целей оптимизации.

В функции authenticate() есть переполнение буфера. Конкретно, функция sprintf() не ограничивает объем данных, которые записывает в выходной буфер. Поэтому если строка username имеет длину около 1024 байтов, данные записываются за пределы переменной buffer и в переменную authenticated. (Помните, что authenticated находится в верхней части стекового фрейма.) Рисунок 5-5 показывает, что происходит при срабатывании переполнения.

Рисунок 5-5. Стековый фрейм authenticate() после эксплуатации

Переменная authenticated -- простая переменная состояния, указывающая, смог ли пользователь успешно войти в систему. Значение ноль означает, что аутентификация не удалась; ненулевое значение означает успех. Переполняя переменную buffer, атакующий может перезаписать переменную authenticated, тем самым сделав ее ненулевой. Следовательно, вызывающий код ошибочно считает атакующего успешно аутентифицированным!

Перезапись соседних локальных переменных -- полезная техника, но она не является универсально применимой. Техника зависит от того, какие переменные доступны для перезаписи, как компилятор упорядочивает переменные в памяти и что программа делает с ними после переполнения. Более общая техника -- нацелиться на сохраненную информацию состояния в каждом стековом фрейме, а именно на сохраненный указатель фрейма и адрес возврата. Из этих двух переменных адрес возврата наиболее непосредственно полезен атакующим. Если переполнение буфера может перезаписать сохраненный адрес возврата, приложение можно перенаправить в произвольную точку после возврата текущей выполняющейся функции. Этот процесс показан на рисунке 5-6.

Рисунок 5-6. Перезапись адреса возврата

По сути атакующий выбирает адрес в программе, где расположен какой-то полезный код, и перезаписывает адрес возврата этим новым адресом. Точное место зависит от того, чего атакующий хочет добиться, но есть два базовых варианта:

• Выполнение можно перенаправить в секцию кода выполняемого приложения или в какой-либо код в разделяемой библиотеке, который делает что-то полезное, например в функцию system() в UNIX libc, запускающую команды через shell.

• Выполнение можно перенаправить в область памяти, содержащую данные, контролируемые атакующим, например в глобальную переменную, место на стеке или статический буфер. В этой ситуации атакующий заполняет целевое место возврата небольшим фрагментом позиционно-независимого кода, который делает что-то полезное, например подключается обратно к атакующему и запускает shell на подключенном сокете. Такие небольшие фрагменты кода обычно называются shellcode.

Атаки SEH

Системы Windows могут быть уязвимы к небольшой вариации традиционных атак переполнения стека; эта вариация известна как "smashing the structured exception handlers". Windows предоставляет structured exception handling (SEH), чтобы программы могли регистрировать обработчик, который согласованно реагирует на ошибки. Когда поток вызывает исключение, у потока есть шанс поймать это исключение и восстановиться. Каждый раз, когда функция регистрирует обработчик исключений, он помещается на вершину цепочки текущих зарегистрированных обработчиков исключений. Когда выбрасывается исключение, эта цепочка проходится с вершины до тех пор, пока не будет найден правильный тип обработчика для выброшенного исключения. Если подходящий обработчик исключений не найден, исключение передается "unhandled exception filter", который обычно завершает процесс.

Примечание

Обработка исключений -- это возможность ряда языков, популяризированная языком программирования C++. Хотя обработка исключений C++ (EH) значительно сложнее базового механизма Windows SEH, C++ исключения в Windows реализованы поверх SEH. Если вы хотите узнать больше об обработке исключений Windows C++, стоит посмотреть материал по адресу www.openrce.org/articles/full_view/21.

SEH предоставляет удобный метод эксплуатации переполнений стека в Windows-системе, потому что регистрационные структуры обработчиков исключений расположены на стеке. Каждая структура имеет адрес процедуры обработчика и указатель на родительские обработчики. Эти структуры показаны на рисунке 5-7.

Рисунок 5-7. Раскладка Windows SEH

Когда происходит исключение, эти записи проходятся от самого недавно установленного обработчика назад к первому. На каждом этапе обработчик выполняется, чтобы определить, подходит ли он для текущего выброшенного исключения. (Это объяснение немного упрощено, но есть отличная статья, описывающая процесс, по адресу www.microsoft.com/msj/0197/exception/exception.aspx.)

Следовательно, если атакующий может вызвать переполнение стека, за которым следует какое-либо исключение, эти регистрационные структуры исключений исследуются, и адрес обработчика исключения в каждой структуре вызывается до тех пор, пока не будет найден подходящий. Поскольку это структуры на поврежденном атакующим стеке, приложение переходит по адресу, выбранному атакующим. Когда возможно переполнить буфер довольно большим объемом, атакующий может скопировать данные поверх всего стека, что приводит к исключению при перезаписи базы стека. Затем приложение использует поврежденную SEH-информацию на стеке и переходит по произвольному адресу. Этот процесс изображен на рисунке 5-8.

Рисунок 5-8. Эксплойт SEH

Ошибки off-by-one

Повреждение памяти часто вызывается неправильным расчетом длины массива. Среди самых распространенных ошибок -- ошибки off-by-one, при которых расчет длины ошибается на один элемент массива. Такая ошибка обычно вызвана тем, что не учитывается завершающий элемент или неправильно понимается способ работы индексации массивов. Рассмотрите следующий пример:

Функция process_string() начинает с чтения небольшого числа символов из аргумента src и сохранения их в стековый буфер dest. Этот код пытается предотвратить переполнение буфера, если в src больше 32 символов, но у него есть простая проблема: он может записать один элемент за пределы dest. Индексы массивов начинаются с 0 и продолжаются до sizeof(array) - 1, поэтому массив с 32 элементами имеет допустимые индексы от 0 до 31. Предыдущий код индексирует один элемент за концом dest, поскольку условие, управляющее циклом, равно (i <= sizeof(dest)), когда должно быть (i < sizeof(dest)). Если i увеличивается до значения 32 в уязвимом коде, оно проходит проверку длины, и программа устанавливает dest[32] равным src[32].

Такой тип проблемы многократно всплывает в коде, работающем со строками C. Строки C требуют места для хранения каждого байта строки, а также одного дополнительного байта для NUL-символа, используемого для завершения строки. Часто этот NUL-байт учитывается неправильно, что может приводить к тонким ошибкам off-by-one, таким как в листинге 5-3.

Листинг 5-3. Ошибочный расчет длины на единицу

Этот код использует функцию strlen(), чтобы проверить, достаточно ли места для копирования имени пользователя в буфер. Функция strlen() возвращает число символов в строке C, но не считает завершающий NUL-символ. Поэтому если строка имеет 1024 символа согласно strlen(), в памяти она фактически занимает 1025 байтов. В функции get_user(), если предоставленная строка user имеет ровно 1024 символа, strlen() возвращает 1024, sizeof() возвращает 1024, и проверка длины проходит. Следовательно, функция strcpy() записывает 1024 байта строковых данных плюс завершающий NUL-символ, вызывая запись на один байт сверх меры в buf.

Можно ожидать, что ошибочные расчеты off-by-one редко, если вообще когда-либо, эксплуатируемы. Однако на ОС, работающих на машинах Intel x86, эти ошибки часто эксплуатируемы, потому что можно перезаписать младший байт сохраненного указателя фрейма. Как вы уже знаете, во время выполнения программы каждая функция выделяет стековый фрейм для хранения локальных переменных. Адрес этого стекового фрейма, известный как базовый указатель или указатель фрейма, хранится в регистре EBP. Как часть пролога функции, программа сохраняет старый базовый указатель на стек прямо рядом с адресом возврата. Если off-by-one переполнение буфера срабатывает на буфере, расположенном прямо под сохраненным базовым указателем, NUL-байт записывается на один байт за конец буфера, что соответствует младшему байту сохраненного базового указателя. Это означает, что при возврате функции восстановленный базовый указатель неверен на величину до 255 байтов, как показано на рисунке 5-9.

Рисунок 5-9. Стековый фрейм off-by-one

Если новый базовый указатель указывает на какие-то контролируемые пользователем данные (например, символьный буфер), пользователи затем могут задать значения локальных переменных из предыдущего стекового фрейма, а также сохраненный базовый указатель и адрес возврата. Следовательно, когда вызывающая функция возвращается, может быть задан произвольный адрес возврата, и можно получить полный контроль над программой.

Ошибки off-by-one также могут быть эксплуатируемы, когда элемент записывается за пределы массива в другую переменную, используемую этой функцией. Последствия off-by-one ошибки для безопасности в такой ситуации зависят от того, как соседняя переменная используется после переполнения. Если переменная является целым числом, указывающим размер, она усекается, и программа может выполнять неправильные расчеты на основе ее значения. Соседняя переменная также может напрямую влиять на модель безопасности. Например, это может быть ID пользователя, позволяющий пользователям получать права, на которые они не имеют права. Хотя такие эксплойты специфичны для реализации, их воздействие может быть таким же серьезным, как у обобщенных атак.

Переполнения кучи

Переполнения кучи -- более недавнее развитие эксплуатации. Хотя сейчас они распространены, общие техники эксплуатации кучи появились только в июле 2000 года. Изначально эти техники были представлены опытным исследователем безопасности, известным как Solar Designer. (Его исходный advisory доступен по адресу www.openwall.com/advisories/OW-002-netscape-jpeg/.) Чтобы понять, как работает эксплуатация кучи, нужно быть знакомым с тем, как управляется куча. Следующие разделы рассматривают основы управления кучей и показывают, как эксплуатируются переполнения буфера в куче.

Управление кучей

Хотя реализации кучи сильно различаются, в большинстве алгоритмов присутствуют некоторые общие элементы. По сути, когда выполняется вызов malloc() или похожей процедуры выделения, некоторый объем памяти берется из кучи и возвращается пользователю. Когда эта память освобождается с помощью free(), система должна пометить ее как свободную, чтобы позже ее можно было использовать снова. Следовательно, нужно хранить состояние областей памяти, возвращаемых вызывающим сторонам, чтобы память можно было эффективно выдавать и возвращать. Во многих случаях эта информация состояния хранится inline. Конкретно, большинство реализаций возвращает пользователю блок памяти, перед которым расположен заголовок, описывающий некоторые базовые характеристики блока, а также дополнительную информацию о соседних блоках памяти. Тип информации в заголовке блока обычно включает следующее:

• Размер текущего блока

• Размер предыдущего блока

• Свободен ли блок или используется

• Возможно, некоторые дополнительные флаги

Примечание

BSD-системы управляют памятью кучи иначе, чем большинство других ОС. Они хранят большую часть информации о блоках out of band.

Свободные блоки часто сцепляются друг с другом с помощью стандартной структуры данных, например односвязного или двусвязного списка. Большинство реализаций кучи определяет минимальный размер блока, достаточный для хранения указателей на предыдущий и следующий элементы списка, и использует это пространство для хранения указателей, когда блок не используется. Рисунок 5-10 -- пример двух базовых структур блоков, специфичных для реализаций glibc malloc().

Рисунок 5-10. Структура кучи glibc

Обратите внимание: такая организация блоков означает, что срабатывание переполнения приводит к повреждению информации заголовков выделенных фрагментов памяти, а также данных управления списками.

Эксплуатация переполнений кучи

Как вы, возможно, догадались, возможность произвольно изменять данные заголовков и указатели списков (как при переполнении буфера) дает атакующим возможность нарушить управление блоками кучи. Эти нарушения можно использовать для манипуляции заголовками блоков, чтобы получить надежное произвольное выполнение за счет алгоритмов обслуживания кучи, особенно обслуживания списков свободных блоков. После первоначального открытия Solar Designer этот процесс был подробно описан в Phrack 57 (www.phrack.org/phrack/57/p57-0x09). Следующий список резюмирует стандартную технику:

1. Предполагается, что блоки, помеченные как свободные, содержат указатели списка на следующий и предыдущий блоки в списке свободных фрагментов.

2. Когда блок освобождается, он часто объединяется с соседними блоками, если они тоже свободны.

3. Поскольку два блока объединяются в один, алгоритм кучи удаляет следующий фрагмент, который изначально был в списке свободных, корректирует размер освобождаемого фрагмента, чтобы отразить, что теперь он больше, а затем добавляет новый более крупный фрагмент в список свободных.

4. Переполнение в куче используется, чтобы пометить следующий фрагмент как свободный, чтобы позже он был отсоединен от списка свободных.

5. Буфер переполнения устанавливает указатели списка в поврежденном фрагменте в места, полезные атакующему.

6. Когда выполняется операция unlink, предоставленное атакующим значение фиксированного размера записывается в определенное атакующим место памяти.

Чтобы понять, почему отсоединение фрагмента приводит к произвольной перезаписи, рассмотрите следующий код для отсоединения элемента от двусвязного списка:

Этот код удаляет ListElement, обновляя указатели в соседних элементах списка, чтобы убрать ссылки на текущий элемент, element. Если бы вы могли задать значения element->next и element->prev, вы увидели бы, что этот код невольно обновляет произвольные области памяти значениями, которые вы контролируете. Этот процесс показан до отсоединения на рисунке 5-11 и после отсоединения на рисунке 5-12.

Рисунок 5-11. Связный список до операции unlink

Рисунок 5-12. Связный список после операции unlink

Возможности перезаписать область памяти контролируемым значением обычно достаточно атакующим, чтобы получить контроль над процессом. Можно перезаписать много полезных значений, позволяющих атакующим скомпрометировать приложение. Несколько популярных целей включают следующее:

• Global offset table (GOT)/process linkage table (PLT). UNIX ELF-бинарники используют несколько структур загрузчика, чтобы разрешать вызываемые функции из библиотек в адреса. Эти структуры позволяют разделяемым библиотекам располагаться где угодно в памяти, так что приложению не нужны статические адреса API-функций во время компиляции. Нацеливаясь на эти структуры, атакующие могут перенаправить выполнение в произвольное место при вызове определенной API-функции (например, free()).

• Exit handlers. Exit handlers -- это таблица указателей функций, вызываемых при выходе процесса в UNIX ОС. Перезаписывая одно из этих значений, можно получить произвольное выполнение, когда процесс вызывает функцию exit() или возвращается из функции main().

• Lock pointers. Windows использует набор указателей функций в process environment block (PEB), чтобы предотвращать несинхронизированное изменение информации процесса конкурирующими потоками. Эти lock pointers можно перезаписать, а затем запустить определенными типами исключительных условий.

• Процедуры обработчиков исключений. Windows PEB поддерживает адрес для процедуры unhandled exception filter. Эта процедура вызывается, когда исключение не обрабатывается успешно никаким другим обработчиком исключений. Распространенная техника -- использовать код обслуживания списка, чтобы перезаписать процедуру unhandled exception при обновлении одной части списка (например, предыдущего элемента), а затем вызвать нарушение доступа к памяти при обновлении другой части списка (следующего элемента). Эта техника гарантирует, что unhandled exception filter будет вызван немедленно, при условии что другой обработчик исключений не поймает успешно возникшее исключение нарушения доступа.

• Указатели функций. Приложения используют указатели функций по разным причинам, например для вызова функций из динамически загружаемых библиотек, для виртуальных функций-членов C++ или для абстрагирования низкоуровневых рабочих функций в opaque-структурах. Перезапись специфичных для приложения указателей функций может дать надежный эксплойт против приложения.

Переполнения глобальных и статических данных

Глобальные и статические переменные используются для хранения данных, сохраняющихся между разными вызовами функций, поэтому обычно они хранятся в сегменте памяти, отличном от переменных стека и кучи. Обычно эти места не содержат общих runtime-структур данных программы, таких как записи активации стека и данные фрагментов кучи, поэтому эксплуатация переполнения в этом сегменте требует специфичных для приложения атак, похожих на уязвимость в листинге 5-2. Эксплуатируемость зависит от того, какие переменные могут быть повреждены при переполнении буфера и как эти переменные используются. Например, если могут быть повреждены переменные-указатели, вероятность эксплуатации возрастает, поскольку такое повреждение вводит возможность произвольных перезаписей памяти.

Shellcode

Переполнения буфера обычно эксплуатируются путем перенаправления выполнения в известное место памяти, где хранятся данные, контролируемые атакующим. Чтобы эксплойт был успешным, это место должно содержать исполняемый машинный код, позволяющий атакующим выполнять вредоносные действия. Это достигается созданием небольших фрагментов машинного кода, предназначенных для запуска shell, подключения обратно к исходному пользователю или выполнения чего угодно по выбору атакующего. На момент написания этой книги самая распространенная тенденция в создании shellcode использует stub'ы, способные загружать дополнительные компоненты по требованию через подключенный сокет, по мере необходимости атакующего на другом конце.

Написание кода

На самом базовом уровне shellcode -- это небольшой фрагмент позиционно-независимого кода, использующий системные API для достижения ваших целей. Чтобы увидеть, как это делается, рассмотрите простой случай запуска shell в UNIX. В этом случае код, который вы хотите выполнить, примерно таков:

Этот простой код при запуске порождает командную shell. Если бы этот код выполнялся в сетевой службе, дескриптор сокета, с которым подключен пользователь, нужно было бы продублировать поверх stdin, stdout и, возможно, stderr.

Чтобы построить машинный код, необходимый для запуска shell, нужно понять, как этот код работает на более низком уровне. Функция execve() экспортируется стандартной библиотекой C, поэтому обычная программа сначала нашла бы реализацию libc execve() с небольшой помощью загрузчика, а затем вызвала бы ее. Поскольку эту функциональность может быть трудно воспроизвести в shellcode разумного размера, обычно хочется найти более простое решение. Как оказывается, execve() также является системным вызовом в UNIX-системах, и все, что делает функция libc, -- выполняет системный вызов.

Вызов системных вызовов в ОС на базе Intel обычно включает построение списка аргументов (в регистрах или на стеке, в зависимости от ОС), а затем просьбу к ядру выполнить системный вызов от имени процесса. Это можно сделать разными методами. Для Intel-систем функциональность системного вызова может опираться на программное прерывание, инициируемое инструкцией int; call gate, вызываемый с помощью lcall; или специализированную машинную поддержку, например sysenter. Для Linux и многих вариантов BSD прерывание int 128 зарезервировано для системных вызовов. Когда это прерывание генерируется, ядро обрабатывает его, определяет, что процессу нужно выполнить некоторую системную функцию, и выполняет запрошенную задачу. Процедура для Linux-систем такова:

1. Поместить параметры системного вызова в регистры общего назначения, начиная с EBX. Если системному вызову требуется больше пяти параметров, дополнительные параметры помещаются на стек.

2. Поместить номер желаемого системного вызова в EAX.

3. Использовать инструкцию int 128, чтобы выполнить системный вызов.

Изначально ассемблерный код выглядел бы примерно так:

Почти вся функциональность, которая нужна при создании shellcode, состоит из серии системных вызовов и следует тем же базовым принципам, представленным здесь. В Windows номера системных вызовов не согласованы между версиями ОС, поэтому большинство Windows shellcode загружает системные библиотеки и вызывает функции в этих библиотеках. Хакерская группа Last Stage of Delirium (LSD) задокументировала основу того, что используется для написания большинства современного Windows shellcode, по адресу www.lsd-pl.net/projects/winasm.zip.

Поиск своего кода в памяти

Построенные фрагменты машинного кода должны быть позиционно-независимыми, то есть должны успешно выполняться независимо от своего расположения в памяти. Чтобы понять, почему это важно, рассмотрите пример из предыдущего раздела: нужно предоставить адрес вектора массива аргументов и адрес строки "/bin/sh" для параметра pathname. Используя абсолютные адреса, вы сильно ограничиваете надежность shellcode и должны были бы изменять его для каждого написанного эксплойта. Поэтому нужен метод динамического определения этих адресов независимо от окружения процесса, в котором выполняется код.

Обычно на CPU Intel x86 строки или данные, необходимые shellcode, предоставляются рядом с кодом, а их адрес вычисляется независимо. Чтобы понять, как это работает, рассмотрите семантику инструкции call. Эта функция неявно сохраняет адрес возврата на стеке; это адрес первого байта после инструкции call. Поэтому shellcode часто строится в следующем формате:

Этот пример переходит в конец кода, а затем использует call, чтобы запустить код, расположенный сразу после инструкции jmp. В чем смысл этой косвенности? По сути, благодаря тому, что инструкция call неявно помещает адрес возврата на стек, на стеке оказывается относительный адрес строки "/bin/sh". Следовательно, адрес "/bin/sh" можно вычислить автоматически независимо от того, где shellcode расположен в целевом приложении. Объединяя это с информацией из предыдущего раздела, shellcode execve() выглядел бы примерно так:

Как видно, код для запуска shell довольно прямолинеен: нужно просто заполнить EBX, ECX и EDX значениями pathname, argv и envp соответственно, а затем вызвать системный вызов. Этот пример -- простой фрагмент shellcode, но более сложный shellcode основан на тех же принципах.

Механизмы защиты

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

Глава 3, "Эксплуатационный анализ", обсуждала несколько таких технологий с высокоуровневой эксплуатационной точки зрения. Этот раздел опирается на материал главы 3, сосредоточиваясь на технических деталях распространенных защит от повреждения памяти и рассматривая потенциальные и реальные слабости этих механизмов. Это обсуждение не является исчерпывающим исследованием механизмов защиты, но затрагивает самые распространенные из них.

Stack cookies

Stack cookies (также известные как "canary values") -- это метод, разработанный для обнаружения и предотвращения эксплуатации переполнения буфера на стеке. Stack cookies -- compile-time решение, присутствующее в большинстве стандартных приложений и библиотек, поставляемых с Windows XP SP2 и более поздними версиями. Также существует несколько UNIX-реализаций защит stack cookie, наиболее заметные -- ProPolice и Stackguard.

Stack cookies работают путем вставки случайного 32-битного значения (обычно генерируемого во время выполнения) на стек сразу после сохраненного адреса возврата и сохраненного указателя фрейма, но перед локальными переменными в каждом стековом фрейме, как показано на рисунке 5-13. Этот cookie вставляется при входе в функцию и проверяется непосредственно перед возвратом функции. Если значение cookie было изменено, программа может вывести, что стек поврежден, и предпринять соответствующее действие. Эта реакция обычно включает запись проблемы в журнал и немедленное завершение. Stack cookie предотвращает эксплуатацию традиционных переполнений стека, поскольку поврежденный адрес возврата никогда не используется.

Рисунок 5-13. Стековый фрейм с cookies и без них

Ограничения

Эта технология эффективна, но не безупречна. Хотя она предотвращает перезапись сохраненного указателя фрейма и сохраненного адреса возврата, она не защищает от перезаписи соседних локальных переменных. Рисунок 5-5 показывал, как перезапись локальных переменных может подорвать безопасность системы, особенно когда повреждаются значения указателей, которые функция использует для изменения данных. Изменение этих значений указателей обычно приводит к тому, что атакующий захватывает контроль над приложением, перезаписывая указатель функции или другое полезное значение. Однако многие системы защиты стека переупорядочивают локальные переменные, что может минимизировать риск перезаписи соседних переменных.

Еще одна атака -- записать данные за stack cookie и перезаписать параметры текущей функции. Атакующий повреждает stack cookie, перезаписывая параметры функции, но цель атаки -- не позволить функции вернуться. В некоторых случаях перезапись параметров функции позволяет атакующему получить контроль над приложением до возврата функции, тем самым делая защиту stack cookie неэффективной.

Хотя эта техника кажется полезной для атакующих, оптимизация иногда может непреднамеренно устранить шанс эксплуатации ошибки. Когда значение переменной используется часто, компилятор обычно генерирует код, который один раз считывает его со стека, а затем держит в регистре на протяжении функции или той части функции, где значение используется повторно. Поэтому даже если аргумент или локальная переменная часто используются после срабатывания переполнения, атакующие могут не суметь использовать этот аргумент для выполнения произвольных перезаписей.

Еще одна похожая техника в Windows -- не беспокоиться о сохраненном адресе возврата, а вместо этого целиться в перезапись SEH. Так атакующий может повредить записи SEH и вызвать нарушение доступа до возврата текущей выполняющейся функции; следовательно, контролируемый атакующим код выполняется, а переполнение так и не обнаруживается.

Наконец, обратите внимание, что stack cookies -- compile-time решение и может быть нереалистичным вариантом, если разработчики не могут перекомпилировать все приложение. У разработчиков может не быть доступа ко всему исходному коду, например к коду в коммерческих библиотеках. Также могут быть проблемы с изменением build-среды для крупного приложения, особенно с компонентами, оптимизированными вручную.

Усиление реализации кучи

Переполнения кучи обычно эксплуатируются через операции unlink, выполняемые системными процедурами выделения и освобождения памяти. Операции со списками в процедурах управления памятью можно использовать для записи в произвольные места памяти и полного захвата контроля над приложением. В ответ на эту угрозу ряд систем усилил свои реализации кучи, чтобы сделать их более устойчивыми к эксплуатации.

Windows XP SP2 и более поздние версии реализовали различные защиты, гарантирующие, что операции кучи непреднамеренно не позволяют атакующим вредоносно манипулировать процессом. Эти механизмы включают следующее:

• 8-битный cookie хранится в каждой структуре заголовка кучи. Операция XOR объединяет этот cookie с глобальным cookie кучи и адресом фрагмента кучи, деленным на 8. Если результирующее значение не равно 0, произошло повреждение кучи. Поскольку в этой операции используется адрес фрагмента кучи, cookies не должны быть уязвимы к brute-force атакам.

• Проверки выполняются всякий раз, когда происходит операция unlink, чтобы убедиться, что предыдущий и следующий элементы действительно допустимы. Конкретно, и следующий, и предыдущий элементы должны указывать обратно на текущий элемент, который вот-вот будет отсоединен. Если они этого не делают, куча считается поврежденной, и операция прерывается.

UNIX-реализация кучи glibc также была усилена, чтобы предотвратить легкую эксплуатацию кучи. Разработчики glibc добавили проверки unlink в свой код управления кучей, похожие на защиты Windows XP SP2.

Ограничения

Технологии защиты кучи не идеальны. У большинства есть слабости, которые все еще позволяют атакующим использовать структуры данных кучи для надежной (или относительно надежной) эксплуатации. Некоторые опубликованные работы об обходе защиты кучи Windows включают следующее:

• "Defeating Microsoft Windows XP SP2 Heap Protection and DEP Bypass" by Alexander Anisimov (www.maxpatrol.com/defeating-xpsp2-heap-protection.htm)

• "A New Way to Bypass Windows Heap Protections" by Nicolas Falliere (www.securityfocus.com/infocus/1846)

• "Windows Heap Exploitation" by Oded Horovitz and Matt Connover (www.cybertech.net/~sh0ksh0k/heap/XPSP2%20Heap%20Exploitation.ppt)

UNIX-реализации glibc прошли похожую проверку. Один полезный ресурс -- "The Malloc Maleficarum" by Phantasmal Phantasmagoria (www.securityfocus.com/archive/1/413007/30/0/threaded).

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

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

Защита неисполняемого стека и кучи

Многие CPU предоставляют тонкую защиту страниц памяти, позволяя CPU помечать страницу памяти как читаемую, записываемую или исполняемую. Если программа полностью разделяет код и данные, можно предотвратить запуск shellcode, пометив страницы данных как неисполняемые. Принудительно обеспечивая защиту неисполняемой памяти, CPU предотвращает самый популярный метод эксплуатации: передачу потока управления в место памяти, где уже находятся созданные атакующим данные.

Примечание

CPU Intel до недавнего времени (2004) не обеспечивали неисполняемые страницы памяти. Для обхода этого ограничения были разработаны интересные обходные пути, наиболее заметные -- командой разработки PaX (теперь часть команды GR-Security). Документация о внутреннем устройстве PaX доступна по адресу http://pax.grsecurity.net/.

Ограничения

Поскольку неисполняемая память обеспечивается CPU, прямой обход этой защиты невозможен: обычно атакующий полностью лишен возможности направить выполнение в место на стеке или в куче. Однако это не мешает атакующим возвращаться в полезный код в исполняемых секциях кода, будь то в эксплуатируемом приложении или в разделяемой библиотеке. Одна популярная техника обхода этих защит -- построить на стеке серию адресов возврата, чтобы атакующий мог выполнить несколько вызовов полезных API-функций. Часто атакующие могут вернуться в API-функцию для снятия защиты с области памяти, содержащей данные, которые они контролируют. Это помечает целевую страницу как исполняемую и отключает защиту, позволяя эксплойту запустить собственный shellcode.

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

Рандомизация раскладки адресного пространства

Address space layout randomization (ASLR) -- это технология, пытающаяся смягчить угрозу переполнений буфера путем рандомизации того, куда данные и код приложения отображаются во время выполнения. По сути секции данных и кода отображаются в (несколько) случайное место памяти при загрузке. Поскольку критически важная часть эксплуатации переполнения буфера включает перезапись ключевых структур данных или возврат в конкретные места памяти, ASLR теоретически должен предотвращать надежную эксплуатацию, потому что атакующие больше не могут полагаться на статические адреса. Хотя ASLR является формой security by obscurity, это весьма эффективная техника предотвращения эксплуатации, особенно при использовании вместе с некоторыми другими уже обсужденными превентивными технологиями.

Ограничения

Победа над ASLR по сути опирается на поиск слабого места в реализации ASLR. Атакующие обычно пытаются принять один из следующих подходов:

• Найти что-то в памяти, что находится в статическом месте несмотря на ASLR. Неважно, что это за статический элемент, он, вероятно, так или иначе полезен. Примеры статически расположенных элементов могут включать базовые исполняемые файлы, не содержащие relocation-информации (так что загрузчик может быть не способен их переместить), специализированные структуры данных, присутствующие во всех отображенных процессах (например, Windows PEB и Linux vsyscall page), сам загрузчик и неперемещаемые разделяемые библиотеки. Если ASLR не рандомизирует какую-либо конкретную часть процесса, на нее можно положиться и потенциально использовать для подрыва защиты ASLR.

• Использовать brute force, где возможно. Во многих случаях элементы данных смещаются в памяти, но не на большой объем. Например, текущий Linux exec-shield ASLR отображает стек в случайное место; однако более внимательное изучение кода показывает, что эти отображения включают только 256 возможных мест. Такой небольшой набор возможных мест не дает большого фактора случайности, и большинство реализаций ASLR не рандомизирует раскладку памяти дочернего процесса. Этот недостаток случайности создает потенциал для brute-force атаки, когда уязвимая служба создает дочерние процессы для обслуживания запросов. Атакующий может отправлять запросы для каждого возможного смещения и в итоге добиться успешной эксплуатации, когда найдено правильное смещение.

SafeSEH

Современные системы Windows (XP SP2+, Windows 2003, Vista) реализуют механизмы защиты для структур SEH, расположенных на стеке. Когда срабатывает исключение, целевые адреса обработчиков исключений исследуются перед вызовом, чтобы убедиться, что каждый из них является допустимой процедурой обработчика исключения. На момент написания этой книги следующая процедура определяет допустимость обработчика исключения:

1. Получить адрес обработчика исключения и определить, в какой модуль (DLL или исполняемый файл) указывает адрес обработчика.

2. Проверить, зарегистрирована ли у модуля таблица исключений. Таблица исключений -- это таблица допустимых обработчиков исключений, которые легитимно могут быть введены в структуру _EXCEPTION_REGISTRATION. Эта таблица необязательна, и модули могут ее опускать. В таком случае обработчик считается допустимым и может быть вызван.

3. Если таблица исключений существует, а адрес обработчика в структуре _EXCEPTION_REGISTRATION не соответствует допустимой записи обработчика, структура считается поврежденной, и обработчик не вызывается.

Ограничения

Защита SafeSEH -- хорошее дополнение к stack cookies, используемым в недавних выпусках Windows, поскольку она не дает атакующим использовать перезаписи SEH как метод обхода защиты stack cookie. Однако, как и другие механизмы защиты, она имела слабости в прошлом. David Litchfield из Next Generation Security Software (NGSSoftware) написал статью с подробным описанием некоторых проблем ранних реализаций SafeSEH, которые с тех пор были устранены (доступна по адресу www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf). Основные методы обхода SafeSEH включали возврат в место памяти, не принадлежащее никакому модулю (например, PEB), возврат в модули без зарегистрированной таблицы исключений или злоупотребление определенными обработчиками исключений, которые могли позволять косвенный запуск произвольного кода.

Обфускация указателей функций

Долгоживущие указатели функций часто являются целью эксплойтов повреждения памяти, потому что дают прямой метод захвата управления выполнением программы. Один метод предотвращения этой атаки -- обфусцировать любые чувствительные указатели, хранящиеся в глобально видимых структурах данных. Этот механизм защиты не предотвращает повреждение памяти, но уменьшает вероятность успешного эксплойта для любой атаки, кроме denial of service. Например, ранее вы видели, что атакующий может использовать указатели функций в PEB запущенного Windows-процесса. Чтобы помочь смягчить эту атаку, Microsoft теперь использует функции EncodePointer(), DecodePointer(), EncodeSystemPointer() и DecodeSystemPointer() для обфускации многих таких значений. Эти функции обфусцируют указатель, объединяя его значение с секретным cookie-значением с помощью операции XOR. Недавние версии Windows также используют эту антиэксплуатационную технику в частях реализации кучи.

Ограничения

Эта технология, безусловно, поднимает планку для разработчиков эксплойтов, особенно в сочетании с другими технологиями, такими как ASLR и неисполняемые страницы памяти. Однако сама по себе она не является полным решением и имеет лишь ограниченное применение. Атакующие все еще могут перезаписывать специфичные для приложения указатели функций, поскольку компиляторы сейчас не кодируют указатели функций, используемые приложением. Атакующий также может перезаписать обычные незакодированные переменные, которые в итоге дают управление выполнением через менее прямой вектор. Наконец, атакующие могут выявить обстоятельства, перенаправляющие управление выполнением ограниченным, но полезным способом. Например, когда контролируемые пользователем данные находятся в непосредственной близости от указателя функции, одно лишь повреждение младшего байта закодированного указателя функции может дать атакующим разумный шанс запустить произвольный код, особенно если они могут повторять попытки эксплуатации, пока не будет найдено успешное значение.

Оценка воздействия повреждения памяти

Теперь, когда вы знакомы с ландшафтом повреждения памяти, нужно знать, как точно оценивать риск, который представляют эти уязвимости. На то, насколько эксплуатируема уязвимость, влияет ряд факторов. Зная эти факторы, аудиторы кода могут оценить, насколько серьезна уязвимость и в какой степени ее можно эксплуатировать. Можно ли использовать ее только для аварийного завершения приложения? Можно ли выполнить произвольный код? Единственный способ узнать наверняка -- написать proof-of-concept эксплойт, но такой подход может быть слишком затратным по времени даже для оценки приложения среднего размера. Вместо этого можно разумно оценить эксплуатируемость, ответив на несколько вопросов о возникающем повреждении памяти. Этот подход не настолько окончателен, как proof-of-concept эксплойт, но требует гораздо меньше времени, что делает его достаточным для большинства оценок.

Реальная стоимость исправления уязвимостей

Вас может удивить объем сопротивления, с которым можно столкнуться при раскрытии уязвимостей поставщикам, даже поставщикам, специально нанявшим вас для оценки. Поставщики часто говорят, что потенциальные ошибки повреждения памяти не эксплуатируемы или по той или иной причине не являются проблемой. Однако повреждение памяти затрагивает приложение на самом базовом уровне, поэтому все случаи требуют серьезного рассмотрения. Более того, история показала, что атакующие и исследователи безопасности одинаково находили изобретательные способы эксплуатировать кажущееся неэксплуатируемым. На ум приходит старая пословица "where there's a will, there's a way", и когда речь идет о компрометации компьютерных систем, желания определенно много.

Поэтому большинство аудиторов считает, что поставщики ПО должны относиться ко всем проблемам как к высокоприоритетным; в конце концов, почему бы поставщикам не хотеть, чтобы их код был максимально безопасным, и не исправлять проблемы так быстро, как они могут? Правда в том, что за исправлением программных ошибок всегда стоит цена, включая время разработчиков, стоимость развертывания патча и возможные отзывы или повторные выпуски продукта. Рассмотрите, например, стоимость распространения обновления уязвимости для широко развернутой встроенной системы, такой как smart card или сотовый телефон. Обновление таких встроенных систем часто требует аппаратных модификаций или другого вмешательства квалифицированного техника. Компания поступила бы безответственно, взяв на себя расходы, связанные с обновлением, если у нее нет разумного ожидания, что ошибка эксплуатируема.

Где буфер расположен в памяти?

Расположение буфера в памяти важно: оно влияет на то, какие варианты есть у атакующего при попытке захватить контроль над процессом. Переменные в основном хранятся в трех областях памяти: стек, куча и постоянные данные (включая статические и глобальные переменные). Однако разные ОС часто дополнительно сегментируют эти три области или добавляют новые области. Могут существовать различия между инициализированными и неинициализированными глобальными данными, или система может помещать thread local storage (TLS) в специальное место. Кроме того, разделяемые библиотеки обычно имеют собственные неинициализированные и инициализированные данные, отображенные в память процесса сразу после их программного кода. При определении эксплуатируемости нужно отслеживать, где происходит повреждение памяти и какие особые соображения применимы. Эта задача может включать дополнительное исследование для понимания раскладки памяти процесса в конкретной ОС.

Какие еще данные перезаписываются?

Повреждение памяти может не ограничиваться только переменными, на которые нацелен атакующий. Оно также может перезаписывать другие переменные, усложняющие процесс эксплуатации. Такое часто происходит при попытке эксплуатировать повреждение на стеке процесса. Вы уже знаете, что уязвимости в сегменте стека чаще всего эксплуатируются перезаписью сохраненного program counter. Однако это не всегда настолько прямолинейно; часто атакующие перезаписывают локальные переменные до перезаписи сохраненного program counter, что может усложнить эксплуатацию, как показано в листинге 5-4.

Листинг 5-4. Переполнение в локальные переменные

В этом примере есть небольшая проблема: хотя атакующие могут перезаписать сохраненный program counter, они также перезаписывают переменную ptr, которая освобождается прямо перед возвратом функции. Это означает, что атакующие должны перезаписать ptr местом в памяти, которое допустимо и не приводит к сбою при вызове free(). Хотя этот метод позволяет атакующим эксплуатировать вызов free(), метод атаки сложнее, чем простая перезапись program counter (особенно если нет контролируемых пользователем данных в статическом месте памяти).

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

Примечание

Иногда для эксплуатируемости ошибки требуется больше одного возврата функции. Например, ОС, работающие на CPU Sun SPARC, часто требуют двух возвратов функции из-за того, как работают регистровые окна SPARC.

Сколько байтов можно перезаписать?

Нужно учитывать, на сколько байтов переполняется буфер и насколько пользователи контролируют размер переполнения. Переполнения слишком малого или слишком большого числа байтов могут значительно усложнить эксплойт. Очевидно, идеальная ситуация для атакующего -- выбрать произвольную длину данных для переполнения.

Иногда атакующий может переполнить буфер на фиксированный объем, что дает меньше вариантов, но успешная эксплуатация все равно вероятна. Если можно переполнить только небольшое число байтов, эксплуатируемость зависит от того, какие данные повреждаются. Если атакующий способен повредить только соседнюю переменную в памяти, которая больше никогда не используется, ошибка, вероятно, неэксплуатируема. Очевидно, чем меньше памяти атакующий может повредить, тем менее вероятно, что ошибка эксплуатируема.

И наоборот, если атакующие могут переполнить на фиксированный объем, который оказывается очень большим, ошибка неизменно приводит к повреждению огромной части памяти программы и почти наверняка завершит процесс аварийно. В некоторых случаях, когда можно повредить обработчик сигнала или обработчик исключения, атакующие могут эксплуатировать эту ситуацию и получить контроль над процессом после возникновения исключения. Самый распространенный пример -- большие стековые переполнения в Windows, поскольку атакующие могут перезаписать SEH-структуры, содержащие указатели функций, к которым обращаются при возникновении исключения.

Кроме того, некоторые ошибки могут приводить к нескольким записям в произвольные места памяти. Хотя часто возможна только одна перезапись, если можно выполнить несколько перезаписей, у атакующего больше рычагов для выбора способа эксплуатации уязвимой программы. Например, при уязвимостях форматной строки атакующие часто могут записывать в столько произвольных мест, сколько захотят, увеличивая вероятность успешной эксплуатации.

Примечание

Иногда 1- или 2-байтную перезапись легче эксплуатировать, чем 4-байтную. Например, предположим, что вы перезаписываете указатель на объект, состоящий из нескольких указателей, за которыми следует буфер с данными, которые вы контролируете. В этом случае младший байт значения указателя можно перезаписать так, чтобы он указывал на буфер данных в объекте, а не на сам объект. Вы могли бы произвольно изменить состояние любого свойства объекта и, вероятно, довольно надежно эксплуатировать ошибку.

Какие данные можно использовать для повреждения памяти?

Некоторые уязвимости повреждения памяти не допускают прямого контроля данных, используемых для перезаписи памяти. Данные могут быть ограничены на основе того, как они используются, как при ограничениях символов, однобайтных перезаписях или изменяемых атакующим вызовах memset(). Листинг 5-5 показывает пример уязвимости, где память перезаписывается данными, которые атакующий не контролирует.

Листинг 5-5. Косвенное повреждение памяти

В этом коде есть переполнение буфера в выделенной строке, манипулирующей массивом tokens. Данные, используемые для перезаписи памяти, не могут контролироваться атакующими напрямую, но перезаписанная память включает указатели на данные, контролируемые атакующим. Это может сделать эксплуатацию даже проще, чем при стандартной технике. Например, если перезаписан указатель функции, атакующим не нужна информация о раскладке памяти, потому что указатель функции можно заменить указателем на данные, контролируемые атакующим. Однако эксплуатация может быть сложнее, если, например, перезаписывается заголовок блока кучи или другая сложная структура.

Уязвимости off-by-one -- одни из самых распространенных уязвимостей, связанных с перезаписанными данными, которые атакующий не контролирует. Листинг 5-6 показывает пример уязвимости off-by-one.

Листинг 5-6. Перезапись off-by-one

Если атакующие задают длину mac ровно MAX_MAC, функция get_mac() читает на один элемент больше, чем для него выделено места (как показано в выделенной строке). В этом случае последнее прочитанное целое перезаписывает переменную key. Во время функции delete_session() переменная key передается в memset перед удалением, что позволяет атакующим перезаписать произвольное место памяти, но только NUL-байтами. Эксплуатация этой уязвимости сложна, потому что атакующие не могут выбирать, какими данными перезаписывается память. Кроме того, предоставленное атакующим место памяти затем освобождается, что означает, что атака, скорее всего, была бы направлена на процедуры управления памятью. Успешное выполнение такой атаки могло бы быть чрезвычайно трудным, особенно в многопоточных приложениях.

Листинги 5-5 и 5-6 показывают, как атакующим может быть трудно эксплуатировать уязвимость, когда перезаписываемые данные нельзя контролировать. При исследовании похожих проблем нужно определить, что входит в перезаписываемые данные и могут ли они контролироваться атакующими. Обычно атакующие имеют довольно прямой контроль над записываемыми данными или могут манипулировать возникающим повреждением, чтобы получить доступ к данным, контролируемым атакующим.

Разделяются ли блоки памяти?

Иногда в приложениях появляются ошибки, при которых менеджер памяти ошибочно выдает один и тот же блок памяти больше одного раза, хотя он все еще используется. Когда это происходит, две или более независимые части приложения используют блок памяти, ожидая, что у них есть исключительный доступ к нему, хотя на самом деле это не так. Эти уязвимости обычно вызваны одной из двух ошибок:

• Ошибка в коде управления памятью

• Неправильное использование API управления памятью

Такие типы уязвимостей также могут приводить к удаленному выполнению; однако определение того, эксплуатируемы ли уязвимости разделения блоков памяти, обычно сложно и специфично для приложения. Одна причина в том, что атакующие могут не иметь возможности точно предсказать, какая другая часть приложения получит тот же блок памяти, и не будут знать, какие данные подать для выполнения атаки. Кроме того, в приложении могут быть проблемы синхронизации, особенно в многопоточном ПО, обслуживающем большое число клиентов по мере их подключения. Несмотря на трудности, существуют процедуры эксплуатации этих уязвимостей, поэтому их не следует считать низкоприоритетными без обоснования.

Похожее повреждение памяти может произойти, когда блок памяти выделяется только один раз (правильное поведение), но затем этот блок памяти передается двум одновременно выполняющимся потокам с предположением о взаимоисключающем доступе. Такой тип уязвимости в основном вызван проблемами синхронизации и подробно рассматривается в главе 13, "Синхронизация и состояние".

Какие защиты включены?

После того как известны детали потенциально эксплуатируемой уязвимости повреждения памяти, нужно учитывать любые смягчающие факторы, которые могут предотвратить эксплуатацию. Например, если фрагмент ПО будет выполняться только на Windows XP SP2+, вы знаете, что присутствуют stack cookies и SafeSEH, поэтому типичное переполнение стека может быть неэксплуатируемым. Конечно, нельзя сбрасывать повреждение памяти со счетов только потому, что включены защитные меры. Вполне возможно, что атакующий найдет способ подорвать SafeSEH, используя небезопасный загруженный модуль, или перезаписать параметр функции, чтобы обойти stack cookies. Однако нужно учитывать эти защитные меры и пытаться оценить вероятность того, что атакующий обойдет их и надежно эксплуатирует систему.

Итоги

Эта глава объяснила, как возникает повреждение памяти и как оно может влиять на состояние приложения. В частности, вы увидели, как атакующие могут использовать ошибки повреждения памяти для захвата контроля над приложениями и выполнения вредоносных действий. Это знание необходимо при оценке уязвимостей безопасности приложений, потому что оно позволяет точно определить вероятность того, что атакующий эксплуатирует конкретную проблему повреждения памяти. Однако эксплойты повреждения памяти -- это целая отдельная область изучения, и современный уровень постоянно меняется, находя новые способы эксплуатировать ранее неэксплуатируемое. Как проверяющий, вы должны рассматривать все проблемы повреждения памяти как потенциально серьезные уязвимости, пока не сможете доказать обратное.

Эта глава исследует тонкие детали языка программирования C, которые могут отрицательно влиять на безопасность и устойчивость приложения. Конкретно, она рассматривает детали хранения примитивных типов, условия арифметического переполнения и исчерпания вниз, проблемы преобразования типов, такие как стандартные повышения типов, преобразования и сравнения signed/unsigned, расширение знака и усечение. Также вы рассмотрите некоторые интересные нюансы C, связанные с неожиданными результатами определенных операторов и другим поведением, которое часто недооценивают. Хотя эта глава сосредоточена на C, многие принципы применимы к другим языкам.

Контекст языка C

Эта глава подробно работает со спецификой языка C и использует терминологию стандартов C. Вам не нужно обращаться к стандартам, чтобы следить за материалом, но глава широко использует публичный финальный черновик стандарта C99 (ISO/IEC 9899:1999), который можно найти по адресу www.open-std.org/jtc1/sc22/wg14/www/standards.

Документ C Rationale, сопровождающий черновик стандарта, также полезен. Заинтересованным читателям стоит посмотреть отличную книгу Peter Van der Linden Expert C Programming (Prentice Hall, 1994) и второе издание The C Programming Language Kernighan и Ritchie (Prentice Hall, 1988). Возможно, вам также будет интересно приобрести финальную версию стандарта ISO или более старый стандарт ANSI; оба продаются через сайт организации ANSI (www.ansi.org).

Хотя эта глава включает недавний стандарт, содержание ориентировано на текущее массовое использование C, конкретно на стандарты ANSI C89/ISO 90. Поскольку обсуждаются низкоуровневые детали безопасности, добавлены примечания о ситуациях, где изменения между версиями C релевантны.

Иногда при обсуждении стандартов используются термины "undefined behavior" и "implementation-defined behavior". Undefined behavior -- ошибочное поведение: условия, которые компилятор не обязан обрабатывать и которые, следовательно, имеют неопределенные результаты. Implementation-defined behavior -- поведение, зависящее от нижележащей реализации. Оно должно обрабатываться согласованным и логичным способом, а метод обработки должен быть документирован.

Обзор хранения данных

Прежде чем углубляться в тонкости C, следует повторить основы типов C, а именно их размеры хранения, диапазоны значений и представления. Этот раздел объясняет типы с общей точки зрения, исследует детали вроде бинарного кодирования, арифметики в дополнительном коде и соглашений о порядке байтов, а затем заканчивает прагматическими наблюдениями о распространенных и будущих реализациях.

Стандарты C определяют объект как область хранения данных в среде выполнения; ее содержимое может представлять значения. У каждого объекта есть связанный тип: способ интерпретировать и придавать смысл значению, хранящемуся в этом объекте. В стандартах C определены десятки типов, но эта глава сосредоточена на следующих:

• Символьные типы. Есть три символьных типа: char, signed char и unsigned char. Все три типа гарантированно занимают 1 байт хранения. Является ли тип char знаковым, определяется реализацией. Большинство текущих систем по умолчанию делает char знаковым, хотя обычно доступны флаги компилятора для изменения этого поведения.

• Целочисленные типы. Есть четыре стандартных знаковых целочисленных типа, не считая символьных типов: short int, int, long int и long long int. У каждого стандартного типа есть соответствующий беззнаковый тип, занимающий тот же объем хранения. (Примечание: тип long long int появился в C99.)

• Типы с плавающей точкой. Есть три вещественных типа с плавающей точкой и три комплексных типа. Вещественные типы с плавающей точкой -- float, double и long double. Три комплексных типа -- float _Complex, double_Complex и long double _Complex. (Примечание: комплексные типы появились в C99.)

• Битовые поля. Битовое поле -- это конкретное число битов в объекте. Битовые поля могут быть знаковыми или беззнаковыми в зависимости от объявления. Если спецификатор знакового типа не указан, знак битового поля зависит от реализации.

Примечание

Битовые поля могут быть незнакомы некоторым программистам, поскольку обычно они встречаются только в сетевом или низкоуровневом коде. Вот краткий пример битового поля:

Структура controller имеет несколько маленьких членов. id относится к 4-битной беззнаковой переменной, а tflag и rflag относятся к отдельным битам. ack -- 2-битная переменная, seqnum -- 8-битная, а code -- 16-битная. Члены этой структуры, вероятно, будут расположены как непрерывные биты в памяти, помещающиеся в одну 32-битную область.

С абстрактной точки зрения каждый целочисленный тип (включая символьные типы) представляет другой размер целого числа, который компилятор может отобразить на подходящий нижележащий архитектурно-зависимый тип данных. Символ гарантированно занимает 1 байт хранения (хотя байт не обязательно должен быть 8 битами). sizeof(char) всегда равен единице, и вы всегда можете использовать указатель на unsigned character, sizeof и memcpy(), чтобы исследовать и изменять фактическое содержимое других типов. Другие целочисленные типы имеют определенные диапазоны значений, которые они обязаны уметь представлять, и должны поддерживать определенные отношения друг с другом (например, long не может быть меньше short), но в остальном их реализация во многом зависит от архитектуры и компилятора.

Знаковые целочисленные типы могут представлять как положительные, так и отрицательные значения, тогда как беззнаковые типы могут представлять только положительные значения. У каждого знакового целочисленного типа есть соответствующий беззнаковый целочисленный тип, занимающий тот же объем хранения. У беззнаковых целочисленных типов есть два возможных типа битов: биты значения, содержащие фактическое двоичное представление значения объекта, и padding bits, которые необязательны и в остальном не определены стандартом. У знаковых целочисленных типов также есть биты значения и padding bits, а также один дополнительный бит: бит знака. Если бит знака очищен в знаковом целочисленном типе, его представление для значения идентично представлению этого значения в соответствующем беззнаковом целочисленном типе. Иными словами, нижележащий битовый шаблон для положительного значения 42 должен выглядеть одинаково независимо от того, хранится оно в int или unsigned int.

У целочисленного типа есть точность и ширина. Точность -- это число битов значения, которые использует целочисленный тип. Ширина -- это число битов, которые тип использует для представления своего значения, включая биты значения и знак, но не padding bits. Для беззнаковых целочисленных типов точность и ширина совпадают. Для знаковых целочисленных типов ширина на единицу больше точности.

Программисты могут вызывать разные типы несколькими способами. Для заданного целочисленного типа, например short int, программист обычно может опустить ключевое слово int. Поэтому ключевые слова signed short int, signed short, short int и short относятся к одному и тому же типу данных. В общем случае, если спецификаторы signed и unsigned опущены, тип считается знаковым. Однако это предположение неверно для типа char, поскольку его знаковость зависит от реализации. (Обычно chars знаковые. Если вам нужен знаковый символ со 100% уверенностью, можно явно объявить signed char.)

В C также есть богатая система псевдонимов типов, поддерживаемая через typedef, поэтому у программистов обычно есть предпочитаемые соглашения для указания переменной известного размера и представления. Например, типы вроде int8_t, uint8_t, int32_t и u_int32_t популярны у UNIX- и сетевых программистов. Они представляют 8-битное знаковое целое, 8-битное беззнаковое целое, 32-битное знаковое целое и 32-битное беззнаковое целое соответственно. Программисты Windows склонны использовать типы вроде BYTE, CHAR и DWORD, которые соответственно отображаются на 8-битное беззнаковое целое, 8-битное знаковое целое и 32-битное беззнаковое целое.

Двоичное кодирование

Беззнаковые целочисленные значения кодируются в чистой двоичной форме, то есть в системе счисления с основанием два. Каждый бит равен 1 или 0 и показывает, вносит ли степень двойки, которую представляет позиция этого бита, вклад в общее значение числа. Чтобы преобразовать положительное число из двоичной записи в десятичную, значение каждой битовой позиции n умножается на 2 n-1. Несколько примеров таких преобразований показаны в следующих строках:

Аналогично, чтобы преобразовать положительное десятичное целое в двоичное, вы многократно вычитаете степени двойки, начиная с наибольшей степени двойки, которую можно вычесть из целого числа, оставив положительный результат (или ноль). Следующие строки показывают несколько примеров преобразований:

Знаковые целые используют бит знака, а также биты значения и padding bits. Стандарты C дают три возможные арифметические схемы для целых чисел и, следовательно, три возможные интерпретации бита знака:

• Sign and magnitude. Знак числа хранится в бите знака. Он равен 1, если число отрицательное, и 0, если число положительное. Величина числа хранится в битах значения. Эта схема легка для чтения и понимания человеком, но неудобна для компьютеров, потому что для арифметических операций им приходится явно сравнивать величины и знаки.

• Ones complement. Опять же, бит знака равен 1, если число отрицательное, и 0, если число положительное. Положительные значения можно читать напрямую из битов значения. Однако отрицательные значения нельзя читать напрямую; сначала нужно инвертировать все число. В ones complement число инвертируется путем инверсии всех его битов. Чтобы найти значение отрицательного числа, нужно инвертировать его биты. Эта система лучше подходит машине, но все еще есть сложности со сложением, и, как sign and magnitude, у нее есть забавная неоднозначность двух значений нуля: положительный ноль и отрицательный ноль.

• Twos complement. Бит знака равен 1, если число отрицательное, и 0, если число положительное. Положительные значения можно читать напрямую из битов значения, но отрицательные значения нельзя читать напрямую; сначала нужно инвертировать все число. В twos complement число инвертируется путем инверсии всех битов и добавления единицы. Это хорошо работает для машины и устраняет неоднозначность двух потенциальных значений нуля.

Целые числа обычно внутренне представлены с использованием twos complement, особенно в современных компьютерах. Как упоминалось, twos complement кодирует положительные значения стандартным двоичным кодированием. Диапазон положительных значений, которые можно представить, основан на числе битов значения. 8-битное знаковое целое в twos complement имеет 7 битов значения и 1 бит знака. Оно может представлять положительные значения от 0 до 127 в 7 битах значения. Все отрицательные значения, представленные кодированием twos complement, требуют установки бита знака. Значения от -128 до -1 можно представить в битах значения при установленном бите знака, тем самым позволяя 8-битному знаковому целому представлять от -128 до 127.

Для арифметики бит знака помещается в самый значимый бит типа данных. В общем случае знаковое число twos complement ширины X может представлять диапазон целых от -2 X-1 до 2 X-1 -1. Таблица 6-1 показывает типичные диапазоны целых twos complement разных размеров.

Таблица 6-1. Максимальные и минимальные значения для целых чисел

Как описано ранее, число twos complement инвертируется путем инверсии всех битов и добавления единицы. Листинг 6-1 показывает, как получить представление -15 путем инверсии числа 15, а затем как выяснить значение неизвестного отрицательного битового шаблона.

Листинг 6-1. Представление -15 в дополнительном коде

Порядок байтов

В современных архитектурах есть два соглашения для упорядочивания байтов: big endian и little endian. Эти соглашения применяются к типам данных больше 1 байта, например short int или int. В big-endian архитектуре байты расположены в памяти начиная с самого значимого байта и заканчивая наименее значимым байтом. Little-endian архитектуры, напротив, начинают с наименее значимого байта и заканчивают самым значимым. Например, у вас есть 4-байтное целое с десятичным значением 12345. В двоичном виде это 11000000111001. Это целое расположено по адресу 500. На big-endian машине оно представлено в памяти следующим образом:

Однако на little-endian машине оно представлено так:

Машины Intel -- little endian, но RISC-машины, такие как SPARC, часто big endian. Некоторые машины способны нативно работать с обоими кодированиями.

Распространенные реализации

Практически говоря, если речь идет о современной 32-битной машине с twos complement, что можно сказать о базовых типах C и их представлениях? В общем случае ни у одного целочисленного типа нет padding bits, поэтому об этом не нужно беспокоиться. Все будет использовать представление twos complement. Байты будут иметь длину 8 бит. Порядок байтов различается: на машинах Intel это little endian, но на RISC-машинах скорее big endian.

Тип char, вероятно, по умолчанию знаковый и занимает 1 байт. Тип short занимает 2 байта, а int занимает 4 байта. Тип long также занимает 4 байта, а long long -- 8 байтов. Поскольку вы знаете, что целые кодируются в twos complement, и знаете их нижележащие размеры, определить их минимальные и максимальные значения легко. Таблица 6-2 резюмирует типичные размеры диапазонов целочисленных типов данных на 32-битной машине.

Таблица 6-2. Типичные размеры и диапазоны целочисленных типов на 32-битных платформах

Чего можно ожидать в ближайшем будущем по мере распространения 64-битных систем? Следующий список описывает несколько систем типов, которые используются сегодня или были предложены:

• ILP32. int, long и pointer все имеют 32 бита; текущий стандарт для большинства 32-битных компьютеров.

• ILP32LL. int, long и pointer все имеют 32 бита, а новый тип long long имеет 64 бита. Тип long long появился в C99. Он дает C тип с минимальной шириной 64 бита, но не меняет фундаментальные свойства языка.

• LP64. long и pointer имеют 64 бита, поэтому типы pointer и long изменились с 32-битных на 64-битные значения.

• ILP64. int, long и pointer все имеют 64 бита. Тип int был изменен на 64-битный тип, что имеет довольно значительные последствия для языка.

• LLP64. pointers и новый тип long long имеют 64 бита. Типы int и long остаются 32-битными типами данных.

Таблица 6-3 кратко резюмирует эти системы типов.

Таблица 6-3. 64-битные системы целочисленных типов

Как видно, типичные размеры типов данных соответствуют модели ILP32LL, которой придерживается большинство компиляторов на 32-битных платформах. Модель LP64 -- фактический стандарт для компиляторов, генерирующих код для 64-битных платформ. Как вы узнаете позже в этой главе, тип int является базовой единицей языка C; многие вещи неявно преобразуются в него и из него. Поскольку тип данных int так сильно используется при вычислении выражений, модель LP64 является идеальным выбором для 64-битных систем, потому что она не меняет тип данных int; в результате она в значительной степени сохраняет ожидаемое поведение преобразований типов C.

Арифметические граничные условия

Вы узнали, что базовые целочисленные типы C имеют минимальные и максимальные возможные значения, определяемые их нижележащим представлением в памяти. (Типичные диапазоны для 32-битных архитектур twos complement были представлены в таблице 6-2.) Теперь можно исследовать, что может произойти при попытке пересечь эти границы. Простая арифметика над переменной, например сложение, вычитание или умножение, может привести к значению, которое не помещается в эту переменную. Посмотрите на этот пример:

Вы знаете, что a без проблем может хранить значение 0xE0000020; таблица 6-2 указывает максимальное значение беззнаковой 32-битной переменной как 4 294 967 295, или 0xFFFFFFFF. Однако когда 0x20000020 добавляется к 0xE0000000, результат, 0x100000040, не может быть сохранен в a. Когда арифметическая операция приводит к значению выше максимально возможного представимого значения, это называется условием числового переполнения.

Вот немного другой пример:

Программист вычитает 1 из a, начальное значение которой равно 0. Полученное значение, -1, не может храниться в a, потому что оно ниже минимально возможного значения 0. Этот результат известен как условие числового исчерпания вниз.

Примечание

Условия числового переполнения также называются в литературе по безопасному программированию numeric overflows, arithmetic overflows, integer overflows или integer wrapping. Условия числового исчерпания вниз могут называться numeric underflows, arithmetic underflows, integer underflows или integer wrapping. Конкретно, могут использоваться выражения "wrapping around a value" или "wrapping below zero".

Хотя эти условия могут казаться редкими или несущественными в реальном коде, на самом деле они происходят довольно часто, и их воздействие может быть очень серьезным с точки зрения безопасности. Неправильный результат арифметической операции может подорвать целостность приложения и часто привести к компрометации его безопасности. Числовое переполнение или исчерпание вниз, происходящее в начале блока кода, может привести к тонкой серии каскадных отказов; не только результат одной арифметической операции испорчен, но и каждая последующая операция, использующая этот испорченный результат, вводит точку, где атакующий может получить неожиданное влияние.

Примечание

Хотя числовое wrapping распространено в большинстве языков программирования, это особая проблема в программах C/C++, потому что C требует от программистов выполнять низкоуровневые задачи, которые более абстрактные высокоуровневые языки обрабатывают автоматически. Эти задачи, например динамическое выделение памяти и отслеживание длины буферов, часто требуют арифметики, которая может быть уязвима. Атакующие часто используют арифметические граничные условия, манипулируя расчетом длины так, чтобы был выделен недостаточный объем памяти. Если это происходит, программа позже рискует манипулировать памятью за пределами выделенного пространства, что часто приводит к эксплуатируемой ситуации. Еще одна распространенная техника атаки -- обход проверки длины, защищающей чувствительные операции, такие как копирование памяти. Эта глава дает несколько примеров того, как условия underflow и overflow приводят к эксплуатируемым уязвимостям. В общем случае аудиторы должны помнить об арифметических граничных условиях при анализе кода и обязательно учитывать возможные последствия тонкой, каскадной природы этих дефектов.

В следующих разделах вы рассмотрите арифметические граничные условия, влияющие на беззнаковые целые, а затем исследуете знаковые целые.

Предупреждение

В примерах была предпринята попытка использовать типы int и unsigned int, чтобы избежать кода, на который влияют стандартные повышения типов C. Эта тема рассматривается далее в этой главе, в разделе "Преобразования типов", но пока отметьте: всякий раз, когда вы используете char или short в арифметическом выражении C, он преобразуется в int до выполнения арифметики.

Границы беззнаковых целых

Беззнаковые целые определены в спецификации C как подчиняющиеся правилам модульной арифметики (см. вставку "Модульная арифметика"). Для беззнакового целого, использующего X битов хранения, арифметика над этим целым выполняется по модулю 2 X. Например, арифметика над 8-битным беззнаковым целым выполняется по модулю 2 8, или по модулю 256. Еще раз посмотрите на это простое выражение:

Сложение выполняется по модулю 2 32, или по модулю 4 294 967 296 (0x100000000). Результат сложения равен 0x40, то есть (0xE0000020 + 0x20000020) modulo 0x100000000.

Еще один способ представить это -- считать, что лишние биты результата числового переполнения усекаются. Если выполнить расчет 0xE0000020 + 0x20000020 в двоичном виде, получится следующее:

Результат, который вы фактически получаете в a, равен 0x40, что имеет двоичное представление 0000 0000 0000 0000 0000 0000 0100 0000.

Модульная арифметика

Модульная арифметика -- система арифметики, широко используемая в computer science. Выражение "X modulo Y" означает "остаток от деления X на Y". Например, 100 modulo 11 равно 1, потому что при делении 100 на 11 ответ равен 9, а остаток равен 1. Оператор модуля в C записывается как %. Поэтому в C выражение (100 % 11) вычисляется в 1, а выражение (100 / 11) вычисляется в 9.

Модульная арифметика полезна для гарантии, что число ограничено определенным диапазоном, и вы часто видите ее использование для этой цели в хеш-таблицах. Чтобы объяснить: когда у вас есть X modulo Y, а X и Y -- положительные числа, вы знаете, что наибольший возможный результат равен Y-1, а наименьший -- 0. Если у вас есть хеш-таблица из 100 buckets и нужно отобразить хеш в один из buckets, можно сделать так:

Чтобы увидеть, как работает модульная арифметика, посмотрите на простой цикл:

Выражение (i % 6) по сути ограничивает i диапазоном от 0 до 5. Во время выполнения программа печатает следующее:

Можно увидеть, что по мере продвижения i от 0 до 19, i % 6 тоже продвигалось, но возвращалось обратно к 0 каждый раз, когда достигало максимального значения 5. Когда вы движетесь вперед по значению, вы оборачиваетесь вокруг максимального значения 5. Если вы движетесь назад по значениям, вы оборачиваетесь "под" 0 к максимальному значению 5.

Можно увидеть, что это то же самое, что результат сложения, но без самого старшего бита. Это недалеко от того, что происходит на машинном уровне. Например, архитектуры Intel имеют carry flag (CF), который хранит этот старший бит. В C нет механизма, позволяющего получить доступ к этому флагу, но в зависимости от нижележащей архитектуры его можно проверить через ассемблерный код.

Вот пример условия числового переполнения, возникающего из-за умножения:

Снова арифметика выполняется по модулю 0x100000000. Результат умножения равен 0xC0000840, то есть (0xE0000020 * 0x42) modulo 0x100000000. Вот он в двоичном виде:

Результат, который вы фактически получаете в a, 0xC0000840, имеет двоичное представление 1100 0000 0000 0000 0000 1000 0100 0000. Снова можно увидеть, как старшие биты, не поместившиеся в результат, фактически были усечены. На машинном уровне часто возможно обнаружить переполнение при целочисленном умножении, а также восстановить старшие биты умножения. Например, на Intel инструкция imul при умножении использует объект назначения, вдвое больший, чем исходные операнды, и устанавливает флаги OF (overflow) и CF (carry), если результат умножения требует ширины больше исходного операнда. Некоторый код даже использует inline assembly для проверки числового переполнения (обсуждается во вставке "Переполнения умножения на Intel" далее в этой главе).

Вы видели примеры того, как арифметические переполнения могут возникать из-за сложения и умножения. Еще один оператор, способный вызвать переполнения, -- сдвиг влево, который для этого обсуждения можно считать умножением на 2. Он ведет себя примерно так же, как умножение, поэтому пример не приводится.

Теперь можно посмотреть на некоторые воздействия на безопасность, связанные с числовым переполнением беззнаковых целых. Листинг 6-2 -- очищенная и отредактированная версия эксплуатируемого условия, недавно найденного в коде клиента.

Листинг 6-2. Пример целочисленного переполнения

Назначение функции make_table() -- взять ширину, высоту и начальную строку и создать таблицу в памяти, где каждая строка инициализирована тем же содержимым, что и init_row. Предположим, что пользователи контролируют размеры новой таблицы: width и height. Если они задают большие размеры, например width 1 000 000 и height 3 000, функция пытается вызвать malloc() для 3 000 000 000 байтов. Выделение, вероятно, завершается ошибкой, а вызывающая функция обнаруживает ошибку и корректно ее обрабатывает. Однако пользователи могут вызвать арифметическое переполнение в умножении width и height, если сделают размеры чуть больше. Это переполнение потенциально эксплуатируемо, потому что выделение выполняется умножением width и height, но фактическая инициализация массива выполняется циклом for. Поэтому если пользователи задают width равным 0x400 и height равным 0x1000001, результат умножения равен 0x400000400. Это значение modulo 0x100000000 равно 0x00000400, или 1024. Поэтому будет выделено 1024 байта, но затем цикл for скопирует init_row примерно на 16 миллионов раз слишком много. Умный атакующий может использовать это переполнение для захвата контроля над приложением, в зависимости от низкоуровневых деталей runtime-окружения процесса.

Посмотрите на реальную уязвимость, похожую на предыдущий пример, найденную в сервере OpenSSH. Листинг 6-3 взят из кода challenge-response аутентификации OpenSSH 3.1: auth2-chall.c, функция input_userauth_info_response().

Листинг 6-3. Пример целочисленного переполнения challenge-response в OpenSSH 3.1

Беззнаковое целое nresp контролируется пользователем, и его назначение -- сообщить серверу, сколько ответов ожидать. Оно используется для выделения массива response[] и заполнения его сетевыми данными. Во время выделения массива response[] в вызове xmalloc() значение nresp умножается на sizeof(char *), что обычно равно 4 байтам. Если пользователи задают достаточно большое значение nresp, может произойти числовое переполнение, и результат умножения может оказаться маленьким числом. Например, если nresp имеет значение 0x40000020, результат умножения на 4 равен 0x80. Следовательно, выделяется 0x80 байтов, но следующий цикл for пытается получить из пакета 0x40000020 строк! Это оказалось критической удаленно эксплуатируемой уязвимостью.

Теперь обратите внимание на числовые underflows. С беззнаковыми целыми вычитания могут вызвать оборачивание значения ниже минимального представимого значения 0. Результат underflow обычно является большим положительным числом из-за модульной природы беззнаковых целых. Вот краткий пример:

Посмотрите на расчет в двоичном виде:

Результат, который вы получаете в a, -- битовый шаблон для 0xffffffe0, который в представлении twos complement является правильным отрицательным значением -0x20. Вспомните: в модульной арифметике, если вы продвигаетесь за максимально возможное значение, вы оборачиваетесь к 0. Похожее явление происходит, если вы уходите ниже минимально возможного значения: вы оборачиваетесь к наибольшему возможному значению. Поскольку a имеет тип unsigned int, после вычитания оно имеет значение 0xffffffe0 вместо -0x20. Листинг 6-4 -- пример числового underflow с участием беззнакового целого.

Листинг 6-4. Пример underflow беззнакового целого

Этот код читает заголовок пакета из сети и извлекает 32-битное поле длины в переменную length. Переменная length представляет общее число байтов в пакете, поэтому программа сначала проверяет, что часть данных пакета не длиннее 1024 байтов, чтобы предотвратить переполнение. Затем она пытается прочитать остальную часть пакета из сети, читая (length - sizeof(struct header)) байтов в buffer. Это имеет смысл, поскольку код хочет прочитать часть данных пакета, то есть общую длину минус длину заголовка.

Уязвимость в том, что если пользователи предоставляют длину меньше sizeof(struct header), вычитание (length - sizeof(struct header)) вызывает integer underflow и в итоге передает очень большой параметр size в full_read(). Эта ошибка может привести к переполнению буфера, потому что в этот момент read() по сути будет копировать данные в буфер до закрытия соединения, что позволит атакующим захватить контроль над процессом.

Переполнения умножения на Intel

В общем случае процессоры обнаруживают, когда происходит целочисленное переполнение, и предоставляют механизмы для работы с ним; однако они редко используются для проверки ошибок и обычно недоступны из C. Например, процессоры Intel устанавливают overflow flag (OF) в регистре EFLAGS, когда умножение вызывает переполнение, но программист C не может проверить этот флаг без использования inline assembler. Иногда это делается по соображениям безопасности, например в процедурах NDR unmarshalling для обработки MSRPC-запросов в операционных системах Windows. Следующий код, взятый из rpcrt4.dll, вызывается при unmarshalling разных типов данных из RPC-запросов:

Можно увидеть, что эта функция, умножающая число предоставленных элементов на размер каждого элемента, выполняет две sanity checks. Сначала она использует jno, чтобы проверить overflow flag и убедиться, что умножение не переполнилось. Затем она убеждается, что результирующий размер меньше или равен максимально представимому значению знакового целого, 0x7FFFFFFF. Если любая проверка не проходит, функция вызывает исключение.

Границы знаковых целых

Знаковые целые -- немного другой зверь. Согласно спецификациям C, результат арифметического переполнения или underflow со знаковым целым определяется реализацией и потенциально может включать машинную ловушку или fault. Однако на большинстве распространенных архитектур результаты арифметических переполнений знаковых чисел хорошо определены, предсказуемы и не приводят ни к какому исключению. Такое граничное поведение является естественным следствием того, как арифметика twos complement реализована на аппаратном уровне, и оно должно быть согласованным на массовых машинах.

Если вы помните, максимальное положительное значение, которое можно представить в знаковом целом twos complement, -- это значение, где все биты установлены в 1, кроме самого значимого бита, который равен 0. Причина в том, что старший бит указывает знак числа, и значение 1 в этом бите означает, что число отрицательное. Когда операция над знаковым целым вызывает арифметическое переполнение или underflow, результирующее значение "оборачивается вокруг границы знака" и обычно вызывает изменение знака. Например, в 32-битном целом значение 0x7FFFFFFF -- большое положительное число. Добавление 1 к нему дает результат 0x80000000, то есть большое отрицательное число. Посмотрите на другой простой пример:

Результат сложения равен -0x7fffff10, или -2 147 483 408. Теперь посмотрите на расчет в двоичном виде:

Результат, который вы получаете в a, -- битовый шаблон для 0x800000f0, что является правильным результатом сложения, но поскольку он интерпретируется как число twos complement, значение фактически интерпретируется как -0x7fffff10. В этом случае большое положительное число плюс маленькое положительное число дало большое отрицательное число.

При знаковом сложении можно переполнить границу знака, заставив положительное число обернуться вокруг 0x80000000 и стать отрицательным. Также можно вызвать underflow границы знака, заставив отрицательное число обернуться ниже 0x80000000 и стать положительным. Вычитание идентично сложению с отрицательным числом, поэтому их можно анализировать как по сути одну и ту же операцию. Переполнения при умножении и сдвиге также возможны, и классифицировать их результаты не так легко. По сути биты ложатся как придется: если бит оказывается в знаковом бите результата, результат отрицателен. Иначе нет. Арифметические переполнения с умножением на первый взгляд кажутся немного хитрыми, но атакующие обычно могут заставить их возвращать полезные целевые значения.

Примечание

На протяжении этой главы функция read() используется для демонстрации разных форм дефектов, связанных с целыми числами. Это некоторое упрощение ради ясности, поскольку многие современные системы проверяют аргумент длины для read() на уровне системного вызова. Эти системы, включая BSD и более новое ядро Linux 2.6, проверяют, что этот аргумент меньше или равен максимальному значению соответствующего знакового целого того же размера, тем самым минимизируя риск повреждения памяти.

Некоторые неожиданные изменения знака в арифметике могут приводить к тонко эксплуатируемым условиям в коде. Эти изменения могут заставлять программы неправильно рассчитывать требования к пространству, приводя к условиям, похожим на те, которые возникают при пересечении максимальной границы беззнаковых целых. Ошибки такого рода обычно встречаются в приложениях, выполняющих арифметику над целыми, полученными напрямую из внешних источников, например сетевых данных или файлов. Листинг 6-5 -- простой пример, показывающий, как пересечение границы знака может отрицательно повлиять на приложение.

Листинг 6-5. Пример уязвимости знакового целого

Этот пример читает целое из сети и выполняет над ним несколько sanity checks. Сначала длина проверяется, чтобы убедиться, что она больше или равна нулю и, следовательно, положительна. Затем длина проверяется, чтобы убедиться, что она меньше MAXCHARS. Однако во второй части проверки длины к длине добавляется 1. Это открывает вектор атаки: значение 0x7FFFFFFF проходит первую проверку (потому что оно больше 0) и проходит вторую проверку длины (поскольку 0x7FFFFFFF + 1 равно 0x80000000, то есть отрицательному значению). Затем read() будет вызвана с фактически неограниченным аргументом длины, что приведет к потенциальной ситуации переполнения буфера.

Такую ошибку легко допустить при работе со знаковыми целыми, и ее может быть столь же трудно заметить. Протоколы, позволяющие пользователям напрямую задавать целые числа, особенно склонны к этому типу уязвимости. Чтобы исследовать это на практике, посмотрите на реальное приложение, выполняющее небезопасный расчет. Следующая уязвимость была в кодовой базе OpenSSL 0.9.6, связанной с обработкой данных, закодированных Abstract Syntax Notation (ASN.1). (ASN.1 -- язык, используемый для описания произвольных сообщений, передаваемых между компьютерами, которые кодируются с использованием BER, его базовых правил кодирования.) Это кодирование -- идеальный кандидат для уязвимости такого рода, потому что протокол явно работает с 32-битными целыми, предоставленными недоверенными клиентами. Листинг 6-6 взят из crypto/asn1/a_d2i_fp.c -- функции ASN1_d2i_fp(), отвечающей за чтение ASN.1 объектов из buffered IO (BIO) streams. Этот код отредактирован для краткости.

Листинг 6-6. Пример уязвимости границы знака целого в OpenSSL 0.9.6l

Этот код вызывается в цикле для получения ASN.1 объектов. Функция ASN1_get_object() читает заголовок объекта, который задает длину следующего ASN.1 объекта. Эта длина помещается в знаковое целое c.slen, которое затем присваивается want. Функция ASN.1 объекта гарантирует, что это число не отрицательное, поэтому максимальное значение, которое можно поместить в c.slen, равно 0x7FFFFFFF. В этот момент len -- объем данных, уже считанных в память, а off -- смещение в этих данных до разбираемого объекта. Поэтому (len-off) -- это объем данных, считанных в память, но еще не обработанных парсером. Если код видит, что объект больше доступных неразобранных данных, он решает выделить больше места и считать остаток объекта.

Функция BUF_MEM_grow() вызывается для выделения необходимого пространства в буфере памяти b; ее второй аргумент -- параметр размера. Проблема в том, что выражение len+want, используемое для второго аргумента, может переполниться. Допустим, при входе в этот код len равен 200 байтам, а off равен 50. Атакующий задает размер объекта 0x7FFFFFFF, который оказывается в want. 0x7FFFFFFF, безусловно, больше 150 байтов оставшихся данных в памяти, поэтому код выделения будет выполнен. Из want будет вычтено 150, чтобы отразить объем уже считанных данных, что даст значение 0x7FFFFF69. Вызов BUF_MEM_grow() запросит len+want байтов, или 0x7FFFFF69 + 200. Это 0x80000031, что интерпретируется как большое отрицательное число.

Внутренне функция BUF_MEM_grow() выполняет сравнение, чтобы проверить аргумент длины относительно того, сколько места она ранее выделила. Поскольку отрицательное число меньше объема памяти, который уже выделен, она считает, что все нормально. Поэтому повторное выделение обходится, и произвольный объем данных может быть скопирован в выделенные данные кучи, с серьезными последствиями.

Преобразования типов

C чрезвычайно гибок в обработке взаимодействия разных типов данных. Например, с несколькими приведениями можно легко умножить беззнаковый символ на знаковое long integer, добавить результат к символьному указателю, а затем передать результат функции, ожидающей указатель на структуру. Программисты привыкли к этой гибкости, поэтому склонны смешивать типы данных, не слишком беспокоясь о том, что происходит за кулисами.

Чтобы работать с этой гибкостью, когда компилятору нужно преобразовать объект одного типа в другой тип, он выполняет то, что известно как преобразование типа. Есть две формы преобразований типов: явные преобразования типов, где программист явно инструктирует компилятор преобразовать один тип в другой с помощью cast, и неявные преобразования типов, где компилятор выполняет "скрытые" преобразования переменных, чтобы программа работала ожидаемым образом.

Примечание

В литературе по языкам программирования вы можете встретить преобразования типов под названием "type coercions"; эти термины являются синонимами.

Часто удивляет, когда впервые узнаешь, сколько неявных преобразований происходит за кулисами в типичной программе C. Эти автоматические преобразования типов, вместе известные как стандартные преобразования типов, происходят почти магически, когда программист выполняет, казалось бы, прямолинейные задачи, такие как вызов функции или сравнение двух чисел.

Уязвимости, возникающие из преобразований типов, часто завораживают, потому что они могут быть тонкими и трудными для обнаружения в исходном коде и часто приводят к ситуациям, где патч для критической удаленной уязвимости так прост, как изменение char на unsigned char. Правила, управляющие этими преобразованиями, обманчиво тонки, и легко поверить, что вы хорошо их понимаете, но все же пропустить важный нюанс, который кардинально меняет дело при анализе или написании кода.

Вместо того чтобы сразу переходить к известным классам уязвимостей, сначала вы посмотрите, как компиляторы C выполняют преобразования типов на низком уровне, а затем подробно изучите правила C, чтобы узнать обо всех ситуациях, где происходят преобразования. Этот раздел довольно длинный, потому что нужно охватить много материала, прежде чем появится основа для уверенного анализа преобразований типов C. Однако этот аспект языка достаточно тонок, чтобы определенно стоило потратить время на прочное понимание базовых правил; это понимание можно использовать для поиска уязвимостей, о которых большинство программистов не знает даже на концептуальном уровне.

Обзор

Столкнувшись с общей проблемой согласования двух разных типов, C делает многое, чтобы не удивлять программистов. Компиляторы следуют набору правил, пытающихся инкапсулировать "здравый смысл" о том, как управлять смешением разных типов, и чаще всего результатом является программа, которая имеет смысл и просто делает то, что намеревался программист. Тем не менее применение этих правил часто может приводить к удивительному, неожиданному поведению. Более того, как и можно ожидать, такое неожиданное поведение обычно имеет тяжелые последствия для безопасности.

В следующем разделе вы начнете с изучения правил преобразования, общих правил, которые C использует при преобразовании между типами. Они диктуют, как машина преобразует один тип в другой на битовом уровне. После того как у вас появится хорошее понимание того, как C преобразует разные типы на машинном уровне, вы рассмотрите, как компилятор выбирает, какие преобразования типов применять в контексте выражений C; это включает три важные концепции: простые преобразования, целочисленные повышения и обычные арифметические преобразования.

Примечание

Хотя нецелочисленные типы, такие как floats и pointers, частично рассматриваются, основной фокус этого обсуждения -- то, как C манипулирует целыми числами, потому что эти преобразования широко неправильно понимаются и критичны для анализа безопасности.

Правила преобразования

Следующие правила описывают, как C преобразует один тип в другой, но не описывают, когда выполняются преобразования или почему они выполняются.

Примечание

Следующий материал специфичен для реализаций twos complement и представляет сжатую и прагматичную версию правил из спецификации C.

Целочисленные типы: сохранение значения

Важная концепция в преобразованиях целочисленных типов -- понятие преобразования с сохранением значения. По сути, если новый тип может представлять все возможные значения старого типа, преобразование считается сохраняющим значение. В этой ситуации значение никак не может быть потеряно или изменено в результате преобразования. Например, если unsigned char преобразуется в int, преобразование сохраняет значение, потому что int может представлять все значения unsigned char. Это можно проверить, снова обратившись к таблице 6-2. Предполагая, что вы рассматриваете машину twos complement, вы знаете, что 8-битный unsigned char может представлять любое значение от 0 до 255. Вы знаете, что 32-битный int может представлять любое значение от -2147483648 до 2147483647. Следовательно, нет такого значения unsigned char, которое int не мог бы представить.

Соответственно, при преобразовании с изменением значения старый тип может содержать значения, которые нельзя представить в новом типе. Например, если вы преобразуете int в unsigned int, вы потенциально создали трудноразрешимую ситуацию. unsigned int на 32-битной машине имеет диапазон от 0 до 4294967295, а int имеет диапазон от -2147483648 до 2147483647. unsigned int не может хранить ни одно отрицательное значение, которое может представлять signed int.

Согласно стандарту C, некоторые преобразования с изменением значения имеют результаты, определяемые реализацией. Это верно только для преобразований с изменением значения, у которых тип назначения знаковый; преобразования с изменением значения в беззнаковый тип определены и согласованы во всех реализациях. (Если вы помните обсуждение граничных условий, причина в том, что беззнаковая арифметика определена как модульная арифметическая система.) Машины twos complement следуют тем же базовым вариантам поведения, поэтому можно с достаточной уверенностью объяснить, как они выполняют преобразования с изменением значения в знаковые типы назначения.

Целочисленные типы: расширение

Когда вы преобразуете узкий тип в более широкий тип, машина обычно копирует битовый шаблон из старой переменной в новую переменную, а затем устанавливает все оставшиеся старшие биты новой переменной в 0 или 1. Если исходный тип беззнаковый, машина использует zero extension, при котором значение 0 распространяется во все старшие биты нового более широкого типа. Если исходный тип знаковый, машина использует sign extension, при котором бит знака исходного типа распространяется во все неиспользуемые биты типа назначения.

Предупреждение

Процедура расширения может иметь некоторые неожиданные последствия: если узкий знаковый тип, например signed char, преобразуется в более широкий беззнаковый тип, например unsigned int, происходит sign extension.

Рисунок 6-1 показывает преобразование с сохранением значения unsigned char со значением 5 в signed int.

Рисунок 6-1. Преобразование unsigned char в int (zero extension, big endian)

Символ помещается в целое, и значение сохраняется. На уровне битового шаблона это просто включало zero extension: очистку старших битов и перемещение least significant byte (LSB) в LSB нового объекта.

Теперь рассмотрите signed char, преобразуемый в int. int может представлять все значения signed char, поэтому это преобразование также сохраняет значение. Рисунок 6-2 показывает, как это преобразование выглядит на битовом уровне.

Рисунок 6-2. Преобразование signed char в integer (sign extension, big endian)

Эта ситуация немного отличается: значение то же самое, но преобразование сложнее. Битовое представление -5 в signed char -- 1111 1011. Битовое представление -5 в int -- 1111 1111 1111 1111 1111 1111 1111 1011. Чтобы выполнить преобразование, компилятор генерирует ассемблер, выполняющий sign extension. На рисунке 6-2 видно, что бит знака установлен в signed char, поэтому для сохранения значения -5 бит знака должен быть скопирован в остальные 24 бита int.

Предыдущие примеры -- преобразования с сохранением значения. Теперь рассмотрим расширяющее преобразование с изменением значения. Допустим, вы преобразуете signed char со значением -5 в unsigned int. Поскольку исходный тип знаковый, вы выполняете sign extension над signed char перед помещением его в unsigned int (см. рисунок 6-3).

Рисунок 6-3. Преобразование signed char в unsigned integer (sign extension, big endian)

Как упоминалось ранее, этот результат может удивлять разработчиков. Его последствия для безопасности рассматриваются далее в этой главе, в разделе "Расширение знака". Это преобразование меняет значение, потому что unsigned int не может представлять значения меньше 0.

Целочисленные типы: сужение

При преобразовании из более широкого типа в более узкий машина использует только один механизм: усечение. Биты более широкого типа, которые не помещаются в новый более узкий тип, отбрасываются. Рисунки 6-4 и 6-5 показывают два сужающих преобразования. Обратите внимание, что все сужающие преобразования меняют значение, потому что вы теряете точность.

Рисунок 6-4. Преобразование integer в unsigned short integer (truncation, big endian)

Рисунок 6-5. Преобразование integer в signed char (truncation, big endian)

Целочисленные типы: знаковые и беззнаковые

Один финальный тип целочисленного преобразования для рассмотрения: если преобразование происходит между знаковым и беззнаковым типами одной ширины, в битовом шаблоне ничего не меняется. Это преобразование меняет значение. Например, допустим, у вас есть знаковое целое -1, которое в двоичном виде представлено как 1111 1111 1111 1111 1111 1111 1111 1111.

Если интерпретировать тот же битовый шаблон как беззнаковое целое, вы увидите значение 4 294 967 295. Преобразование резюмировано на рисунке 6-6. Преобразование из unsigned int в int технически может быть определяемым реализацией, но работает тем же образом: битовый шаблон оставляется как есть, а значение интерпретируется в контексте нового типа (см. рисунок 6-7).

Рисунок 6-6. Преобразование int в unsigned int (big endian)

Рисунок 6-7. Преобразование unsigned int в signed int (big endian)

Резюме преобразований целочисленных типов

Вот несколько практических эмпирических правил для преобразований целочисленных типов:

• Когда вы преобразуете более узкий знаковый тип в более широкий беззнаковый тип, компилятор генерирует ассемблер для sign extension, и значение объекта может измениться.

• Когда вы преобразуете более узкий знаковый тип в более широкий знаковый тип, компилятор генерирует ассемблер для sign extension, и значение объекта сохраняется.

• Когда вы преобразуете более узкий беззнаковый тип в более широкий тип, компилятор генерирует ассемблер для zero extension, и значение объекта сохраняется.

• Когда вы преобразуете более широкий тип в более узкий тип, компилятор генерирует ассемблер для усечения, и значение объекта может измениться.

• Когда вы преобразуете между знаковым и беззнаковым типами одной ширины, компилятор фактически ничего не делает, битовый шаблон остается тем же, и значение объекта может измениться.

Таблица 6-4 резюмирует обработку, происходящую при преобразовании разных целочисленных типов в реализациях C на twos complement. Пока вы проходите материал следующих разделов, эта таблица может служить полезной справкой для вспоминания того, как происходит преобразование.

Таблица 6-4. Преобразование целочисленных типов в C (источник слева, назначение сверху)

Типы с плавающей точкой и комплексные типы

Хотя уязвимости, вызванные использованием арифметики с плавающей точкой, не получили широких публикаций, они, безусловно, возможны. В финансовом ПО вполне возможно появление тонких ошибок, связанных с преобразованиями типов с плавающей точкой или проблемами представления. Обсуждение типов с плавающей точкой в этой главе довольно краткое. Для дополнительной информации обратитесь к документам стандартов C и ранее упомянутым справочникам по программированию на C.

Правила стандарта C для преобразований между вещественными типами с плавающей точкой и целочисленными типами оставляют много места для поведения, определяемого реализацией. При преобразовании вещественного типа в целочисленный дробная часть числа отбрасывается. Если целочисленный тип не может представить целую часть числа с плавающей точкой, результат не определен. Аналогично, преобразование из целочисленного типа в вещественный тип переносит значение, если это возможно. Если вещественный тип не может представить значение целого, но может приблизиться, компилятор округляет целое до следующего большего или меньшего числа способом, определяемым реализацией. Если целое вне диапазона вещественного типа, результат не определен.

Преобразования между типами с плавающей точкой разной точности обрабатываются похожей логикой. Повышение не вызывает изменения значения. При понижении, вызывающем изменение значения, компилятор свободен округлять числа, если это возможно, способом, определяемым реализацией. Если округление невозможно из-за диапазона целевого типа, результат не определен.

Другие типы

В C есть мириады других типов помимо целых и floats, включая указатели, Booleans, структуры, unions, функции, массивы, enums и многое другое. По большей части преобразования между этими типами не настолько критичны с точки зрения безопасности, поэтому они не рассматриваются в этой главе подробно.

Арифметика указателей рассматривается далее в этой главе, в разделе "Арифметика указателей". Преобразование типов указателей в значительной степени зависит от нижележащей машинной архитектуры, и многие преобразования указаны как определяемые реализацией. По сути программисты свободны преобразовывать указатели в целые и обратно, а также преобразовывать указатели одного типа в другой. Результаты определяются реализацией, и программисты должны помнить об ограничениях выравнивания и других низкоуровневых деталях.

Простые преобразования

Теперь, когда у вас есть хорошее представление о том, как C преобразует один целочисленный тип в другой, можно рассмотреть некоторые ситуации, где эти преобразования типов происходят. Простые преобразования -- это выражения C, использующие прямолинейное применение правил преобразования.

Приведения

Как вы знаете, typecasts -- механизм C, позволяющий программистам задавать явное преобразование типа, как показано в этом примере:

Каким бы ни был тип bob, это выражение преобразует его в тип unsigned char. Результирующий тип выражения -- unsigned char.

Присваивания

Простое преобразование типов также происходит в операторе присваивания. Компилятор должен преобразовать тип правого операнда в тип левого операнда, как показано в этом примере:

Для обоих присваиваний компилятор должен взять объект в правом операнде и преобразовать его в тип левого операнда. Правила преобразования говорят, что преобразование из int bob в short int fred приводит к усечению.

Вызовы функций: прототипы

В C есть два стиля объявлений функций: старый стиль K&R, где типы параметров не указываются в объявлении функции, и новый стиль ANSI, где типы параметров являются частью объявления. В стиле ANSI использование прототипов функций все еще необязательно, но распространено. В стиле ANSI обычно можно увидеть что-то вроде этого:

Объявление функции dostuff() содержит прототип, сообщающий компилятору число аргументов и их типы. Эмпирическое правило таково: если у функции есть прототип, типы преобразуются прямолинейно с использованием правил, документированных ранее. Если у функции нет прототипа, включается нечто под названием стандартные повышения аргументов (объясняется в разделе "Целочисленные повышения").

В предыдущем примере символ (a) преобразуется в int (jim), unsigned short (b) преобразуется в unsigned char (bob), а int (возвращаемое значение функции dostuff()) преобразуется в long long int (c).

Вызовы функций: return

return выполняет преобразование своего операнда в тип, указанный в определении окружающей функции. Например, int a преобразуется в тип данных char оператором return:

Целочисленные повышения

Целочисленные повышения определяют, как C берет узкий целочисленный тип данных, например char или short, и преобразует его в int (или, в редких случаях, в unsigned int). Это up-conversion, или повышение, используется для двух разных целей:

• Некоторые операторы C требуют целочисленный операнд типа int или unsigned int. Для этих операторов C использует правила целочисленного повышения, чтобы преобразовать более узкий целочисленный операнд в правильный тип -- int или unsigned int.

• Целочисленные повышения являются критическим компонентом правил C для обработки арифметических выражений, которые называются обычными арифметическими преобразованиями. Для арифметических выражений с целыми числами целочисленные повышения обычно применяются к обоим операндам.

Примечание

В другой литературе вы можете встретить термины "integer promotions" и "integral promotions" как взаимозаменяемые, поскольку они являются синонимами.

Есть полезная концепция из стандартов C: каждому целочисленному типу данных назначается так называемый integer conversion rank. Эти ранги упорядочивают целочисленные типы данных по ширине от меньшей к большей. Знаковым и беззнаковым разновидностям каждого типа назначается один и тот же ранг. Следующий сокращенный список сортирует целочисленные типы по рангу преобразования от высокого к низкому. Стандарт C назначает ранги и другим целочисленным типам, но этого списка должно хватить для обсуждения:

По сути в любом месте C, где можно использовать int или unsigned int, можно также использовать любой целочисленный тип с более низким integer conversion rank. Это означает, что в выражениях C можно использовать меньшие типы, такие как char и short int, вместо int. Также можно использовать битовое поле типа _Bool, int, signed int или unsigned int. Битовым полям не приписываются integer conversion ranks, но они считаются более узкими, чем соответствующий базовый тип. Это имеет смысл, потому что битовое поле int обычно меньше int, а в самом широком случае имеет такую же ширину, как int.

Если применить целочисленные повышения к переменной, что происходит? Во-первых, если переменная не является целочисленным типом или битовым полем, повышения ничего не делают. Во-вторых, если переменная является целочисленным типом, но ее integer conversion rank больше или равен рангу int, повышения ничего не делают. Следовательно, ints, unsigned ints, long ints, pointers и floats не изменяются целочисленными повышениями.

Итак, целочисленные повышения отвечают за взятие более узкого целочисленного типа или битового поля и повышение его до int или unsigned int. Это делается прямолинейно: если можно выполнить преобразование в int с сохранением значения, оно выполняется. Иначе выполняется преобразование в unsigned int с сохранением значения.

На практике это означает, что почти все преобразуется в int, поскольку int может хранить минимальные и максимальные значения всех меньших типов. Единственные типы, которые могут повышаться до unsigned int, -- это битовые поля unsigned int с 32 битами или, возможно, некоторые специфичные для реализации расширенные целочисленные типы.

Историческое примечание

Стандарт C89 внес важное изменение в правила преобразования типов C. Во времена K&R языка C целочисленные повышения были unsigned-preserving, а не value-preserving. Поэтому при текущих правилах C, если более узкий беззнаковый целочисленный тип, например unsigned char, повышается до более широкого знакового целого, например int, преобразование значения диктует, что новый тип является знаковым целым. При старых правилах повышение сохраняло бы беззнаковость, поэтому результирующим типом был бы unsigned int. Это изменило поведение многих signed/unsigned сравнений, включавших повышения типов, более узких, чем int.

Резюме целочисленных повышений

Базовое эмпирическое правило таково: если целочисленный тип уже, чем int, целочисленные повышения почти всегда преобразуют его в int. Таблица 6-5 резюмирует результат целочисленных повышений для нескольких распространенных типов.

Таблица 6-5. Результаты целочисленных повышений

Применения целочисленных повышений

Теперь, когда вы понимаете целочисленные повышения, следующие разделы рассматривают, где они используются в языке C.

Унарный оператор +

Унарный оператор + выполняет целочисленные повышения над своим операндом. Например, если переменная bob имеет тип char, результирующий тип выражения (+bob) -- int, тогда как результирующий тип выражения (bob) -- char.

Унарный оператор -

Унарный оператор - выполняет целочисленное повышение над своим операндом, а затем выполняет отрицание. Независимо от того, является ли операнд знаковым после повышения, выполняется отрицание twos complement, включающее инверсию битов и добавление 1.

Парадокс Леблана

David Leblanc -- опытный исследователь и автор, один из ведущих мировых экспертов по проблемам целых чисел в C и C++. Он задокументировал интересный нюанс арифметики twos complement, который обнаружил при работе над классом SafeInt со своим коллегой Atin Bansal (http://msdn.microsoft.com/library/en-us/dncode/html/secure01142004.asp). Чтобы отрицать число twos complement, вы инвертируете все биты и добавляете 1 к результату. Если предположить 32-битный знаковый тип данных, что является обратным для 0x80000000?

Если инвертировать все биты, вы получите 0x7fffffff. Если добавить 1, вы получите 0x80000000. Поэтому унарное отрицание этого граничного числа равно самому себе!

Эта особенность может вступать в игру, когда разработчики используют отрицательные целые для представления специального sentinel-набора чисел или пытаются взять абсолютное значение целого. В следующем коде намерение состоит в том, чтобы отрицательный индекс задавал вторичную хеш-таблицу. Это работает нормально, если только атакующие не могут задать index равным 0x80000000. Отрицание числа не меняет значение, а 0x80000000 % 1000 равно -648, что приводит к изменению памяти перед массивом.

Унарный оператор ~

Унарный оператор ~ выполняет ones complement своего операнда после целочисленного повышения операнда. В реализациях twos complement это фактически выполняет одну и ту же операцию над знаковыми и беззнаковыми операндами: инвертирует биты.

Побитовые операторы сдвига

Побитовые операторы сдвига >> и << сдвигают битовые шаблоны переменных. Целочисленные повышения применяются к обоим аргументам этих операторов, а тип результата совпадает с повышенным типом левого операнда, как показано в этом примере:

a преобразуется в integer, и c преобразуется в integer. Повышенный тип левого операнда -- int, поэтому тип результата -- int. Целочисленное представление a сдвигается влево 16 раз.

Операторы switch

Целочисленные повышения используются в операторах switch. Общая форма оператора switch выглядит примерно так:

Целочисленные повышения используются следующим образом: сначала они применяются к управляющему выражению, так что это выражение получает повышенный тип. Затем все целочисленные константы преобразуются в тип повышенного управляющего выражения.

Вызовы функций

Старые программы C, использующие семантику K&R, не указывают типы данных аргументов в объявлениях функций. Когда функция вызывается без прототипа, компилятору приходится выполнять так называемые стандартные повышения аргументов. По сути целочисленные повышения применяются к каждому аргументу функции, а любые аргументы типа float преобразуются в аргументы типа double. Рассмотрите следующий пример:

В этом примере копия значения a передается функции jim(). Тип char сначала проходит через целочисленные повышения и преобразуется в integer. Именно этот integer передается функции jim(). Код, который компилятор генерирует для функции jim(), ожидает integer argument и выполняет прямое преобразование этого integer обратно в формат char для переменной bob.

Обычные арифметические преобразования

Во многих ситуациях от C ожидается, что он возьмет два операнда потенциально разных типов и выполнит некоторую арифметическую операцию, включающую оба. Стандарты C описывают общий алгоритм согласования двух типов в совместимый тип для этой цели. Эта процедура известна как обычные арифметические преобразования. Цель этих преобразований -- преобразовать оба операнда в общий вещественный тип, который используется для фактической операции, а затем как тип результата. Эти преобразования применяются только к арифметическим типам -- целочисленным типам и типам с плавающей точкой. Следующие разделы рассматривают правила преобразования.

Правило 1: числа с плавающей точкой имеют приоритет

Типы с плавающей точкой имеют приоритет над целочисленными типами, поэтому если один из аргументов в арифметическом выражении является типом с плавающей точкой, другой аргумент преобразуется в тип с плавающей точкой. Если один аргумент с плавающей точкой менее точен, чем другой, менее точный аргумент повышается до типа более точного аргумента.

Правило 2: применить целочисленные повышения

Если у вас есть два операнда и ни один не является float, вы входите в правила согласования целых чисел. Сначала целочисленные повышения выполняются над обоими операндами. Это чрезвычайно важная часть головоломки! Если вы помните из предыдущего раздела, это означает, что любой целочисленный тип меньше int преобразуется в int, а все, что имеет ту же ширину, что int, больше int или не является целочисленным типом, остается без изменений. Вот краткий пример:

В этом выражении оператор + заставляет применить обычные арифметические преобразования к своим операндам. Это означает, что и jim, и bob повышаются до ints, выполняется сложение, и результирующий тип выражения -- int, содержащий результат сложения (510). Поэтому do_something() вызывается, хотя кажется, что сложение могло вызвать числовое переполнение. Резюме: всякий раз, когда есть арифметика с типами уже, чем integer, узкие типы за кулисами повышаются до integers. Вот еще один краткий пример:

Интуиция подсказывает, что если у вас есть unsigned short со значением 1 и из него вычитается 5, он underflows вокруг 0 и в итоге содержит большое значение. Однако если протестировать этот фрагмент, вы увидите, что do_something() вызывается, потому что оба операнда оператора вычитания преобразуются в ints перед сравнением. Поэтому a преобразуется из unsigned short в int, а затем из него вычитается int со значением 5. Результирующее значение равно -4, что является допустимым integer value, поэтому сравнение истинно. Обратите внимание: если бы вы сделали следующее, do_something() не был бы вызван:

Целочисленное повышение все равно происходит с (a-5), но результирующее integer value -4 помещается обратно в unsigned short a. Как вы знаете, это вызывает простое преобразование из signed int в unsigned short, что приводит к усечению, и a получает большое положительное значение. Поэтому сравнение не проходит.

Правило 3: тот же тип после целочисленных повышений

Если два операнда имеют один и тот же тип после применения целочисленных повышений, дальнейшие преобразования не нужны, потому что арифметика должна быть прямолинейно выполнима на машинном уровне. Это может произойти, если оба операнда были повышены до int целочисленными повышениями или если они просто оказались одного типа и не были затронуты целочисленными повышениями.

Правило 4: тот же знак, разные типы

Если два операнда имеют разные типы после применения целочисленных повышений, но имеют одинаковую знаковость, более узкий тип преобразуется в тип более широкого типа. Иными словами, если оба операнда знаковые или оба операнда беззнаковые, тип с меньшим integer conversion rank преобразуется в тип операнда с более высоким conversion rank.

Обратите внимание, что это правило не имеет отношения к short integers или characters, потому что они уже были преобразованы в integers целочисленными повышениями. Это правило больше применимо к арифметике с типами больших размеров, такими как long long int или long int. Вот краткий пример:

Целочисленные повышения не меняют никаких типов, потому что они имеют ширину, равную или большую, чем тип int. Поэтому это правило требует, чтобы int jim был преобразован в long int до выполнения сложения. Результирующий тип, long int, преобразуется в long long int присваиванием в fred.

В следующем разделе вы рассмотрите операнды разных типов, где один знаковый, а другой беззнаковый; это становится интересным с точки зрения безопасности.

Правило 5: беззнаковый тип шире или той же ширины, что знаковый тип

Первое правило для этой ситуации: если беззнаковый операнд имеет больший integer conversion rank, чем знаковый операнд, или их ранги равны, вы преобразуете знаковый операнд в тип беззнакового операнда. Такое поведение может удивлять, поскольку приводит к ситуациям вроде этой:

Оператор сравнения < заставляет применить обычные арифметические преобразования к обоим операндам. Целочисленные повышения применяются к jim и к sizeof(int), но не затрагивают их. Затем вы продолжаете обычные арифметические преобразования и пытаетесь выяснить, какой тип должен быть общим типом для сравнения. В этом случае jim -- знаковое целое, а sizeof (int) -- size_t, то есть беззнаковый целочисленный тип. Поскольку size_t имеет больший integer conversion rank, беззнаковый тип получает приоритет по этому правилу. Поэтому jim преобразуется в беззнаковый целочисленный тип, сравнение завершается неуспешно, и do_something() не вызывается. На 32-битной системе фактическое сравнение таково:

Правило 6: знаковый тип шире беззнакового типа, сохранение значения возможно

Если знаковый операнд имеет больший integer conversion rank, чем беззнаковый операнд, и можно выполнить преобразование беззнакового целочисленного типа в знаковый целочисленный тип с сохранением значения, вы выбираете преобразование всего к знаковому целочисленному типу, как в этом примере:

Знаковый аргумент, long long int, может представлять все значения беззнакового аргумента, unsigned int, поэтому компилятор преобразует оба операнда к типу знакового операнда: long long int.

Правило 7: знаковый тип шире беззнакового типа, сохранение значения невозможно

Есть еще одно правило: если знаковый целочисленный тип имеет больший integer conversion rank, чем беззнаковый целочисленный тип, но все значения беззнакового целочисленного типа не могут поместиться в знаковый целочисленный тип, нужно сделать нечто немного странное. Вы берете тип знакового целочисленного типа, преобразуете его в соответствующий беззнаковый целочисленный тип, а затем преобразуете оба операнда к этому типу. Вот пример:

Для целей этого примера предположим, что на этой машине размер long int имеет ту же ширину, что размер int. Оператор сложения вызывает применение обычных арифметических преобразований. Целочисленные повышения применяются, но не меняют типы. Знаковый тип (long int) имеет более высокий ранг, чем беззнаковый тип (unsigned int). Знаковый тип (long int) не может хранить все значения беззнакового типа (unsigned int), поэтому остается последнее правило. Вы берете тип знакового операнда, то есть long int, преобразуете его в соответствующий беззнаковый эквивалент, unsigned long int, а затем преобразуете оба операнда к unsigned long int. Следовательно, выражение сложения имеет результирующий тип unsigned long int и значение 30.

Резюме арифметических преобразований

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

• Если любой операнд является числом с плавающей точкой, преобразуйте все операнды к типу с плавающей точкой операнда наибольшей точности. Готово.

• Выполните целочисленные повышения над обоими операндами. Если два операнда теперь имеют один и тот же тип, готово.

• Если два операнда имеют одинаковую знаковость, преобразуйте операнд с меньшим integer conversion rank к типу операнда с большим integer conversion rank. Готово.

• Если беззнаковый операнд имеет больший или равный integer conversion rank, чем знаковый операнд, преобразуйте знаковый операнд к типу беззнакового операнда. Готово.

• Если знаковый операнд имеет больший integer conversion rank, чем беззнаковый операнд, и можно выполнить преобразование с сохранением значения, преобразуйте беззнаковый операнд к типу знакового операнда. Готово.

• Если знаковый операнд имеет больший integer conversion rank, чем беззнаковый операнд, но преобразование с сохранением значения выполнить нельзя, преобразуйте оба операнда к беззнаковому типу, соответствующему типу знакового операнда.

Таблица 6-6. Примеры обычных арифметических преобразований

Применения обычных арифметических преобразований

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

Сложение

Сложение может происходить между двумя арифметическими типами, а также между типом указателя и арифметическим типом. Арифметика указателей объясняется в разделе "Арифметика указателей", но пока нужно лишь отметить, что когда оба аргумента являются арифметическими типами, компилятор применяет к ним обычные арифметические преобразования.

Вычитание

Есть три типа вычитания: вычитание между двумя арифметическими типами, вычитание между указателем и арифметическим типом и вычитание между двумя типами указателей. При вычитании между двумя арифметическими типами C применяет обычные арифметические преобразования к обоим операндам.

Мультипликативные операторы

Операнды для * и / должны быть арифметическим типом, а аргументы для % должны быть целочисленным типом. Обычные арифметические преобразования применяются к обоим операндам этих операторов.

Операторы отношения и равенства

Когда сравниваются два арифметических операнда, обычные арифметические преобразования применяются к обоим операндам. Результирующий тип -- int, а его значение равно 1 или 0, в зависимости от результата проверки.

Бинарные побитовые операторы

Бинарные побитовые операторы &, ^ и | требуют целочисленных операндов. Обычные арифметические преобразования применяются к обоим операндам.

Оператор вопросительного знака

С точки зрения преобразования типов условный оператор -- один из наиболее интересных операторов C. Вот короткий пример того, как он обычно используется:

В этом примере первый операнд, choice, вычисляется как scalar. Если он установлен, результат выражения -- вычисление второго операнда, то есть a. Если он не установлен, результат -- вычисление третьего операнда, b.

Компилятор должен знать во время компиляции результирующий тип условного выражения, что в этой ситуации может быть непросто. C определяет, какой тип был бы результатом применения обычных арифметических преобразований ко второму и третьему аргументам, и делает этот тип результирующим типом выражения. Поэтому в предыдущем примере выражение дает unsigned int независимо от значения choice.

Резюме преобразований типов

Таблица 6-7 показывает детали некоторых распространенных преобразований типов.

Таблица 6-7. Резюме стандартных повышений типов

Совет аудитору: преобразования типов

Даже те, кто подробно изучал преобразования, все еще могут удивляться тому, как компилятор превращает некоторые выражения в ассемблер. Когда вы видите код, который кажется подозрительным или потенциально неоднозначным, не колеблясь напишите простую тестовую программу или изучите сгенерированный ассемблер, чтобы проверить свою интуицию.

Если вы генерируете ассемблер для проверки или исследования преобразований, обсуждаемых в этой главе, учитывайте, что компиляторы C могут оптимизировать некоторые преобразования или использовать архитектурные приемы, из-за которых ассемблер выглядит неправильным или несогласованным. На концептуальном уровне компиляторы ведут себя так, как описывает стандарт C, и в итоге генерируют код, следующий правилам. Однако ассемблер может выглядеть несогласованным из-за оптимизаций или даже неверным, поскольку он может манипулировать частями регистров, которые должны быть неиспользуемыми.

Уязвимости преобразования типов

Теперь, когда у вас есть прочное понимание преобразований типов C, можно исследовать некоторые исключительные обстоятельства, которые они могут создавать. Неявные преобразования типов могут застать программистов врасплох в нескольких ситуациях. Этот раздел сосредоточен на простых преобразованиях между знаковыми и беззнаковыми типами, расширении знака, усечении и обычных арифметических преобразованиях, с акцентом на сравнения.

Преобразования signed/unsigned

Большинство проблем безопасности, связанных с преобразованиями типов, является результатом простых преобразований между знаковыми и беззнаковыми целыми. Это обсуждение ограничено преобразованиями, возникающими из-за присваивания, вызовов функций или typecasts.

Кратко повторяя правила простых преобразований: когда знаковая переменная преобразуется в беззнаковую переменную того же размера, битовый шаблон остается как есть, а значение меняется соответствующим образом. То же самое происходит, когда беззнаковая переменная преобразуется в знаковую. Технически преобразование unsigned-to-signed определяется реализацией, но в реализациях twos complement обычно битовый шаблон остается как есть.

Самая важная ситуация, где это преобразование становится релевантным, -- вызовы функций, как показано в этом примере:

Третий аргумент -- unsigned int, представляющий длину копируемой секции памяти. Если вы вызываете эту функцию и передаете signed int как третий аргумент, он преобразуется в unsigned integer. Например, допустим, вы делаете это:

Функция copy() видит чрезвычайно большое положительное len и, скорее всего, копирует до тех пор, пока не вызовет segmentation fault. Большинство процедур libc, принимающих параметр размера, имеют аргумент типа size_t, то есть беззнаковый целочисленный тип той же ширины, что указатель. Именно поэтому нужно быть осторожным и никогда не позволять отрицательному полю длины попасть в процедуру libc, такую как snprintf(), strncpy(), memcpy(), read() или strncat().

Такая ситуация возникает довольно часто, особенно когда знаковые целые используются для значений длины, а программист не учитывает потенциал значения меньше 0. В этом случае все значения меньше 0 меняют свое значение на большое положительное число при преобразовании в беззнаковый тип. Злонамеренные пользователи часто могут задавать отрицательные целые через разные интерфейсы программы и подрывать логику приложения. Такой тип ошибки часто происходит, когда выполняется проверка максимальной длины для целого, предоставленного пользователем, но не выполняется проверка того, отрицательное ли это целое, как в листинге 6-7.

Листинг 6-7. Пример уязвимости знакового сравнения

В листинге 6-7 предположим, что функция get_user_length() читает 32-битное целое из сети. Если длина, предоставленная пользователем, отрицательна, проверку длины можно обойти, и приложение может быть скомпрометировано. Отрицательная длина преобразуется в тип size_t для вызова read(), что, как вы знаете, превращается в большое беззнаковое значение. Проверяющий код всегда должен учитывать последствия отрицательных значений в знаковых типах и смотреть, могут ли возникнуть неожиданные результаты, ведущие к воздействиям на безопасность. В этом случае из-за ошибочной проверки длины может сработать переполнение буфера; следовательно, недосмотр довольно серьезен.

Совет аудитору: преобразования signed/unsigned

Нужно искать ситуации, где функция принимает параметр длины size_t или unsigned int, а программист передает знаковое целое, на которое могут влиять пользователи. Хорошие функции для поиска включают read(), recvfrom(), memcpy(), memset(), bcopy(), snprintf(), strncat(), strncpy() и malloc(). Если пользователи могут заставить программу передать отрицательное значение, функция интерпретирует его как большое значение, что может привести к эксплуатируемому условию.

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

При анализе функций в приложении полезно записывать типы данных каждого аргумента функции в журнал аудита функций. Так каждый раз, когда вы проверяете последующий вызов этой функции, можно просто сравнить типы и изучить таблицы преобразования типов в разделе этой главы "Преобразования типов", чтобы точно предсказать, что произойдет и каковы последствия этого преобразования. Подробнее об анализе функций и ведении журналов прототипов и поведения функций вы узнаете в главе 7, "Строительные блоки программ".

Расширение знака

Расширение знака происходит, когда меньший знаковый целочисленный тип преобразуется в более крупный тип, а машина распространяет знаковый бит меньшего типа на неиспользуемые биты большего типа. Смысл расширения знака в том, чтобы преобразование сохраняло значение при переходе от меньшего знакового типа к большему знаковому типу.

Как вы знаете, расширение знака может возникать несколькими способами. Во-первых, если выполняется простое преобразование из небольшого знакового типа в более крупный тип через typecast, присваивание или вызов функции, происходит расширение знака. Вы также знаете, что расширение знака происходит, если знаковый тип, меньший чем integer, повышается через integer promotions. Расширение знака может также возникнуть в результате обычных арифметических преобразований, применяемых после integer promotions, потому что знаковый целочисленный тип может быть повышен до более крупного типа, например long long.

Расширение знака -- естественная часть языка, и оно необходимо для повышений целых, сохраняющих значение. Так почему оно упоминается как проблема безопасности? Есть две причины:

• В некоторых случаях расширение знака является преобразованием, меняющим значение, и дает неожиданный результат.

• Программисты постоянно забывают, что используемые ими типы char и short являются знаковыми.

Чтобы рассмотреть первую причину, вспомните из раздела о преобразованиях один из более интересных выводов: расширение знака выполняется, если меньший знаковый тип преобразуется в более крупный беззнаковый тип. Допустим, программист делает что-то вроде этого:

Этот код буквально напрашивается на беду. Если результат get_len_field() таков, что len получает значение меньше 0, это отрицательное значение передается как аргумент длины в snprintf(). Допустим, программист пытается исправить ошибку и делает следующее:

Такое решение вроде бы имеет смысл. Беззнаковое целое не может быть отрицательным, верно? К сожалению, при преобразовании из char в unsigned int происходит расширение знака, поэтому попытка избавиться от символов меньше 0 срабатывает наоборот. Если len оказывается ниже 0, (unsigned int)len превращается в большое значение.

Этот пример может показаться несколько произвольным, но он похож на реальную ошибку, которую авторы недавно обнаружили в коде клиента. Вывод здесь такой: всегда помните, что при преобразовании из меньшего знакового типа в более крупный беззнаковый тип применяется расширение знака.

Теперь вторая причина: программисты постоянно забывают, что используемые ими типы char и short являются знаковыми. Это утверждение особенно справедливо для сетевого кода, который работает со знаковыми длинами, или для кода, который обрабатывает двоичные либо текстовые данные по одному символу. Рассмотрим реальную уязвимость в коде разбора DNS-пакетов инструмента antisniff от l0pht (http://packetstormsecurity.org/sniffers/antisniff/). Это отличный пример для демонстрации нескольких уже обсуждавшихся уязвимостей. Сначала в программе было обнаружено переполнение буфера из-за неправильного использования strncat(), а после исправления этой уязвимости исследователи из TESO обнаружили, что программа по-прежнему уязвима из-за проблемы расширения знака. Исправление проблемы расширения знака тоже оказалось неправильным, и была опубликована еще одна уязвимость. Следующие примеры проходят по хронологии этой уязвимости.

Листинг 6-8 содержит слегка отредактированный уязвимый код из версии 1 исследовательского релиза antisniff, из файла raw_watchdns.c, функции watch_dns_ptr().

Листинг 6-8. Уязвимость Antisniff v1.0

Прежде чем понять этот код, нужен небольшой контекст. Назначение функции watch_dns_ptr() -- извлечь доменное имя из пакета и скопировать его в строку nameStr. DNS-имена в DNS-пакетах чем-то похожи на Pascal-строки. Каждая метка в доменном имени предваряется байтом, содержащим ее длину. Доменное имя заканчивается, когда достигается метка длиной 0. Схема DNS-сжатия к этой уязвимости отношения не имеет. Рисунок 6-8 показывает, как DNS-имя выглядит в пакете. Здесь есть три метки -- test, jim и com, -- а также метка длиной 0, задающая конец имени.

Рисунок 6-8. Пример DNS-имени

Код начинается с чтения первого байта длины из пакета и сохранения его в целочисленной переменной count. Этот байт длины -- знаковый символ, сохраненный в integer, поэтому в count можно поместить любое значение от -128 до 127. Запомните это для дальнейшего анализа.

Цикл while() продолжает читать метки и вызывать strncat(), добавляя их к строке nameStr. Первая опубликованная уязвимость заключалась в отсутствии проверки длины в этом цикле. Если просто предоставить достаточно длинное доменное имя в пакете, код мог записать данные за пределы nameStr[]. Листинг 6-9 показывает, как эта проблема была исправлена в версии 1.1 исследовательской версии.

Листинг 6-9. Уязвимость Antisniff v1.1

Код в основном тот же, но были добавлены проверки длины, которые должны предотвращать переполнение буфера. В начале цикла программа проверяет, достаточно ли в буфере места для count байтов, прежде чем выполнять конкатенацию строк. Теперь рассмотрим этот код с учетом уязвимостей расширения знака. Вы знаете, что count может быть любым значением от -128 до 127, так что произойдет, если задать для count отрицательное значение? Посмотрите на проверку длины:

Вы знаете, что strlen(nameStr) вернет size_t, что на 32-битной системе фактически является unsigned int, и знаете, что count -- integer меньше 0. Допустим, цикл уже выполнился один раз, strlen(nameStr) равен 5, а count равен -1. Для сложения count преобразуется в беззнаковое целое, и получается выражение 5 + 4 294 967 295. Такое сложение легко вызывает числовое переполнение, так что итогом становится малое значение, например 4; 4 меньше (MAX_LEN - 1), то есть 256. Пока все хорошо. Затем видно, что count, который вы задали равным -1, передается как аргумент длины в strncat(). Функция strncat() принимает size_t, поэтому интерпретирует это как 4 294 967 295. Следовательно, вы снова выигрываете, потому что по сути можете добавить к строке nameStr сколько угодно данных.

Листинг 6-10 показывает, как эта уязвимость была исправлена в версии 1.1.1 исследовательского релиза.

Листинг 6-10. Уязвимость Antisniff v1.1.1

Это решение в основном представляет собой тот же код, только в проверку длины добавлены typecasts. Посмотрим ближе:

Результат strlen() приводится к unsigned int, что избыточно, потому что это уже size_t. Затем count приводится к unsigned int. Это тоже избыточно, поскольку обычно он преобразуется в беззнаковый целочисленный тип оператором сложения. По сути, ничего не изменилось. Все еще можно отправить отрицательную длину метки и обойти проверку длины. Листинг 6-11 показывает, как эта проблема была исправлена в версии 1.1.2.

Листинг 6-11. Уязвимость Antisniff v1.1.2

Разработчики изменили count, nameStr и indx, сделав их беззнаковыми, и вернулись к проверке длины из предыдущей версии. Значит, расширение знака, которым вы пользовались, теперь вроде бы исчезло, потому что указатель на символы indx теперь имеет беззнаковый тип. Однако присмотритесь к этой строке:

Эта строка разыменовывает indx, который является указателем на unsigned char. В результате получается беззнаковый символ, который затем явно преобразуется в знаковый char. Вы знаете, что битовый шаблон не изменится, поэтому снова получаете значение из диапазона от -128 до 127. Оно присваивается unsigned int, но вы знаете, что преобразование из меньшего знакового типа в более крупный беззнаковый тип вызывает расширение знака. Поэтому из-за typecast к (char) в цикл все еще можно занести злонамеренно большое значение count, но только для первой метки. Теперь с учетом этого посмотрите на проверку длины:

К сожалению, strlen(nameStr) равен 0, когда вы впервые входите в цикл. Поэтому довольно большое значение count не будет меньше (MAX_LEN - 1), и вас поймают, выбросив из цикла. Почти получилось, но нет. Забавно, что если вас выбрасывает уже на первом заходе в цикл, программа делает следующее:

Поскольку strlen(nameStr) равен 0, это означает запись 0 на 1 байт перед буфером, в nameStr[-1]. Теперь, когда вы увидели эволюцию исправления с позиции заднего ума, рассмотрим листинг 6-12, пример на основе типа данных short integer.

Листинг 6-12. Пример уязвимости расширения знака

Здесь работают сразу несколько концепций, которые вы изучали в этой главе. Во-первых, результат функции read_length(), unsigned short int, преобразуется в signed short int и сохраняется в length. В следующей проверке длины обе стороны сравнения повышаются до integers. Если length -- отрицательное число, оно проходит проверку, которая проверяет, больше ли оно 1024. Следующая строка добавляет 1 к length и передает результат как первый аргумент в malloc(). Параметр length снова расширяется по знаку, потому что для сложения он повышается до integer. Поэтому если заданный length равен 0xFFFF, он расширяется по знаку до 0xFFFFFFFF. Сложение этого значения с 1 оборачивается в 0, и malloc(0) потенциально возвращает небольшой блок памяти. Наконец, вызов read() приводит к тому, что третий аргумент, параметр length, преобразуется напрямую из signed short int в size_t. Расширение знака происходит потому, что это случай преобразования меньшего знакового типа в более крупный беззнаковый тип. Поэтому вызов read() позволяет прочитать в буфер большое количество байтов, что приводит к потенциальному переполнению буфера.

Еще один классический пример места, где программисты забывают, являются ли малые типы знаковыми, -- использование функций libc семейства ctype. Рассмотрим функцию toupper() со следующим прототипом:

На большинстве реализаций libc функция toupper() работает, находя правильный ответ в таблице поиска. Некоторые libc не обрабатывают отрицательный аргумент корректно и индексируют память перед таблицей. Следующее определение toupper() не является чем-то необычным:

Допустим, вы делаете что-то вроде этого:

Если у вас реализация libc без достаточно надежной функции toupper(), вы можете получить странные изменения в строке. Если один из символов равен -1, он преобразуется в integer со значением -1, и функция toupper() индексирует память перед своей таблицей.

Рассмотрим последний реальный пример, где программисты не учли расширение знака. Листинг 6-13 -- уязвимость Sendmail, обнаруженная исследователем безопасности Михаилом Залевским (www.cert.org/advisories/CA-2003-12.html). Она взята из Sendmail версии 8.12.3, из функции prescan(), которая в основном отвечает за разбор адресов электронной почты на токены (файл sendmail/parseaddr.c). Код сокращен для краткости.

Листинг 6-13. Уязвимость расширения знака в prescan Sendmail

Константа NOCHAR определена как -1 и предназначена для обозначения некоторых ошибочных условий при обработке символов. Переменная p обрабатывает предоставленный пользователем адрес и выходит из показанного цикла, когда прочитан полный токен. В цикле есть проверка длины; однако она выполняется только при истинности двух условий: когда c не равно NOCHAR (то есть c != -1) и bslashmode ложно. Проблема в этой строке:

Из-за расширения знака символа, на который указывает p, пользователи могут задать символ 0xFF и получить его расширение до 0xFFFFFFFF, то есть NOCHAR. Если пользователи предоставляют повторяющийся шаблон из 0x2F (символ обратной косой черты), за которым следует 0xFF, цикл может выполняться непрерывно, так и не выполняя проверку длины в начале. Это приводит к тому, что обратные косые черты постоянно записываются в буфер назначения без проверки оставшегося места. Следовательно, из-за расширения знака символа при сохранении в переменной c срабатывает неожиданный путь выполнения, который приводит к переполнению буфера.

Эта уязвимость также подкрепляет еще один принцип, сформулированный в начале главы. Неявные действия компилятора тонки, и при анализе исходного кода нужно изучать последствия преобразований типов и предвидеть, как программа будет обращаться с неожиданными значениями (в данном случае со значением NOCHAR, которое пользователи могут задать из-за расширения знака).

Расширение знака выглядит так, будто оно должно быть повсеместным и в основном безвредным в C-коде. Однако программисты редко намеренно хотят, чтобы их меньшие типы данных расширялись по знаку при преобразовании, и наличие расширения знака часто указывает на ошибку. Расширение знака довольно трудно находить в C, но в ассемблерном коде оно хорошо проявляется инструкцией movsx. Попробуйте практиковаться в поиске преобразований расширения знака в ассемблере и затем связывать их обратно с исходным кодом; это полезный прием.

В качестве короткой демонстрации сравните листинг 6-14 и листинг 6-15.

Листинг 6-14. Пример расширения знака

Листинг 6-15. Пример расширения нуля

Если предположить, что реализация использует знаковые символы, вы знаете, что в листинге 6-14 произойдет расширение знака, а в листинге 6-15 -- нет. Сравните сгенерированный ассемблерный код, приведенный в таблице 6-8.

Таблица 6-8. Расширение знака и расширение нуля в ассемблерном коде

Можно видеть, что в примере расширения знака используется инструкция movsx. В примере расширения нуля компилятор сначала очищает регистр с помощью xor eax, eax, а затем перемещает байт символа в этот регистр.

Совет аудитору: расширение знака

При поиске уязвимостей, связанных с расширением знака, нужно сосредоточиться на коде, который обрабатывает значения или указатели типа signed character либо значения или указатели типа signed short integer. Обычно их можно встретить в коде обработки строк и в сетевом коде, который декодирует пакеты с полями длины. В общем случае нужно искать код, который берет символ или short integer и использует его в контексте, вызывающем преобразование в integer. Помните: если вы видите, что signed character или signed short преобразуется в unsigned integer, расширение знака все равно происходит.

Как упоминалось ранее, один эффективный способ находить уязвимости расширения знака -- искать в ассемблерном коде бинарного файла приложения инструкцию movsx. Этот прием часто помогает прорезать несколько слоев typedef, макросов и преобразований типов при поиске потенциально уязвимых мест в коде.

Усечение

Усечение происходит, когда более крупный тип преобразуется в меньший тип. Обратите внимание, что обычные арифметические преобразования и integral promotions на самом деле никогда не требуют преобразования большого типа в меньший. Поэтому усечение может возникать только в результате присваивания, typecast или вызова функции, где есть прототип. Вот простой пример усечения:

Когда g присваивается h, верхние 16 бит значения усекаются, и h получает значение 0x5678. Поэтому если такая потеря данных происходит в ситуации, которую программист не ожидал, она вполне может привести к сбоям безопасности. Листинг 6-16 приблизительно основан на исторической уязвимости в Network File System (NFS), связанной с усечением integer.

Листинг 6-16. Пример уязвимости усечения в NFS

Справедливости ради, эта уязвимость в основном известна по рассказам, и ее существование не было проверено по исходному коду. NFS запрещает пользователям удаленно монтировать диск с привилегиями root. В конце концов злоумышленники выяснили, что могут указать UID 65536, который пройдет проверки безопасности, предотвращающие доступ root. Однако затем этот UID присваивался unsigned short integer и усекался до значения 0. Поэтому злоумышленники могли принять личность root с UID 0 и обойти защиту.

Перед реальной проблемой усечения рассмотрите еще одну синтетическую уязвимость в листинге 6-17.

Листинг 6-17. Пример уязвимости усечения

Результат функции strlen(), то есть size_t, преобразуется в unsigned short. Если строка имеет длину 66 000 символов, произойдет усечение, и f получит значение 464. Поэтому проверка длины, защищающая strcpy(), будет обойдена, и произойдет переполнение буфера.

Критическая ошибка в большинстве SSH-демонов была вызвана усечением integer. По иронии, уязвимый код находился в функции, предназначенной для устранения другой дыры безопасности -- SSH insertion attack, обнаруженной CORE-SDI. Подробности этой атаки доступны по адресу www1.corest.com/files/files/11/CRC32.pdf.

Суть атаки в том, что злоумышленники могут использовать хитрую атаку с известным открытым текстом против блочного шифра, чтобы вставлять небольшие объемы выбранных ими данных в SSH-поток. Обычно такая атака предотвращалась бы проверками целостности сообщений, но SSH использовал CRC32, и исследователи из CORE-SDI поняли, как обойти его в контексте SSH-протокола.

Функция, содержащая уязвимость усечения, отвечает за определение того, происходит ли insertion attack. Одно из свойств таких атак -- длинная последовательность похожих байтов в конце пакета, предназначенная для манипулирования значением CRC32 так, чтобы оно оказалось корректным. Спроектированная защита искала повторяющиеся блоки в пакете, а затем выполняла вычисление CRC32 до точки повтора, чтобы определить, происходит ли манипуляция. Для небольших пакетов этот метод был прост, но на больших наборах данных мог влиять на производительность. Поэтому, предположительно ради снижения этого влияния, была использована схема хэширования.

Функция, которую вы сейчас увидите, имеет два отдельных пути выполнения. Если пакет меньше определенного размера, она выполняет прямой анализ данных. Если пакет больше этого размера, она использует хэш-таблицу, чтобы сделать анализ эффективнее. Для понимания уязвимости понимать всю функцию необязательно. Однако если вам любопытно, более простой случай для малых пакетов примерно использует алгоритм, описанный в листинге 6-18.

Листинг 6-18. Алгоритм Detect_attack для малых пакетов в SSH

Код проходит по каждому 8-байтовому блоку пакета, и если видит идентичный блок в пакете перед текущим, выполняет проверку, чтобы понять, идет ли атака.

Путь через код, основанный на хэш-таблице, немного сложнее. Он использует тот же общий алгоритм, но вместо сравнения множества 8-байтовых блоков друг с другом берет 32-битный хэш каждого блока и сравнивает их. Хэш-таблица индексируется 32-битным хэшем 8-байтового блока по модулю размера хэш-таблицы, а bucket содержит позицию блока, который последним дал хэш в этот bucket. Проблема усечения возникла при создании и управлении хэш-таблицей. Листинг 6-19 содержит начало кода.

Листинг 6-19. Уязвимость усечения Detect_attack в SSH

Сначала код проверяет, не является ли пакет чрезмерно длинным и кратна ли его длина 8 байтам. SSH_MAXBLOCKS равен 32 768, а BLOCKSIZE равен 8, поэтому пакет может достигать 262 144 байтов. В следующем коде n изначально равно HASH_MINSIZE / HASH_ENTRYSIZE, то есть 8 192 / 2, или 4 096, и предназначено для хранения количества элементов в хэш-таблице:

Начальный размер хэш-таблицы -- 8 192 элемента. Этот цикл пытается определить хороший размер хэш-таблицы. Он начинает с предположения n, текущего размера, и проверяет, достаточно ли его для пакета. Если недостаточно, он учетверяет l, сдвигая его влево на два бита. Он решает, достаточно ли велика хэш-таблица, проверяя, что в ней есть 3/2 от количества 8-байтовых блоков в пакете. HASH_FACTOR определен как ((x)*3/2). Следующий код -- самая интересная часть:

Если h равно NULL, это означает первый проход через функцию, и нужно выделить место для новой хэш-таблицы. Если помните, l -- значение, вычисленное как подходящий размер хэш-таблицы, а n содержит количество элементов в хэш-таблице. Если h не равно NULL, хэш-таблица уже выделена. Однако если текущая хэш-таблица недостаточно велика относительно заново вычисленного l, она перевыделяется.

Вы уже увидели достаточно кода, чтобы заметить проблему: n -- это unsigned short int. Если отправить достаточно большой пакет, l, являющийся unsigned int, может получить значение больше 65 535, и при присваивании l в n может произойти усечение. Например, предположим, что вы отправляете пакет размером 262 144 байта. Он проходит первую проверку, а затем в цикле l меняется так:

Когда l со значением 65 536 присваивается n, верхние 16 бит усекаются, и n получает значение 0. В нескольких современных ОС malloc() с размером 0 возвращает действительный указатель на небольшой объект, а дальнейшее поведение функции становится крайне подозрительным.

Следующая часть функции -- код прямого анализа; поскольку он не использует хэш-таблицу, он не представляет непосредственного интереса:

Далее идет код, выполняющий процедуру обнаружения на основе хэшей. В следующем коде помните, что n будет равно 0, а h будет указывать на небольшой, но действительный объект в куче. С такими значениями можно делать с памятью процесса довольно интересные вещи:

Если вы не видите немедленного способа атаковать этот цикл, не волнуйтесь. Вы в хорошей компании, к тому же здесь отсутствуют некоторые критически важные определения макросов. Эта ошибка крайне тонкая, а эксплойты для нее сложны и изящны. Фактически эта уязвимость уникальна с разных точек зрения. Она подкрепляет мысль о том, что безопасное программирование трудно, и ошибиться может каждый, поскольку CORE-SDI без труда можно отнести к числу самых технически компетентных компаний по безопасности в мире. Она также демонстрирует, что иногда простой black-box тест может найти ошибки, которые было бы трудно обнаружить при аудите исходного кода; первооткрыватель, Михаил Залевский, нашел эту уязвимость поразительно прямолинейным способом (ssh -l long_user_name). Наконец, она подсвечивает примечательный случай, когда написание эксплойта может быть труднее, чем нахождение корневой уязвимости.

Совет аудитору: усечение

Уязвимости, связанные с усечением, обычно обнаруживаются там, где integer-значения присваиваются меньшим типам данных, таким как short integers или characters. Чтобы найти проблемы усечения, ищите места, где эти более короткие типы данных используются для отслеживания значений длины или хранения результата вычисления. Хорошее место для поиска потенциальных переменных -- определения структур, особенно в сетевом коде.

Программисты часто используют тип данных short или character просто потому, что ожидаемый диапазон значений переменной хорошо ложится на этот тип. Однако использование таких типов часто может приводить к непредвиденным усечениям.

Сравнения

Вы уже видели примеры знаковых сравнений с отрицательными числами в проверках длины и то, как они могут приводить к проблемам безопасности. Еще одна потенциально опасная ситуация -- сравнение двух целых с разными типами. Как вы уже узнали, при выполнении сравнения компилятор сначала выполняет integer promotions над операндами, а затем следует обычным арифметическим преобразованиям, чтобы сравнение выполнялось над совместимыми типами. Поскольку эти повышения и преобразования могут менять значение (из-за изменения знаковости), сравнение может работать не совсем так, как рассчитывал программист. Злоумышленники могут использовать эти преобразования для обхода проверок безопасности и часто для компрометации приложения.

Чтобы увидеть, как сравнения могут пойти не так, рассмотрим листинг 6-20. Этот код читает short integer из сети; он задает длину входящего пакета. Первая половина проверки длины сравнивает (length - sizeof(short)) с 0, чтобы убедиться, что указанная длина не меньше sizeof(short). Если она меньше, то при последующем вычитании sizeof(short) в операторе read() значение могло бы обернуться в большое integer.

Листинг 6-20. Пример уязвимости сравнения

Первая проверка на самом деле неверна. Обратите внимание, что тип результата оператора sizeof -- это size_t, то есть беззнаковый целочисленный тип. Поэтому для вычитания (length - sizeof(short)) переменная length сначала повышается до signed int в рамках integer promotions, а затем преобразуется в беззнаковый целочисленный тип в рамках обычных арифметических преобразований. Результирующий тип операции вычитания -- беззнаковый целочисленный тип. Следовательно, результат вычитания никогда не может быть меньше 0, и проверка фактически не работает. Значение 1 для length обходит именно то условие, от которого первая половина if должна была защищать, и вызывает integer underflow в вызове read().

Можно предоставить и другие значения, которые обходят обе проверки и вызывают переполнение буфера. Если length -- отрицательное число, например 0xFFFF, первая проверка все равно проходит, потому что тип результата вычитания всегда беззнаковый. Вторая проверка (length > MAX_SIZE) тоже проходит, потому что length повышается до signed int для сравнения и сохраняет отрицательное значение, которое меньше MAX_SIZE (1024). Этот результат показывает, что переменная length трактуется как беззнаковая в одном случае и как знаковая в другом из-за других операндов, используемых в сравнении.

При работе с типами данных, меньшими чем int, integer promotions превращают узкие значения в signed integers. Это повышение сохраняет значение и само по себе не является большой проблемой. Однако иногда сравнения могут непреднамеренно повышаться до знакового типа. Листинг 6-21 иллюстрирует эту проблему.

Листинг 6-21. Уязвимость знакового сравнения

Листинг 6-21 показывает, почему нужно понимать результирующий тип данных, используемый в сравнении. Переменные max и length являются short integers и, следовательно, проходят integer conversions; обе повышаются до signed integers. Это означает, что любое отрицательное значение, переданное в length, обходит проверку длины относительно max. Из-за преобразований типов данных, выполняемых в сравнении, можно не только обходить sanity checks, но и делать все сравнение бесполезным, если оно проверяет невозможное условие. Рассмотрим листинг 6-22.

Листинг 6-22. Уязвимость беззнакового сравнения

Листинг 6-22 проверяет переменную n, чтобы убедиться, что она находится в диапазоне от 0 до 1024. Однако поскольку переменная n беззнаковая, проверка на значение меньше 0 невозможна. Беззнаковое целое никогда не может быть меньше 0, потому что любое представимое значение положительно. Потенциальная уязвимость довольно тонкая: если злоумышленники передают недопустимое целое как argv[1], get_int() возвращает -1, которое при присваивании n преобразуется в unsigned long. Поэтому оно становится большим значением и в итоге приводит к падению программы в memset().

Компиляторы могут обнаруживать условия, которые никогда не будут истинными, и выдавать предупреждение, если передать им определенные флаги. Посмотрите, что происходит, когда предыдущий код компилируется GCC:

Обратите внимание, что флаг -Wall не предупреждает об ошибке этого типа, хотя большинство разработчиков ожидали бы обратного. Чтобы получить предупреждение для такого бага, нужно использовать флаг -W. Если код if(n < 0) изменить на if(n <= 0), предупреждение не генерируется, потому что условие уже не является невозможным. Теперь рассмотрим реальный пример похожей ошибки. Листинг 6-23 взят из модуля PHP Apache (4.3.4) при чтении данных POST.

Листинг 6-23. Пример знакового сравнения в PHP

Возвращаемое значение get_client_block() сохраняется в переменной read_bytes, а затем сравнивается, чтобы убедиться, что не было возвращено отрицательное число. Поскольку read_bytes беззнаковая, эта проверка не обнаруживает ошибки из get_client_block() так, как предполагалось. Как выясняется, этот баг не является непосредственно эксплуатируемым в этой функции. Видите почему? Условие, управляющее циклом, тоже использует беззнаковое сравнение, поэтому если total_read_bytes уменьшается ниже 0, оно переполняется вниз и, следовательно, принимает значение больше count_bytes, из-за чего цикл завершается.

Совет аудитору

Анализ сравнений необходим при аудите C-кода. Обращайте особое внимание на сравнения, которые защищают выделение памяти, индексирование массивов и операции копирования. Лучший способ изучать такие сравнения -- идти построчно и внимательно разбирать каждое релевантное выражение.

В общем случае нужно отслеживать каждую переменную и ее базовый тип данных. Если вы можете проследить вход функции до знакомого вам источника, у вас должно быть хорошее представление о возможных значениях каждой входной переменной. Проходите через каждое потенциально интересное вычисление или сравнение и отслеживайте возможные значения переменных в разных точках вычисления функции. Можно использовать процесс, похожий на описанный в предыдущем разделе о поиске проблем integer boundary conditions.

Когда оцениваете сравнение, обязательно следите за беззнаковыми integer-значениями, из-за которых соседние операнды повышаются до unsigned integers. sizeof и strlen() -- классические примеры операндов, вызывающих такое повышение.

Не забывайте следить за беззнаковыми переменными, используемыми в сравнениях, например:

Первая форма обычно заставляет компилятор выдать предупреждение, а вторая -- нет. Если вы видите такой шаблон, это хороший признак, что с этим участком кода, вероятно, что-то не так. Нужно выполнить аккуратный построчный анализ окружающей функциональности.

Операторы

Операторы могут давать непредвиденные результаты. Как вы уже видели, неочищенные операнды, используемые в простых арифметических операциях, потенциально могут открывать дыры безопасности в приложениях. Такие проблемы обычно возникают из-за пересечения граничных условий, влияющих на смысл результата. Кроме того, с каждым оператором связаны повышения типов, которые неявно выполняются над каждым из его операндов и могут давать неожиданные результаты. Поскольку получение неожиданных результатов -- сама суть поиска уязвимостей, важно знать, как такие результаты могут возникать и какие исключительные условия могут появиться. Следующие разделы выделяют эти исключительные условия и объясняют некоторые распространенные неправильные использования операторов, которые могут приводить к потенциальным уязвимостям.

Оператор sizeof

Первый оператор, который стоит упомянуть, -- sizeof. Он регулярно используется для выделения буферов, сравнений размеров и параметров размера в функциях, ориентированных на длину. В определенных обстоятельствах оператор sizeof подвержен неправильному использованию, которое может приводить к тонким уязвимостям в коде, выглядящем вполне надежно.

Одна из самых распространенных ошибок с sizeof -- случайное применение его к указателю вместо целевого объекта. Листинг 6-24 показывает пример такой ошибки.

Листинг 6-24. Пример уязвимости неправильного использования sizeof

В этом коде часть пользовательских данных читается из сети и копируется в выделенный буфер. Однако sizeof неправильно используется на buffer. Предполагается, что sizeof(buffer) вернет 1024, но поскольку он применяется к типу указателя на символ, он возвращает только 4. Это приводит к integer underflow в параметре размера для snprintf(), когда присутствует значение style; следовательно, в память, на которую указывает переменная buffer, можно записать произвольное количество данных. Эту ошибку довольно легко совершить, и при чтении кода она часто не очевидна, поэтому внимательно следите за типами переменных, передаваемых оператору sizeof. Чаще всего такие ошибки встречаются в аргументах длины, как в предыдущем примере, но иногда они также возникают при вычислении размеров для выделения памяти. Причина, по которой такой тип бага встречается сравнительно редко, в том, что неверное выделение памяти, вероятно, приведет программу к падению и поэтому во многих приложениях будет поймано до выпуска (если только оно не находится в редко проходящем пути выполнения).

sizeof() также играет важную роль в багах знаковых и беззнаковых сравнений (рассмотренных ранее в этой главе в разделе "Сравнения") и в проблемах padding структур (рассмотренных далее в разделе "Padding структур").

Совет аудитору: sizeof

Ищите использования sizeof, в которых разработчики берут размер указателя на буфер, хотя намеревались взять размер самого буфера. Это часто происходит из-за ошибок редактирования, когда буфер переносится из локальной переменной функции в аргумент функции.

Также ищите sizeof в выражениях, которые заставляют операнды преобразовываться в беззнаковые значения.

Неожиданные результаты

Вы исследовали две основные особенности арифметических операторов: граничные условия, связанные с хранением целочисленных типов, и проблемы, вызванные преобразованиями, происходящими при использовании арифметических операторов в выражениях. Некоторые другие нюансы C могут приводить к непредвиденному поведению, особенно нюансы, связанные с тем, что базовые машинные примитивы учитывают знаковость. Если ожидается, что результат попадет в определенный диапазон, злоумышленники иногда могут нарушить эти ожидания.

Интересно, что на машинах с twos complement в C есть лишь несколько операторов, в которых знаковость операндов может влиять на результат операции. Самые важные операторы в этой группе -- сравнения. Кроме сравнений, только три других оператора C имеют результат, чувствительный к тому, являются ли операнды знаковыми: сдвиг вправо (>>), деление (/) и остаток от деления (%). Эти операторы могут давать неожиданные отрицательные результаты, когда используются со знаковыми операндами, потому что соответствующие операции на машинном уровне учитывают знак. Как проверяющий код, вы должны искать неправильное использование этих операторов, потому что они могут давать результаты за пределами ожидаемого диапазона и заставать разработчиков врасплох.

Оператор сдвига вправо (>>) часто используется в приложениях вместо оператора деления (при делении на степени 2). Проблемы могут возникать, когда этот оператор используется со знаковым integer в качестве левого операнда. При сдвиге отрицательного значения вправо знак значения сохраняется базовой машиной, выполняющей расширяющий знак арифметический сдвиг. Такой сохраняющий знак сдвиг вправо показан в листинге 6-25.

Листинг 6-25. Сдвиг вправо с сохранением знака

Листинг 6-26 показывает, как этот код может дать неожиданный результат, приводящий к уязвимости. Он близок к реальной уязвимости, недавно найденной в клиентском коде.

Листинг 6-26. Пример уязвимости сдвига вправо

Эта функция предназначена для печати 16-битного беззнакового целого (старших 16 бит аргумента number). Поскольку number знаковый, сдвиг вправо расширяет number по знаку на 16 бит, если он отрицательный. Поэтому спецификатор %u в sprintf() способен напечатать число, гораздо большее, чем sizeof("65535"), то есть объем пространства, выделенного для буфера назначения; результатом становится переполнение буфера. Уязвимые сдвиги вправо -- хорошие примеры багов, которые трудно найти в исходном коде, но легко увидеть в ассемблерном коде. В Intel assembly знаковый, или арифметический, сдвиг вправо выполняется мнемоникой sar. Логический, или беззнаковый, сдвиг вправо выполняется мнемоникой shr. Поэтому анализ ассемблерного кода может помочь определить, потенциально уязвим ли сдвиг вправо к расширению знака. Таблица 6-9 показывает знаковые и беззнаковые операции сдвига вправо в ассемблерном коде.

Таблица 6-9. Знаковые и беззнаковые операции сдвига вправо в ассемблере

Деление (/) -- еще один оператор, который может давать неожиданные результаты из-за учета знака. Всякий раз, когда один из операндов отрицательный, результирующее частное тоже отрицательное. Приложения часто не учитывают возможность отрицательных результатов при выполнении деления над integers. Листинг 6-27 показывает, как использование отрицательных операндов может создать уязвимость с делением.

Листинг 6-27. Пример уязвимости деления

Листинг 6-27 берет параметр bitlength из сети и выделяет память на его основе. bitlength делится на 8, чтобы получить количество байтов, необходимых для данных, которые затем читаются из сокета. К результату добавляется единица, предположительно чтобы сохранить лишние биты, если предоставленный bitlength не кратен 8. Если можно заставить деление вернуть -1, добавление 1 дает 0, в результате чего malloc() выделяет небольшое количество памяти. Затем третий аргумент read() будет равен -1, преобразуется в size_t и будет интерпретирован как большое положительное значение.

Аналогично, оператор остатка (%) может давать отрицательные результаты при работе с отрицательным операндом-делимым. Аудиторы кода должны искать операции остатка, которые неправильно очищают свои операнды-делимые, потому что они могут давать отрицательные результаты и создавать проблемы безопасности. Операторы остатка часто используются при работе с массивами фиксированного размера (например, хэш-таблицами), поэтому отрицательный результат может сразу индексировать память перед началом массива, как показано в листинге 6-28.

Листинг 6-28. Пример уязвимости оператора остатка

Как видите, заголовок читается из сети, а информация о сессии извлекается из хэш-таблицы на основе поля идентификатора сессии в заголовке. Сессии хранятся в хэш-таблице sessions для последующего извлечения программой. Если идентификатор сессии отрицательный, результат оператора остатка отрицателен, и индексируются, а возможно и перезаписываются, элементы за пределами массива sessions, что, вероятно, было бы эксплуатируемым условием.

Как и с оператором сдвига вправо, беззнаковые и знаковые операции деления и остатка легко различить в Intel assembly. Мнемоника беззнаковой инструкции деления -- div, а ее знаковый аналог -- idiv. Таблица 6-10 показывает различие между знаковыми и беззнаковыми операциями деления. Обратите внимание, что компиляторы часто используют операции сдвига вправо вместо деления, когда делитель является константой.

Таблица 6-10. Знаковые и беззнаковые операции деления в ассемблере

Совет аудитору: неожиданные результаты

Всякий раз, когда вы встречаете сдвиг вправо, обязательно проверяйте, является ли левый операнд знаковым. Если да, может существовать небольшой потенциал уязвимости. Аналогично ищите операции остатка и деления, работающие со знаковыми операндами. Если пользователи могут задавать отрицательные значения, они могут вызвать неожиданные результаты.

Арифметика указателей

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

Обзор указателей

Вы знаете, что указатель по сути является местом в памяти -- адресом, поэтому это тип данных, который неизбежно зависит от реализации. На разных архитектурах представления указателей могут заметно различаться, и даже на 32-битной архитектуре Intel указатели могут быть реализованы по-разному. Например, у вас может быть 16-битный код или даже компилятор, который прозрачно поддерживает пользовательские схемы виртуальной памяти с сегментами. Поэтому предположим, что в этом обсуждении используется распространенная архитектура компиляторов GCC или vc++ для пользовательского кода на машинах Intel.

Вы знаете, что указатели, вероятно, должны быть беззнаковыми целыми, потому что действительные адреса виртуальной памяти могут находиться в диапазоне от 0x0 до 0xffffffff. При этом вычитание двух указателей выглядит слегка странно. Разве указателю не нужно как-то представлять и отрицательные значения? Оказывается, результат вычитания вообще не является указателем; вместо этого это знаковый целочисленный тип, известный как ptrdiff_t.

Указатели можно свободно преобразовывать в целые и в указатели других типов с помощью casts. Однако компилятор не гарантирует, что получившийся указатель или integer правильно выровнен или указывает на действительный объект. Поэтому указатели являются одной из наиболее зависящих от реализации частей языка C.

Обзор арифметики указателей

Что происходит, когда вы выполняете арифметику с указателем? Вот простой пример добавления 1 к указателю:

В этом коде есть указатель на short с именем j. Он инициализирован произвольным фиксированным адресом 0x1234. Это плохой C-код, но он помогает донести суть. Как упоминалось ранее, указатели и integers можно рассматривать взаимозаменяемо, если использовать casts, но результаты зависят от реализации. Можно предположить, что после добавления 1 к j значение j станет 0x1235. Однако, как вы, вероятно, знаете, происходит не это. На самом деле j становится 0x1236.

Когда C выполняет арифметику с участием указателя, операция выполняется относительно размера целевого объекта указателя. Поэтому когда вы добавляете 1 к указателю на объект, результатом является указатель на следующий объект такого размера в памяти. В этом примере объект -- short integer, занимающий 2 байта (на 32-битной архитектуре Intel), поэтому short, следующий за 0x1234 в памяти, находится по адресу 0x1236. Если вы вычитаете 1, результатом будет адрес short перед тем, что расположен по 0x1234, то есть 0x1232. Если добавить 5, получится адрес 0x123e, то есть пятый short после того, что расположен по 0x1234.

Другой способ думать об этом: указатель на объект рассматривается как массив, состоящий из одного элемента этого объекта. Поэтому j, указатель на short, рассматривается как массив short j[1], содержащий один short. Следовательно, j + 2 будет эквивалентно &j[2]. Таблица 6-11 показывает эту концепцию.

Таблица 6-11. Арифметика указателей и память

Теперь рассмотрим детали важных операторов арифметики указателей, описанные в следующих разделах.

Сложение

Правила сложения указателей немного строже, чем можно ожидать. Можно сложить целочисленный тип с типом указателя или тип указателя с целочисленным типом, но нельзя сложить тип указателя с типом указателя. Это имеет смысл, если учесть, что именно делает сложение указателей: компилятор не знал бы, какой указатель использовать как базовый тип, а какой -- как индекс. Например, рассмотрим следующую операцию:

Эта операция была бы недопустимой, потому что компилятор не знал бы, как преобразовать j или k в индекс для арифметики указателей. Конечно, можно привести j или k к integer, но результат был бы неожиданным, и вряд ли кто-то сделал бы это намеренно.

Одно интересное правило C состоит в том, что оператор индексирования относится к категории сложения указателей. Стандарт C утверждает, что оператор индексирования эквивалентен выражению со сложением следующим образом:

С учетом этого рассмотрим следующий пример:

Выражение b[4] ссылается на пятый объект в символьном массиве b. Согласно правилу, эквивалентная запись выглядит так:

Из предыдущего анализа вы знаете, что b + 4, где b имеет тип указателя на char, равносильно &b[4]; поэтому выражение было бы похоже на (*(&b[4])) или b[4].

Наконец, обратите внимание, что результирующий тип сложения между integer и указателем -- это тип указателя.

Вычитание

Вычитание имеет правила, похожие на сложение, за исключением того, что вычитание одного указателя из другого допустимо. Когда вы вычитаете указатель из указателя того же типа, вы запрашиваете разницу в индексах двух элементов. В этом случае результирующий тип -- не указатель, а ptrdiff_t, знаковый целочисленный тип. Стандарт C указывает, что он должен быть определен в заголовочном файле stddef.h.

Сравнение

Сравнение между указателями работает так, как можно ожидать. Оно учитывает относительные положения двух указателей в виртуальном адресном пространстве. Результирующий тип такой же, как у других сравнений: целочисленный тип, содержащий 1 или 0.

Условный оператор

Условный оператор (?) может иметь указатели в качестве двух последних операндов, и ему приходится согласовывать их типы примерно так же, как при использовании с арифметическими операндами. Он делает это, применяя все квалификаторы, которые есть у любого из типов указателя, к результирующему типу.

Уязвимости

Лишь немногие уязвимости, связанные с арифметикой указателей, были широко опубликованы, по крайней мере в описываемом здесь смысле. Многие уязвимости, включающие манипулирование указателями на символы, по сути сводятся к неправильному подсчету размеров буферов, и хотя технически они подходят под ошибки арифметики указателей, они не настолько тонки, насколько могут быть тонкими уязвимости указателей. Более вредная форма проблем возникает там, где разработчики ошибочно выполняют арифметику над указателями, не понимая, что их integer-операнды масштабируются размером целевого объекта указателя. Рассмотрим следующий код:

Цель выражения b < buf + sizeof(buf) -- не дать b продвинуться дальше buf[1023]. Однако на самом деле оно не дает b продвинуться дальше buf[4092]. Поэтому этот код потенциально уязвим к довольно прямолинейному переполнению буфера.

Листинг 6-29 выделяет буфер, а затем копирует первый компонент пути из строки-аргумента в буфер. Есть проверка длины, защищающая функцию wcscat от переполнения выделенного буфера, но она построена неправильно. Поскольку строки состоят из wide characters, вычитание указателей, выполненное для проверки размера входа (sep - string), возвращает разницу двух указателей в wide characters, то есть разницу между двумя указателями в байтах, деленную на 2. Поэтому эта проверка длины проходит, пока (sep - string) содержит меньше (MAXCHARS * 2) wide characters, что может быть вдвое больше пространства, чем способен вместить выделенный буфер.

Листинг 6-29. Пример уязвимости арифметики указателей

Совет аудитору

Ошибки арифметики указателей бывает трудно заметить. Всякий раз, когда выполняется арифметическая операция с участием указателей, посмотрите тип этих указателей и затем проверьте, согласуется ли операция с происходящей неявной арифметикой. В листинге 6-29 был ли sizeof() неправильно использован с указателем на тип, который не является байтом? Произошла ли похожая операция, где разработчик предположил, что тип указателя не повлияет на выполнение операции?

Прочие нюансы C

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

Порядок вычисления

Для большинства операторов C не гарантирует порядок вычисления операндов или порядок присваиваний из "побочных эффектов" выражения. Например, рассмотрим такой код:

Нет гарантии, в каком порядке будут выполнены два инкремента, и вы обнаружите, что вывод различается в зависимости от компилятора и архитектуры, на которой компилируется программа. Единственные операторы, для которых порядок вычисления гарантирован, -- это &&, ||, ?: и ,. Обратите внимание, что запятая здесь не относится к аргументам функции; порядок их вычисления определяется реализацией. Поэтому даже в таком простом коде нет гарантии, что a() будет вызвана до b():

Неоднозначные побочные эффекты немного отличаются от неоднозначного порядка вычисления, но имеют похожие последствия. Побочный эффект -- это выражение, вызывающее изменение переменной: присваивание или оператор инкремента, например ++. Порядок вычисления побочных эффектов в пределах одного выражения не определен, поэтому что-то вроде следующего определяется реализацией и, следовательно, может вызывать проблемы:

Как такие проблемы могут влиять на безопасность? В листинге 6-30 разработчик использует вызов getstr(), чтобы получить строку пользователя и строку пароля из некоторого внешнего источника. Однако если система будет перекомпилирована и порядок вычисления функций getstr() изменится, код может начать записывать в лог пароль вместо имени пользователя. Конечно, это была бы проблема низкого риска, пойманная во время тестирования.

Листинг 6-30. Логическая уязвимость порядка вычисления

В листинге 6-31 есть функция copy_packet(), которая читает пакет из сети. Она использует макрос GET32(), чтобы извлечь integer из пакета и продвинуть указатель. В протоколе предусмотрен необязательный padding, а наличие поля размера padding обозначается флагом в заголовке пакета. Поэтому если установлен FLAG_PADDING, порядок вычисления макросов GET32() при вычислении datasize теоретически может быть обращен. Если опция padding находится в редко используемой части протокола, ошибка такого рода может остаться незамеченной в промышленной эксплуатации.

Листинг 6-31. Уязвимость макроса из-за порядка вычисления

Padding структур

Одна довольно малоизвестная особенность структур C состоит в том, что члены структуры не обязаны располагаться в памяти непрерывно. Порядок членов гарантированно следует порядку, заданному программистами, но между членами может использоваться padding структуры для удовлетворения требований выравнивания и производительности. Вот пример простой структуры:

Как вы думаете, чему равен sizeof(bob)? Разумная догадка -- 7; это sizeof(a) + sizeof(b) + sizeof(c), то есть 4 + 2 + 1. Однако большинство компиляторов возвращает 8, потому что они вставляют padding структуры. Сейчас такое поведение выглядит несколько obscure, но оно определенно станет хорошо известным явлением по мере распространения 64-битного кода, потому что потенциально влияет на такой код острее. Как это может иметь последствия для безопасности? Рассмотрим листинг 6-32.

Листинг 6-32. Padding структуры в сетевом протоколе

На 32-битной big-endian системе структура netdata, скорее всего, будет расположена так, как показано на рисунке 6-9. У вас есть unsigned int, unsigned short, 2 байта padding и unsigned int, всего размер структуры составляет 12 байтов. Рисунок 6-10 показывает трафик, проходящий по сети, в network byte order. Если разработчики не ожидают, что в структуру будет вставлен padding, они могут неправильно интерпретировать сетевой протокол. Эта ошибка может привести к тому, что сервер примет replay attack.

Рисунок 6-9. Структура netdata на 32-битной big-endian машине

Рисунок 6-10. Сетевой протокол в network byte order

Вероятность совершить ошибку такого рода возрастает на 64-битных архитектурах. Если структура содержит указатель или значение long, компоновка структуры в памяти, скорее всего, изменится. Любое 64-битное значение, например указатель или long int, будет занимать вдвое больше места, чем на 32-битной системе, и должно размещаться на границе 64-битного выравнивания.

Содержимое padding bits зависит от того, что находилось в памяти при выделении структуры. Эти биты могут различаться, что может приводить к логическим ошибкам, связанным со сравнениями памяти, как показано в листинге 6-33.

Листинг 6-33. Пример double free из-за padding структуры

Если padding структуры различается в двух структурах, это может вызвать ошибку double-free. Рассмотрим листинг 6-34.

Листинг 6-34. Пример неверного подсчета из-за padding структуры

Размер hdropt, вероятно, будет равен 3, потому что требований padding для выравнивания нет. Размер hdr, вероятно, будет равен 8, а размер msghdr, вероятно, будет равен 12, чтобы выровнять две структуры. Поэтому memset запишет 1 байт с \0 за пределами выделенных данных.

Приоритет

Когда вы анализируете код, написанный опытными разработчиками, часто встречаются сложные выражения, которые выглядят рискованно лишенными скобок. Интересной уязвимостью была бы ситуация, где допущена ошибка приоритета, но она возникает так, что не полностью ломает программу.

Первая потенциальная проблема -- приоритет битовых операторов & и |, особенно когда вы смешиваете их с операторами сравнения и равенства, как в этом примере:

Программисты пытаются понять, является ли len отрицательным, проверяя старший бит. Их намерение выглядит примерно так:

Однако в ассемблерный код фактически попадает вот это:

Этот код будет вычислен как len & 1. Если младший бит len не установлен, проверка пройдет, и пользователи смогут указать отрицательный аргумент для memcpy().

Есть также потенциальные проблемы приоритета с присваиванием, но они вряд ли всплывут в production-коде из-за предупреждений компилятора. Например, посмотрите на следующий код:

Авторы намеревались написать следующее:

Однако получили следующее:

После выхода из if переменная len будет равна 1 или 0. Если она равна 1, второй аргумент snprintf() равен -29, что по сути означает неограниченную строку.

Вот еще одна потенциальная ошибка приоритета:

Авторы намеревались написать следующее:

Как можно догадаться, они получили следующее:

Макросы/препроцессор

Препроцессор C также может быть источником проблем безопасности. Большинство людей знакомы с проблемами в таком макросе:

Если использовать его следующим образом:

он будет вычислен так:

Этот результат очевидно неверен. Рекомендуемое исправление -- поставить скобки вокруг макроса и аргументов, чтобы получилось следующее:

С макросами, построенными таким образом, все еще можно попасть в неприятности, если учитывать порядок вычисления и проблемы побочных эффектов. Например, если использовать следующее:

оно будет вычислено как:

Этот результат определяется реализацией. Аналогично, если использовать следующее:

оно будет вычислено как:

Этот результат, вероятно, не соответствует намерениям автора. Макросы вполне могут вносить проблемы безопасности, если используются способом, выходящим за рамки обычного применения, поэтому будьте внимательны при аудите кода, который активно их использует. Если сомневаетесь, разворачивайте их вручную или смотрите вывод прохода препроцессора.

Опечатки

Программисты могут делать множество простых типографических ошибок, которые не влияют на компиляцию программы и не нарушают ее выполнение, но могут приводить к проблемам, релевантным безопасности. Такие ошибки сравнительно редки в production-коде, но иногда они появляются. Искать опечатки в коде может быть даже интересно. Возможные типографические ошибки представлены как серия задач. Попробуйте найти ошибку до чтения анализа.

Задача 1

Оператор if (left = 0) должен быть записан как if (left == 0).

В правильной версии кода, если left равен 0, цикл обнаруживает попытку переполнения буфера и аварийно завершает выполнение. В неправильной версии оператор if присваивает 0 переменной left, а результат этого присваивания равен 0. Оператор if (0) не истинен, поэтому следующим выполняется оператор left--;. Поскольку left равен 0, left-- становится отрицательной 1 или большим положительным числом, в зависимости от типа left. В любом случае left не равен 0, поэтому цикл while продолжается, а проверка не предотвращает переполнение буфера.

Задача 2

Оператор if (f = FLAG_AUTHENTICATED) должен быть записан так:

В правильной версии кода, если security flags пользователя показывают, что он аутентифицирован, функция возвращает LOGIN_OK. Иначе она возвращает LOGIN_FAILED.

В неправильной версии оператор if присваивает f то значение, которым в данный момент является FLAG_AUTHENTICATED. Оператор if всегда успешен, потому что FLAG_AUTHENTICATED -- некоторое ненулевое значение. Поэтому функция возвращает LOGIN_OK для каждого пользователя.

Задача 3

Оператор for (i==5; src[i] && i<10; i++) должен быть записан так:

В правильной версии кода цикл for копирует 4 байта, начиная чтение с src[5] и запись с dst[0]. В неправильной версии выражение i==5 вычисляется как true или false, но не влияет на содержимое i. Поэтому если i имеет некоторое значение меньше 10, цикл for может читать и писать за пределами буферов dst и src.

Задача 4

Оператор if должен выглядеть так:

В правильной версии кода программа получает строку в буфер src и проверяет буфер src на переполнение. Если переполнения нет, она копирует строку в буфер dst и печатает "string safely copied".

В неправильной версии оператор & не имеет тех же характеристик, что оператор &&. Даже если в этой ситуации нет проблемы из-за различия между логическим и битовым AND, остается критическая проблема short-circuit evaluation и гарантированного порядка выполнения. Поскольку это битовая операция AND, вычисляются оба выражения-операнда, а порядок их вычисления не обязательно известен. Поэтому copy_string() вызывается даже если check_for_overflow() завершается неуспешно, и она может быть вызвана до check_for_overflow().

Задача 5

Оператор if должен выглядеть так:

В правильной версии кода программа выполняет memcpy() только если длина находится в определенных пределах, тем самым предотвращая атаку с переполнением буфера. В неправильной версии лишняя точка с запятой в конце оператора if обозначает пустой оператор, а значит memcpy() выполняется всегда, независимо от результата проверок длины.

Задача 6

Оператор char buf[040]; должен быть записан как char buf[40];.

В правильной версии кода программа выделяет 40 байтов для буфера, в который копирует пользовательский ввод. В неправильной версии программа выделяет 32 байта. Когда целочисленная константа в C начинается с 0, это указывает компилятору, что константа записана в восьмеричной системе. Поэтому длина буфера интерпретируется как 040 восьмеричное, или 32 десятичное, и snprintf() может записать за пределы стекового буфера.

Задача 7

Оператор if должен выглядеть так:

В правильной версии кода программа проверяет длину перед выполнением memcpy() и вызывает abort(), если длина выходит за подходящий диапазон.

В неправильной версии отсутствие завершения комментария означает, что memcpy() становится целевым оператором для оператора if. Поэтому memcpy() выполняется только если проверки длины не проходят.

Задача 8

Первый оператор if должен выглядеть так:

В правильной версии программа проверяет длину перед выполнением memcpy(). Если длина выходит за подходящий диапазон, программа выставляет флаг, который вызывает аварийное завершение.

В неправильной версии отсутствие составного оператора после if означает, что memcpy() выполняется всегда. Отступ предназначен для того, чтобы обмануть глаза читателя.

Задача 9

Оператор report_magic(1) должен выглядеть так:

В правильной версии программа проверяет длину перед выполнением memcpy(). Если длина выходит за подходящий диапазон, программа выставляет флаг, который вызывает аварийное завершение.

В неправильной версии отсутствие составного оператора после magicword if означает, что проверка длины выполняется только если сравнение magicword истинно. Поэтому memcpy(), скорее всего, выполняется всегда.

Задача 10

Заметили баг? В одной из проверок длины есть ошибка: разработчики используют битовый оператор AND (&) вместо логического AND (&&). Конкретно оператор должен выглядеть так:

Эта простая ошибка могла бы привести к повреждению памяти, если бы функция BUF_MEM_grow_clean() завершилась неудачно. Эта функция возвращает 0 при неудаче, а логический оператор not превратит это значение в 1. Затем произойдет битовая операция AND с frag_len. Поэтому в случае неудачи неверный оператор фактически делает следующее:

Резюме

Эта глава рассмотрела нюансы языка программирования C, которые могут приводить к тонким и сложным уязвимостям. Эти базовые знания должны помочь вам выявлять проблемы, которые могут возникать при обработке операторов, преобразованиях типов, арифметических операциях и распространенных C-опечатках. Однако сложный характер этой темы не позволяет полностью понять ее за один проход. Поэтому возвращайтесь к этому материалу по мере необходимости при проведении оценок приложений. В конце концов, даже лучший аудитор кода легко может пропустить тонкие ошибки, способные привести к серьезным уязвимостям.

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

Аудит использования переменных

Переменные -- это объекты, используемые для хранения элементов данных, имеющих некоторое значение для приложения. Их смысл определяется тем, как они используются: что в них хранится, какие операции над ними выполняются и что они представляют. Значительная часть аудита кода основана на понимании переменных, их отношений друг с другом и того, как на приложение может неблагоприятно повлиять неожиданная манипуляция этими отношениями. Этот раздел обсуждает разные техники распознавания неправильного использования переменных и структур данных и приводит несколько примеров из популярных приложений, чтобы закрепить концепции.

Отношения между переменными

Переменные связаны друг с другом, если их значения каким-либо образом зависят друг от друга или если они вместе используются для представления некоторого состояния приложения. Например, функция может иметь одну переменную, которая указывает на доступную для записи позицию в буфере, и одну переменную, которая отслеживает объем оставшегося места в этом буфере. Эти переменные связаны друг с другом, и их значения должны изменяться синхронно при манипуляциях с буфером. Чем больше переменных используется для представления состояния, тем выше вероятность, что переменными можно будет манипулировать так, чтобы нарушить отношения между ними, что приведет к общему несогласованному состоянию. Как аудитор кода, вы должны искать переменные, связанные друг с другом, определять их предполагаемые отношения, а затем выяснять, есть ли способ десинхронизировать эти переменные. Обычно это означает поиск блока кода, который изменяет одну переменную способом, несогласованным с другими переменными. Примеры такого типа уязвимости могут варьироваться от простых ошибок с двумя переменными в цикле до сложных ошибок, где множество переменных в нескольких модулях программы вместе представляют сложное состояние.

Сначала рассмотрим листинг 7-1, пример из модуля Apache mod_dav. Этот код работает с XML-элементами CDATA.

Листинг 7-1. Уязвимость разбора CDATA в Apache mod_dav

В листинге 7-1 видно, что буфер данных s (также установленный в cdata) выделяется через apr_palloc(), а затем строковые элементы данных из двух связанных списков (elem->first_cdata.first и elem->first_child) копируются в этот буфер данных. Длина буфера cdata, переменная len, была ранее вычислена двумя похожими циклами по связанным спискам. В этот момент есть две связанные переменные, которые нас интересуют: указатель на буфер, cdata, и переменная, представляющая длину буфера, len. Предыдущий код корректен, но посмотрите, что происходит, когда mod_dav пытается обрезать буфер, удаляя пробельные символы:

Начальные пробелы пропускаются инкрементом переменной cdata; однако переменная len не уменьшается, чтобы отразить сокращение размера буфера. Отношение между двумя переменными становится недействительным. Поэтому когда во втором цикле while обрезаются завершающие пробелы, позиция cdata[len] может указывать за пределы буфера.

Предыдущий пример показывает довольно прямолинейную ошибку. Обычно уязвимости такого рода гораздо сложнее, потому что несколько связанных переменных вместе представляют состояние приложения или потому что сложные пути выполнения дают больше возможностей для десинхронизации переменных. Чтобы увидеть пример таких путей выполнения, рассмотрим листинг 7-2 из кода resolver BIND 9.2.1. Код сокращен, потому что он довольно длинный и достаточно труден для чтения.

Листинг 7-2. Уязвимость кода resolver gethostans() в Bind 9.2.1

Теперь рассмотрим переменные, участвующие в предыдущем коде. При входе в функцию ansbuf является указателем на DNS response packet, а cp указывает на первую запись в пакете после DNS-заголовка. Буфер pvt->hostbuf хранит имена хостов, прочитанные из DNS-ответа. Переменная buflen представляет объем оставшегося места в буфере hostbuf и соответствующим образом обновляется по мере записи в буфер каждого ответа из пакета. Переменная bp содержит текущую позицию записи в буфере имени хоста. Поэтому каждый раз, когда bp инкрементируется и указывает дальше в буфер, buflen должна уменьшаться на ту же величину. Цикл while в конце проходит по каждому ответу в DNS response packet (это отслеживается переменной anscount), убеждаясь, что чтение не выходит за конец пакета (хранящийся в eom).

Следующий код обрабатывает извлечение имен хостов из ответа CNAME на запрос. С точки зрения безопасности он корректен и должен дать вам некоторое понимание использования переменных:

В сущности, если запрос является запросом IP-адреса (qtype==T_A), а сервер отвечает CNAME, то есть псевдонимом, программе нужно записать этот псевдоним в список (pvt->host_aliases) и поместить имя хоста в буфер pvt->hostbuf. Если в списке псевдонимов есть место, BIND использует dn_expand(), чтобы извлечь имя хоста из пакета во временный буфер tbuf. Если это имя допустимо, псевдоним сохраняется в буфере имени хоста. Обратите внимание, что выделенное ранее отношение между синхронным движением bp и buflen сохранено. Проверяющий код, сосредоточенный на этом отношении, увидит один случай, где десинхронизация bp и buflen возможна, а именно при преобразовании информации, связанной с записями A и AAAA. Проблемный код показан в следующем фрагменте:

Как видите, переменная bp обновляется без уменьшения buflen, тем самым десинхронизируя две переменные. Это создает возможность для клиентов отправлять искаженные DNS-ответы с несколькими A и AAAA ответами, которые сохраняются неправильно; в результате переменная pvt->hostbuf может быть переполнена. Эта уязвимость с тех пор была исправлена удалением данного отношения между переменными, чтобы подобный баг не возник снова. Вместо переменной buflen введена переменная-указатель ep, статически установленная на конец буфера. Хотя эта переменная тоже связана с bp, отношение безопаснее, потому что ep никогда не должна двигаться и, следовательно, никогда не может быть десинхронизирована. В такой ситуации нужно пытаться выявлять участки кода, где bp инкрементируется за ep, а вычитание двух указателей (ep - bp) преобразуется в большое положительное integer, передаваемое как аргумент длины.

Предыдущий пример продемонстрировал переменную длины, которая неправильно обновлялась относительно оставшегося места в буфере. Несмотря на объем кода в этой функции, это все еще прямолинейный пример, поскольку только две переменные составляли состояние, которое вы пытались десинхронизировать. Иногда несколько переменных взаимосвязаны и представляют более сложное состояние, как в листинге 7-3, который состоит из кода Sendmail 8.11.x.

Листинг 7-3. Уязвимость связанных переменных в Sendmail crackaddr()

Листинг 7-3 показывает начальную настройку функции crackaddr(), которая используется для проверки синтаксиса предоставленного адреса электронной почты, а также для вывода его в символьный массив buf. Здесь несколько переменных вместе представляют состояние функции. Все переменные, заканчивающиеся на lev, обозначают некоторый уровень вложенных компонентов адреса. Переменная режима skipping используется для указания, что места в выходном буфере больше нет, а несколько других переменных представляют разные аспекты входной строки и ее допустимости. Следующий код показывает еще немного обработки в этой функции.

В некоторых случаях запись в выходной буфер происходит без проверки переменной режима skipping, которая должна подтверждать наличие достаточного места, а именно при работе с символом угловой скобки (>). Изучив код, можно увидеть повторяющиеся шаблоны, которые пользователи могут предоставить, чтобы заставить эти символы записываться за пределы буфера. В частности, когда предоставляется символ угловой скобки, он может быть записан в выходной буфер несмотря на включенный skipping mode, если copylev меньше или равен нулю. Когда символ угловой скобки записывается, copylev инкрементируется, поэтому нужен способ уменьшить его обратно до нуля. Оказывается, copylev можно декрементировать, предоставив закрывающую скобку, если cmtlev больше 0; это можно обеспечить, сначала предоставив открывающую скобку. Поэтому шаблон ()>()>()> ... приводит к записи некоторого количества символов > за пределы буфера. У этого бага две первопричины: есть места, где символы могут записываться в выходной буфер несмотря на включенный skipping mode, и переменные lev не инкрементируются и декрементируются одинаково символами, ограничивающими компонент адреса, такими как ( и ), когда skipping mode включен.

Когда вы начинаете изучать новую функцию, полезно быстро пройти по коду и выявить в функции отношения, подобные этому. Затем сделайте один проход, чтобы понять, могут ли какие-либо переменные быть десинхронизированы. Хорошо спроектированное приложение стремится сводить отношения между переменными к минимуму. Разработчики часто скрывают сложные отношения в отдельных подсистемах, чтобы внутренние детали не были открыты вызывающему коду; такое сокрытие переменных известно как data hiding и обычно считается хорошим стилем программирования. Однако data hiding может усложнить вашу работу, распределяя сложные отношения по нескольким файлам и функциям. Примеры data hiding включают private variables в классе C++ и подсистему управления буферами в OpenSSH. В следующем разделе вы увидите пример уязвимости десинхронизации в этой подсистеме управления буферами.

Неправильное управление структурами и объектами

Приложения часто используют крупные структуры для управления состоянием программы и сессии, а также для группировки связанных элементов данных. Сама суть объектно-ориентированного программирования поощряет такое поведение, поэтому проверяющие код часто сталкиваются с кодом, который широко использует непрозрачные объекты или структуры, нередко изменяемые через недостаточно документированные интерфейсы. Проверяющие код должны разобраться в этих интерфейсах, чтобы понять назначение объектов и составляющих их членов.

Как обсуждалось в предыдущем разделе, чем больше связанных переменных есть в части приложения, тем выше вероятность ошибки несогласованного состояния. Одна из целей аудита объектно-ориентированного кода -- определить, можно ли десинхронизировать связанные члены структуры или оставить их в неожиданном либо несогласованном состоянии, чтобы заставить приложение выполнить некоторую непредвиденную операцию. Например, OpenSSH широко использует динамические изменяемые буферы данных по всему приложению. Процедура, отвечающая за инициализацию структуры буфера, buffer_init(), показана в листинге 7-4.

Листинг 7-4. Уязвимость повреждения буфера в OpenSSH 3.6.1

Из этого можно вывести, что переменные buf и alloc имеют связь: член alloc всегда должен представлять количество байтов, выделенных в буфере. Изучая другие функции buffer_*, можно вывести еще несколько отношений, а именно что offset и end являются смещениями внутри буфера, оба должны быть меньше alloc, и offset должен быть меньше end. Если эти отношения не соблюдаются, код может содержать проблемы integer underflow. Поэтому при анализе этого приложения нужно определить, можно ли нарушить какие-либо из этих отношений между переменными, поскольку результирующее несогласованное состояние может вызвать переполнение буфера.

В этом коде две переменные могут быть десинхронизированы в одном случае: переменные buf и alloc. Эта проблема возникает в buffer_append_space(), показанной в следующем коде:

Переменная alloc увеличивается на определенную величину, из-за чего становится несогласованной с количеством данных, выделенных в buf. Затем buf перевыделяется, так что структура снова согласована при возврате вызывающей функции, но разработчик не учел последствия отказа функции xrealloc() или провала проверки длины alloc относительно константного значения 0xa00000. Оба отказа в конечном счете приводят к вызову функции fatal(). Если проверка длины проваливается или xrealloc() завершается неудачно, fatal() вызывается немедленно. Реализация xrealloc() показана в следующем коде:

Можно видеть, что xrealloc() также вызывает fatal() при неудаче. Дальнейшее исследование показывает, что функция fatal() очищает несколько глобальных переменных, включая буферы, используемые для обработки входных и выходных данных, с помощью процедуры buffer_free(), показанной здесь:

Следовательно, если выделение памяти завершается неудачно или достигается встроенный порог размера, и изменяемый буфер является одной из этих глобальных переменных, функция memset() в buffer_free() записывает большой объем данных за пределы выделенного буфера. Затем вызываются еще несколько функций очистки, что создает возможность для эксплуатации.

Этот пример показывает, что баги неправильного управления структурами обычно бывают довольно тонкими, поскольку код управления структурами распределен по нескольким небольшим функциям, каждая из которых сама по себе довольно проста. Поэтому любые уязвимости обычно являются результатом совокупного, возникающего поведения сразу нескольких функций. Одна важная проблемная область в таком коде управления структурами -- низкоуровневые вопросы языка, такие как преобразование типов, отрицательные значения, арифметические границы и арифметика указателей (обсуждается в главе 6, "Проблемы языка C"). Причина в том, что код управления часто выполняет много вычислений и сравнений длин. Вспомните пример OpenSSL с арифметическими границами (см. листинг 7-10). Вы смогли передать отрицательное значение в функцию BUF_MEM_grow(), которая отвечает за управление буферами в библиотеках OpenSSL. Листинг 7-5 показывает внутреннее устройство этой функции.

Листинг 7-5. Десинхронизация знаковой переменной в OpenSSL BUF_MEM_grow()

Как видите, эта структура представляет длины знаковыми integers. Код в этом контексте довольно опасен, поскольку все сравнения в функции не учитывают отрицательные значения корректно. Можно видеть, что если функция получает отрицательное значение длины, первое сравнение проходит успешно, и программа ошибочно определяет, что в текущем выделенном буфере уже есть достаточно свободного места. Проверяющие код должны искать любые места, где в эту функцию может быть передана отрицательная длина, потому что это десинхронизирует data и length.

Естественно, при анализе объектно-ориентированного кода, например приложений на C++ или Java, связанные переменные часто организованы в классы. Вы уже рассмотрели простые несогласованности в объектах, связанные с неинициализированными переменными; однако более широкий набор проблем возникает, когда объект остается в несогласованном состоянии. Процесс поиска таких уязвимостей похож на пример OpenSSH: определите, как переменные связаны друг с другом, и попытайтесь понять, существует ли путь выполнения, где эти переменные могут обновляться неожиданным образом. Неявные member functions являются важной частью объектно-ориентированных языков, и аудиторы кода, скорее всего, найдут больше потенциальных тонких уязвимостей, вызванных неверными предположениями о поведении неявных member functions, например перегруженных операторов.

Совет аудитору

Определите, что означает каждая переменная в определении и как каждая переменная связана с другими. Когда вы поймете отношения, проверьте member functions или interface functions, чтобы определить, могут ли возникнуть несогласованности в выявленных отношениях между переменными. Для этого найдите пути выполнения, где одна переменная обновляется, а другая -- нет.

Инициализация переменных

Иногда программисты совершают ошибку, читая значение из переменной до того, как она была инициализирована. В основном это происходит в двух обстоятельствах:

• Программист хотел, чтобы переменная была инициализирована в начале функции, но забыл указать инициализатор при объявлении.

• Существует путь выполнения, где переменная случайно используется, так и не будучи инициализированной.

Ошибка инициализации переменной приводит к тому, что неинициализированные, а значит неопределенные, данные из области памяти, где находится переменная (обычно стек или куча программы), интерпретируются и получают смысл. Во многих случаях злоумышленники могут влиять на эти области памяти и использовать ошибку, чтобы получить контроль над процессом, содержащим проблемный код. В любом случае неожиданные данные дают возможность перейти по неожиданным путям выполнения, что часто имеет нежелательные результаты. Листинг 7-6 -- простой пример.

Листинг 7-6. Использование неинициализированной переменной

Листинг 7-6 принимает login string, содержащую имя пользователя и необязательный login style, обозначенный двоеточием в login string. Позже код выбирает альтернативный путь выполнения на основе предоставленного login style. Проблема в том, что если style не предоставлен, переменная style никогда не инициализируется, и обращения к ней читают случайные данные из стека программы. При аккуратной манипуляции злоумышленники могли бы влиять на значения, которые принимают неинициализированные переменные. Атаковать эту уязвимость возможно, хотя и довольно сложно: злоумышленникам нужно выяснить порядок вызова функций и их относительную глубину стека, то есть если функция X вызывает функцию Y, а затем функцию Z, локальные переменные функции Y остаются в стеке примерно в том же месте, где функция Z выделяет место для своих локальных переменных.

Большинство уязвимостей такого рода возникает, когда функция идет по ненормальному пути выполнения. Функции, выделяющие несколько объектов, обычно имеют эпилог, который очищает объекты, чтобы избежать утечек памяти при возникновении ошибки. Рассмотрим код в листинге 7-7.

Листинг 7-7. Неинициализированный буфер памяти

Если ошибка возникает во время вызова read_data(), буфер buf не выделяется, как и struct descriptor *desc. Однако в условии err они все равно освобождаются, потенциально создавая эксплуатируемую ситуацию.

При аудите C++-кода обращайте особое внимание на member variables в объектах, поскольку неожиданные пути выполнения могут оставлять объекты в несогласованном или частично неинициализированном состоянии. Лучший способ начать изучать такой код обычно состоит в просмотре функций-конструкторов, чтобы увидеть, не забывают ли какие-либо конструкторы инициализировать некоторые элементы объекта. Листинг 7-8 показывает простой пример.

Листинг 7-8. Неинициализированные атрибуты объекта

В примере есть очевидная проблема: конструктор никогда не инициализирует свой member data. Поэтому если вызов read() завершается неудачно, деструктор автоматически вызывается во время эпилога функции. Деструктор по умолчанию для этого объекта затем вызывает функцию free() на member data, который является произвольным значением, потому что он никогда не был инициализирован, поскольку obj.setdata() никогда не вызывалась. Этот пример иллюстрирует важный момент: баги такого рода в C++-приложениях могут быть гораздо тоньше, потому что многие операции происходят неявно. Проверяющим код нужно помнить об этих неявных операциях, таких как вызовы конструкторов и деструкторов, перегруженные операторы и так далее, при оценке фрагмента кода.

Совет аудитору

Когда переменные читаются, определите, существует ли путь выполнения, где переменная не инициализируется значением. Обращайте особое внимание на cleanup epilogues, к которым переходят из нескольких мест функции, поскольку именно там наиболее вероятно возникновение уязвимостей такого рода. Также следите за функциями, которые предполагают, что переменные инициализированы где-то еще в программе. Когда вы находите такой код, попытайтесь определить, есть ли способ вызвать функции, делающие эти предположения, в моменты, когда эти предположения неверны.

Арифметические границы

Арифметические границы подробно представлены в главе 6. Однако при аудите использования переменных полезно иметь структурированный процесс выявления таких уязвимостей. Следующие три шага дают хороший план атаки:

1. Обнаружить операции, которые при срабатывании граничного условия имели бы последствия для безопасности (в основном вычисления и сравнения, основанные на длинах).

2. Определить набор значений для каждого операнда, которые вызывают соответствующее оборачивание арифметической границы.

3. Определить, может ли этот путь выполнения быть достигнут со значениями из набора, определенного на шаге 2.

Первый шаг обычно прост. Для аудиторов здравый смысл подсказывает, нужно ли считать арифметическую операцию способной неблагоприятно повлиять на приложение. В некотором смысле любая операция, которую можно подорвать, вредна для приложения; однако проблемы следует рассматривать по степени серьезности, от обычных багов до уязвимостей, представляющих непосредственную опасность при эксплуатации. Также нужно учитывать контекст ошибочного вычисления. В зависимости от характера приложения злоумышленника может не интересовать типичная ошибка вычисления длины буфера. Например, банковское приложение, которое неправильно обрабатывает отрицательные значения в транзакциях, потенциально еще опаснее, чем уязвимость повреждения памяти.

После выявления проблемных областей шаг 2 требует найти problem domain, то есть набор значений, которые могут вызвать арифметические граничные условия. Например, следующая строка кода выполняет проверку длины перед копированием данных:

Если предположить, что length -- 32-битное беззнаковое значение, видно, что integer wrap обходит эту проверку, когда length содержит значение между 0xFFFFFFE0 и 0xFFFFFFFF. Вычисления с несколькими переменными часто имеют problem domains, которые не являются непрерывным набором значений, как в следующем выражении:

В этом примере проверку длины можно обойти, пока сумма length1 и length2 переполняет нулевую границу. Неважно, какая переменная принимает большое значение (или принимают ли обе), пока вместе они дают значение больше 0xFFFFFFFF. При оценке таких проблем нужно записывать местоположение проблемного случая, а затем возвращаться к нему, когда у вас появится представление об ограничениях, наложенных на каждую переменную.

Наконец, на шаге 3 нужно определить, может ли путь выполнения быть достигнут, когда переменные содержат значения из problem domain. Этот шаг можно выполнить довольно прямолинейно:

• Определите тип данных вовлеченной переменной. Определение типа данных позволяет задать начальный набор значений, которые переменная может принимать. Если problem domain -- от 0xFFFFFFE0 до 0xFFFFFFFF, но переменная является 16-битным беззнаковым integer, проверку можно автоматически отбросить, потому что переменная никогда не сможет принять значения из рассматриваемого domain. Обратите внимание на использование unsigned: знаковая 16-битная переменная может принимать значения из problem domain, если во время проверки происходят определенные преобразования типов.

• Определите точки, в которых переменной присваивается значение. Следующий шаг -- определить, где и как переменная получает значение. Обращайте внимание на то, какие значения по умолчанию может принимать параметр, и отмечайте любые специальные конфигурации, которые могут сделать приложение уязвимым. Также нужно проследить значения других переменных, присваиваемых подозрительной переменной. Если ни одно из присвоенных значений не может пересекаться с problem domain, операцию можно пометить как безопасную.

• Определите ограничения на переменную от присваивания до уязвимой операции. Теперь, когда вы знаете начальный набор значений и возможные присваивания, нужно определить любые ограничения, наложенные на переменную на уязвимом пути выполнения. Часто переменная проходит через ряд проверок, которые уменьшают набор значений, которые она может принимать. Нужно проследить переменную через ее использование и определить, какие значения входят в этот уменьшенный набор, известный как validated domain. Любое пересечение problem domain и validated domain представляет уязвимость.

• Определите дополнительные ограничения пути выполнения. Помимо переменной, используемой в уязвимой операции, другие переменные могут играть важную роль в срабатывании бага. Следует записывать эти дополнительные переменные и значения, которые могут приводить к уязвимым путям выполнения.

Теперь, когда вы понимаете, как выявлять арифметические граничные условия, попробуем применить процесс к уязвимому пути выполнения в листингах 7-9 и 7-10.

Листинг 7-9. Пример арифметической уязвимости

Для целей этого обсуждения предположим, что функция alloc() в листинге 7-9 уязвима к integer overflow, и вы хотите определить эксплуатируемый путь к этой функции. Для этого нужно сначала понять, как обойти сравнение длины, выполняемое выделенной строкой кода. Слева в сравнении bloblen должен принять значение, которое после добавления 4 будет меньше pktlen. Хотя bloblen знаковый, для левой части этого сравнения он преобразуется в беззнаковый integer. Это оставляет небольшой problem domain: от 0xFFFFFFFC до 0xFFFFFFFF (от -4 до -1). Справа в сравнении bloblen трактуется как знаковый, поэтому problem domain не меняется. Чтобы определить, уязвима ли эта функция, нужно посмотреть, как она вызывается; это показано в листинге 7-10.

Примечание

Обсуждение листинга 7-9 предполагает, что вызов alloc() уязвим к integer wrapping condition. В реальном приложении вы бы проанализировали alloc() и определили, так ли это, но такое предположение разумно. Пользовательские обертки выделения памяти часто подвержены множеству арифметических проблем, как обсуждается далее в этой главе в разделе "Аудит управления памятью".

Листинг 7-10. Пример арифметической уязвимости в родительской функции

В листинге 7-10 есть два вызова read_blob(). Когда type равен TYPE_KEY, переменная length проверяется относительно RSA_KEY_SIZE, и функция возвращает ошибку, если значение не совпадает. Это означает, что validated domain содержит только одно значение -- RSA_KEY_SIZE, -- и вряд ли пересекается с problem domain. Поэтому вызов read_blob() в этом месте безопасен. Однако когда type равен TYPE_USER, таких ограничений нет. Следовательно, validated domain -- от 0x00000000 до 0xFFFFFFFF, и здесь есть пересечение. Все значения из problem domain входят в validated domain, поэтому можно уверенно сказать, что это сравнение можно обойти. Вот единственные имеющиеся ограничения:

• type == TYPE_USER

• length (из функции read_blob) + sizeof(long) меньше pktlen (поэтому, вероятно, нужно, чтобы pktlen был больше 4)

Путаница типов

Тип данных, производный от union, используется для хранения нескольких элементов данных в одном и том же месте памяти. Предполагаемая цель такого хранения состоит в том, что каждый из элементов данных взаимоисключающий, и одновременно может использоваться только один из них. Union-типы данных чаще всего используются, когда структуры или объекты должны представлять несколько типов данных в зависимости от внешнего условия, например разные непрозрачные объекты, прочитанные из сети. Иногда разработчики приложений путают, что именно представляют данные в union. Это может иметь катастрофические последствия для приложения, особенно когда целочисленные типы данных путаются с типами указателей или сложные структуры одного типа путаются с другим. Хотя такая ошибка кажется маловероятной, она проявлялась как минимум в одном широко развернутом приложении. Большинство уязвимостей такого рода возникает из-за неправильной интерпретации переменной, используемой для определения того, какой вид данных содержит структура. Листинг 7-11 показывает короткий пример.

Листинг 7-11. Путаница типов

Листинг 7-11 показывает интерфейс для чтения объектов некоторого вида из сети. Обратите внимание на небольшие различия между тем, как объекты инициализируются и как они очищаются. Переменная type -- 32-битный integer, прочитанный из сети, однако при инициализации объекта проверяются только младшие 8 бит. При очистке объекта проверяются все 32 бита. Поэтому если предоставляется 32-битный integer type, у которого младшие биты равны OBJ_NUM, а старшие биты не все установлены в ноль, контролируемый пользователем integer передается в функцию free_opaque() и трактуется как адрес памяти, что, скорее всего, приведет к вызову free() на произвольной области памяти.

Списки и таблицы

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

Связанные списки часто используются для хранения связанных элементов данных, которые позже нужно найти или изменить в программе. Связанные списки могут быть односвязными или двусвязными. Односвязные списки -- это списки, в которых элементы содержат указатель на следующий элемент списка; элементы двусвязных списков содержат указатели и на следующий, и на предыдущий элемент списка. Кроме того, связанные списки могут быть кольцевыми, то есть последний элемент списка ссылается обратно на первый; для двусвязных списков указатель previous первого элемента ссылается обратно на последний элемент.

При аудите кода, использующего связанные списки, нужно изучить, насколько хорошо алгоритм реализует список и как он работает с граничными условиями при доступе к элементам этих списков. Нужно рассмотреть каждый из следующих пунктов, обсуждаемых в следующих разделах:

• Корректно ли алгоритм работает с манипулированием элементами списка, когда список пуст?

• Каковы последствия дублирующихся элементов?

• Всегда ли корректно обновляются указатели previous и next?

• Корректно ли учитываются диапазоны данных?

Манипулирование элементами пустых списков

Часто члены структур списков или глобальные переменные используются для указания на голову списка и, возможно, на хвост списка. Если проверяющий код может найти случай, где эти переменные обновляются неправильно, появляется возможность обращаться к устаревшим элементам или неопределенным данным так, будто они являются частью списка. Например, рассмотрим код в листинге 7-12.

Листинг 7-12. Уязвимости пустого списка

В коде удаления из листинга 7-12 есть очевидное упущение: если удаляются элементы head или tail, это удаление не учитывается в функции delete_element(). Поскольку глобальные переменные head и tail не обновляются, первый или последний элемент может быть удален этой функцией, а затем к нему сможет обратиться любой код, манипулирующий указателями head или tail. Код, который неправильно работает с элементами head и tail, встречается нечасто, но такое возможно, особенно когда управление списком децентрализовано, то есть нет чистого интерфейса управления списком и управление происходит бессистемно в разных местах кода.

Некоторые реализации инициализируют список пустыми элементами head и/или tail, часто называемыми sentinel nodes (или sentinels). Sentinel nodes используются в основном для удобства, чтобы коду не приходилось специально обрабатывать случаи пустого списка, поскольку sentinel nodes всегда дают как минимум один элемент. Если пользователи могут добавлять элементы данных, которые выглядят для программы как sentinels, или заставлять sentinels удаляться, код управления списком может быть подвержен уязвимостям из-за неверной интерпретации того, где находится head или tail списка.

Дублирующиеся элементы

В зависимости от характера хранимых данных дублирующиеся элементы могут вызывать проблемы. Элементы, содержащие одинаковые ключи (значения данных, используемые для характеристики структуры как уникальной), могут быть перепутаны друг с другом, из-за чего из списка будет выбран неправильный элемент. Такая ошибка может иметь интересные последствия; например, сессии, уникально идентифицируемые cookie, могут быть перепутаны, если два или более клиента предоставят одинаковые cookies. Эта путаница может привести к некоторой утечке информации, повышению привилегий или другой компрометации.

Обновления указателей previous и next

Ошибки реализации при удалении и вставке элементов могут помешать корректному обновлению указателей previous и next. Это особенно справедливо, если программа рассматривает текущий элемент как head или tail списка. Листинг 7-13 показывает потенциальную проблему, возникающую при обновлении элементов списка.

Листинг 7-13. Ошибка обновления указателей списка

В коде листинга 7-13 есть небольшая ошибка при обновлении элементов head и tail. Если в списке существует только один элемент, и head, и tail указывают на него, однако в коде видно, что при проверке, является ли элемент head или tail, используется оператор else. Поэтому если в списке существует один элемент и он удаляется, head корректно обновляется в NULL, но tail указывает на устаревший элемент.

Диапазоны данных

В упорядоченных списках элементы отсортированы в некотором порядке на основе члена данных, отличающего каждый элемент списка. Часто каждый элемент данных в списке представляет диапазон значений, например часть IP datagram в очереди IP-фрагментов или диапазоны памяти в управляющих структурах ядра для процессов. Код, используемый для реализации этой, казалось бы, простой структуры данных, может быть довольно сложным, особенно когда нужно учитывать следующие нюансы данных:

• Можно ли предоставить перекрывающиеся диапазоны данных?

• Можно ли предоставить заменяющие диапазоны данных (дублирующиеся элементы)?

• Старые или новые данные имеют приоритет?

• Что происходит, когда предоставляются диапазоны данных нулевой длины?

Если эти детали обрабатываются неправильно, они могут привести к логическим ошибкам в обработке данных или несогласованностям в структурах данных списка. Наиболее вероятный результат такого недосмотра -- эксплуатируемое условие повреждения памяти. Листинг 7-14 -- код из ядра Linux, знаменитый баг teardrop. Он показывает, как перекрывающиеся диапазоны данных могут обрабатываться неправильно, приводя к уязвимости.

Листинг 7-14. Уязвимость Linux Teardrop

Этот код обрабатывает входящие IP-фрагменты, которые нужно поместить в очередь с другими фрагментами, являющимися частью одной IP datagram. Переменная offset представляет смещение в полной datagram, где начинается текущий фрагмент. Переменная end -- это смещение в полной datagram, где текущий фрагмент заканчивается; оно вычисляется добавлением начального смещения фрагмента и его длины. IP-код проходит по списку фрагментов и выходит из цикла, когда находит правильное место в списке для вставки входящего IP-фрагмента. Если между двумя фрагментами есть перекрытие, текущий фрагмент уменьшается так, чтобы в очередь добавлялись только еще не учтенные диапазоны данных, а перекрывающиеся данные отбрасывались. "Перекрытие" в этой ситуации означает, что два или более фрагмента частично или полностью предоставляют дублирующиеся диапазоны данных. Например, если один фрагмент предоставляет данные со смещения 10-30, а другой задает 20-40, они перекрываются, потому что оба фрагмента задают данные со смещения 20-30.

Уязвимость в этом коде возникает во время процесса уменьшения текущего фрагмента; код написан с предположением, что end больше или равен prev->end. Если это не так, offset инкрементируется и становится больше end. В результате переменная fp->len получает отрицательное значение, которое позже используется как аргумент memcpy(), приводя к переполнению буфера.

Алгоритмы хэширования

Хэш-таблицы -- еще одна популярная структура данных, обычно используемая для быстрого доступа к элементам данных. Хэш-таблица часто реализуется как массив связанных списков, поэтому предыдущее обсуждение управления списками также относится к хэш-таблицам. Хэш-таблицы используют элемент списка как вход для хэш-функции (хэш-функции обсуждаются в главе 2, "Анализ проектирования"). Получившееся хэш-значение используется как индекс в массиве. При работе с хэш-таблицами аудиторы кода должны рассмотреть следующие дополнительные вопросы:

• Может ли алгоритм хэширования давать недопустимые результаты? Большинство алгоритмов хэширования пытается гарантировать, что результат лежит в определенном диапазоне (размере массива), выполняя операцию и затем используя оператор modulus или and над результатом. Как обсуждалось в главе 6, один потенциальный вектор атаки -- заставить оператор modulus вернуть отрицательные результаты. Такой результат позволил бы отрицательное индексирование в массив, используемый для хранения элементов. Кроме того, проверяющие код должны оценить последствия ситуации, где на элементы данных можно влиять так, что возникает множество коллизий. Часто эта проблема замедляет поиск, что может быть серьезной проблемой, если приложение критично ко времени.

• Каковы последствия invalidating elements? Несколько алгоритмов, хранящих множество элементов данных, могут делать members недействительными на основе определенных условий, например timeout или достижения порогов памяти. Такое pruning иногда может иметь неожиданные последствия. Как и со списками, аудиторы кода должны определить, могут ли invalidated elements быть неправильно отвязаны от таблицы, из-за чего приложение потенциально будет позже использовать устаревшие элементы. Предсказуемое invalidating elements может иметь и другие интересные последствия, например заставить приложение с несколькими элементами session data удалить действительные сессии, что приведет к denial-of-service condition.

Аудит потока управления

Как вы узнали в главе 4, "Процесс анализа приложения", control flow относится к тому, как процессор выполняет определенную последовательность инструкций. В языках программирования есть несколько конструкций, позволяющих программистам переходить к разным путям кода на основе условия, повторять инструкции некоторое число итераций и вызывать подпрограммы (напрямую или косвенно). Эти конструкции являются базовыми строительными блоками языков программирования, и каждый разработчик с ними знаком. При аудите кода интересно видеть, что эти конструкции часто имеют похожие уязвимости безопасности не потому, что программисты не знают, как их реализовать, а потому, что приложение может попасть в специфический контекст, который неправильно учтен. В этом разделе рассматриваются конструкции циклов и операторов switch, управляющие внутренним потоком выполнения. Внешний поток управления рассматривается далее в этой главе в разделе "Аудит функций". Пока вы сосредоточитесь на том, как аудировать циклы и ветвления в стиле switch, и узнаете некоторые ориентиры того, на что смотреть при оценке их корректного использования.

Конструкции циклов

Конструкции циклов чрезвычайно распространены и используются в каждом компоненте обработки приложения: при инициализации структур, обработке ввода, взаимодействии с файловой системой или освобождении памяти. Этот раздел сосредоточен на циклах обработки данных, которые используются для интерпретации предоставленных пользователем данных и построения некоторой формы вывода на основе этих данных. Такой вывод может варьироваться от элементов, извлеченных из пользовательского ввода, до данных, производных от ввода. Циклы такого типа представляют самую непосредственную угрозу безопасности приложения.

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

• Условия завершения не учитывают размеры буфера назначения или в некоторых случаях учитывают размеры назначения неправильно.

• Цикл является posttest, хотя должен быть pretest.

• Оператор break или continue отсутствует или размещен неправильно.

• Неправильно поставленный знак пунктуации заставляет цикл делать не то, что он должен.

Любое из этих условий может иметь потенциально катастрофические последствия для безопасности приложения, особенно если цикл каким-либо образом выполняет записи в память. Как обсуждалось в главе 5, "Повреждение памяти", записи имеют наибольший шанс разрушительно повлиять на другие переменные или информацию о состоянии программы и, следовательно, привести к эксплуатируемой ситуации.

Условия завершения

Разработчикам приложений часто приходится строить циклы для обработки данных, которыми может управлять пользователь. Эти циклы должны разбирать и извлекать поля данных, искать вхождения определенных элементов данных или сохранять части данных в определенное назначение, например в другую область памяти или файл. Когда цикл выполняет копирование данных, необходимо проверить, выполняется ли копирование безопасно, то есть нет ли способа, при котором цикл может читать или писать за границами объектов, над которыми он работает. Обычно циклы, выполняющие такие копирования, имеют несколько условий завершения, то есть проверок, которые могут заставить цикл выйти. Цикл может иметь условие завершения, проверяющее успешное завершение копирования, а также несколько условий завершения, пытающихся учесть ошибочные условия, которые могут возникнуть во время обработки. Если набор условий завершения в цикле недостаточно учитывает все возможные ошибочные условия или реализация проверок некорректна, программа может быть уязвима к компрометации в той или иной форме. При работе с вычислениями длины могут возникнуть две основные проблемы:

• Циклы не учитывают размер буфера.

• Проверка размера выполняется, но она неверна.

Первая проблема довольно проста: проверка размера входных или выходных данных не выполняется, поэтому если злоумышленники могут предоставить больше данных, чем было выделено для буфера назначения, они могут вызвать условие переполнения буфера и скомпрометировать приложение. Листинг 7-15 показывает простой пример.

Листинг 7-15. Простой незавершающийся цикл переполнения буфера

Код в листинге 7-15 по сути выполняет ту же задачу, что и процедура strcpy(): он копирует данные из src в dst, пока не встретит NUL-байт. Такие циклы обычно довольно легко заметить при аудите кода, и они часто встречаются в крупных приложениях. Примечательный пример есть в RPC-интерфейсе Object Activation для Distributed Component Object Model (DCOM) в операционных системах Windows. В этом интерфейсе есть компактный цикл в функции GetMachineName(). Листинг 7-16 показывает приблизительный C-код на основе ассемблерного кода.

Листинг 7-16. Листинг переполнения буфера MS-RPC DCOM

Как видите, это переполнение буфера похоже на листинг 7-15 и выполняет потенциально опасное копирование. Однако иногда при чтении сложных функций с вложенными циклами такие подозрительные циклические конструкции бывает трудно заметить. Часто сложно проверить, действительно ли они представляют потенциальную уязвимость. Листинг 7-17 из NTPD, демона network time protocol (NTP), демонстрирует более сложный копирующий цикл.

Листинг 7-17. Пример переполнения буфера в NTPD

Код в листинге 7-17 обрабатывает control packet NTP. Он уязвим к переполнению буфера, поскольку буфер назначения, на который указывает tp, не проверяется на достаточность размера для хранения входных данных, предоставленных пользователями. В листинг включено много окружающего кода, чтобы показать, как сложный код иногда усложняет аудит. Возможно, вам придется сделать несколько проходов, прежде чем вы поймете, что делает предыдущая функция и может ли конструкция цикла while, которая сначала кажется уязвимой, быть достигнута со значениями, запускающими уязвимость.

Совет аудитору

Когда копирование данных в циклах выполняется без проверки размера, проверьте каждый путь выполнения, ведущий к опасному циклу, и определите, можно ли достичь его так, чтобы исходный буфер был больше буфера назначения.

Вторая проблема при работе с вычислениями длины, как упоминалось в начале этого раздела, -- неправильно выполненная проверка размера. В последние годы разработчики приложений стали осторожнее с конструкциями циклов, добавляя проверку длины как одно из условий завершения цикла. Однако иногда проверка реализуется неправильно, оставляя приложение уязвимым для компрометации.

Первая распространенная ошибка -- off-by-one (обсуждалась в главе 5). Эта уязвимость чаще всего возникает при обработке строк, как в следующем примере:

Технически цикл здесь не виноват. Он записывает данные в буфер назначения и не пишет за пределами буфера dst. Однако оператор сразу после него может записать один байт за конец массива. Это происходит, когда цикл завершается потому, что i равен размеру буфера назначения buf. В этом случае оператор dst[i] = '\0' становится эквивалентен dst[sizeof(dst)] = '\0', что записывает NUL на один байт за выделенное пространство buf. Этот баг часто связан с циклами такого рода.

Предыдущая уязвимость подводит к следующему интересному поведению, на которое нужно обращать внимание: иногда, когда циклы завершаются неожиданным образом, переменные могут оставаться в несогласованном состоянии. Важно определить, какие переменные находятся под влиянием конструкции цикла и оставляет ли какое-либо потенциальное условие выхода (обычно граничное условие, обозначающее ошибку некоторого рода) одну из этих переменных в несогласованном состоянии. Естественно, это определение релевантно только если переменные используются после завершения цикла. Листинг 7-18 показывает код из mod_php, который читает POST-данные от пользователей.

Листинг 7-18. Уязвимость незавершающегося буфера в Apache mod_php

Ожидается, что функция sapi_read_standard_form_data заполнит глобальный буфер post_data и поместит NUL-байт в конец буфера. Однако в одном случае она этого не делает: если предоставлено больше данных, чем post_max_size, генерируется предупреждение и функция возвращается. Поскольку эта функция имеет тип void и не возвращает значение, вызывающий код не знает, что произошла ошибка, и продолжает обработку, ничего не подозревая.

Обратите внимание, что в некоторых обстоятельствах функция php_error_docref() может заставить процесс завершиться, в зависимости от второго аргумента; однако в этом случае функция просто генерирует предупреждение. В обычных обстоятельствах такой баг создавал бы потенциальные возможности эксплуатации, заставляя указатель инкрементироваться за пределы переменной post_data. Однако в этом случае allocator не позволяет предоставить post_max_size (8 MB) байтов в запросе, потому что существует лимит памяти 8 MB на запрос, хотя и максимальный лимит данных для выделения памяти, и post_max_size могут быть настроены.

Совет аудитору

Отмечайте все условия выхода из цикла, а также все переменные, которыми манипулирует цикл. Определите, существуют ли условия, при которых переменные остаются в несогласованном состоянии. Обращайте внимание на места, где цикл завершается из-за неожиданной ошибки, поскольку такие ситуации с большей вероятностью оставляют переменные в несогласованном состоянии.

Еще одна off-by-one ошибка возникает, когда переменная неправильно проверяется на попадание в определенные границы до того, как она инкрементируется и используется. Листинг 7-19, код из модуля Apache mod_rewrite, демонстрирует эту ошибку.

Листинг 7-19. Off-by-one уязвимость Apache 1.3.29/2.X mod_rewrite

Как видите, переменная c используется, чтобы гарантировать, что в массиве указателей token хранится только пять указателей. Однако после выполнения проверки размера переменная c инкрементируется и используется, а значит проверка должна читаться как (*cp && c < 4). Если атакующий предоставляет входные данные для цикла так, что c равно четырем, вход проходит проверку длины, но заставляет программу записать указатель в token[5], что находится за пределами выделенного пространства для token. Эта ошибка может привести к эксплуатируемому условию, потому что атакующий записывает указатель на контролируемые пользователем данные за пределы переменной token.

Циклы, которые могут записывать несколько элементов данных за одну итерацию, также могут быть уязвимы к неправильным проверкам размера. В прошлом несколько уязвимостей возникали из-за экранирования или расширения символов, которые не были достаточно учтены проверкой размера в цикле. Нидерландский исследователь Scrippie нашел примечательный баг в OpenBSD 2.8. Код в листинге 7-20, взятый из ftp-демона OpenBSD 2.8, копирует данные в буфер назначения, экранируя символы двойной кавычки (") по мере их встречи.

Листинг 7-20. Off-by-one уязвимость OpenBSD ftp

Проблема в листинге 7-20 состоит в том, что переменная i может быть инкрементирована дважды за одну итерацию цикла. Поэтому если символ двойной кавычки встречается в исходной строке в позиции (sizeof(npath)-2), i инкрементируется дважды и получает значение (sizeof(npath)), а оператор сразу после цикла записывает нулевой байт за пределами буфера. Этот код в итоге оказался эксплуатируемой off-by-one уязвимостью.

Наконец, проверка размера цикла может быть недействительной из-за преобразования типов, арифметического граничного условия, неправильного использования оператора или ошибки арифметики указателей. Эти вопросы обсуждались в главе 6.

Posttest-циклы и pretest-циклы

При написании программных циклов разработчики могут решать, использовать ли posttest или pretest управляющую структуру. Posttest-цикл проверяет условие завершения цикла в конце каждой итерации; pretest-цикл проверяет условие перед каждой итерацией. В C posttest- и pretest-циклы легко различить: posttest-цикл использует конструкцию do {...} while(), а pretest-циклы используют for( ;; ) {...} или while() {...}. Pretest-циклы обычно используются чаще; posttest-циклы применяются в некоторых ситуациях по необходимости или из личных предпочтений. При встрече с циклами аудиторы кода должны определить последствия выбора разработчиком формы цикла и то, может ли этот выбор иметь негативные последствия для кода.

Posttest-циклы следует использовать, когда тело цикла всегда должно быть выполнено хотя бы один раз. Как аудитор, вы должны искать потенциальные ситуации, где выполнение тела цикла может привести к неожиданному условию. Один момент, на который стоит обращать внимание, -- условная форма цикла выполняет sanity check, который следовало бы выполнить до входа в цикл. Рассмотрим пример в листинге 7-21, где posttest-цикл используется для простой обработки строки.

Листинг 7-21. Уязвимость postincrement-цикла

В этом коде, если предоставленные данные являются пустой строкой (строкой, содержащей только NUL-символ), указатель cp инкрементируется за предполагаемые границы строки. Цикл продолжает обрабатывать неопределенные данные, потенциально приводя к повреждению памяти или какой-либо уязвимости утечки информации. Программист должен был проверить, указывает ли cp на NUL-символ, до входа в цикл, поэтому этот цикл следовало записать в pretest-форме.

Аналогично, программист может использовать pretest-цикл, когда posttest-формат был бы более уместен, и вследствие этого создать эксплуатируемую ситуацию. Если код после цикла ожидает, что тело цикла было выполнено хотя бы один раз, атакующий может намеренно полностью пропустить цикл и создать эксплуатируемое условие. Рассмотрим код в листинге 7-22.

Листинг 7-22. Уязвимость pretest-цикла

В этом примере код после цикла предполагает, что массив token_array был выделен, что может произойти только если цикл выполнится хотя бы один раз. Если первый вызов parse_element() возвращает NULL, входа в цикл не происходит, token_array никогда не выделяется, и выделенный код вызывает разыменование NULL-указателя, что приводит к потенциальному падению.

Ошибки пунктуации

Как обсуждалось в главе 6, типографические ошибки могут приводить к ситуациям с последствиями для безопасности. Иногда разработчики ошибочно вставляют лишние знаки пунктуации языка там, где их быть не должно, и такая ошибка часто приводит к тому, что цикл делает не то, что предполагалось. Рассмотрим простой пример:

Цикл for в этом коде должен копировать данные в массив dest; однако программист допустил небольшую ошибку: точку с запятой в конце строки с циклом for. Поэтому цикл на самом деле ничего не копирует, а то, что должно было быть телом цикла, всегда выполняется один раз после того, как счетчик инкрементирован за границы массива. Эта ошибка означает, что потенциально можно записать байт в dest[sizeof(dest)], что будет на один байт за пределами.

Естественно, такие ошибки не слишком распространены, потому что они обычно ломают функциональность программы и, следовательно, обнаруживаются во время тестирования или разработки. Простое тестирование кода из предыдущего примера, вероятно, показало бы программисту, что любая последующая обработка dest имеет проблему, потому что цикл не копирует данные в dest, как должен. Однако такие ошибки время от времени возникают так, что не влияют на функциональность программы, или появляются в коде обработки ошибок или отладки, который не тестировался. Как обсуждалось в главе 6, проверяющие всегда должны быть внимательны к таким небольшим ошибкам пунктуации.

Операторы передачи потока управления

Языки программирования обычно предоставляют операторы потока управления, которые разработчики могут использовать для перенаправления выполнения очень прямыми способами. У циклов обычно есть механизм, с помощью которого программист может немедленно завершить цикл или перейти к следующей итерации цикла. Операторы в стиле switch имеют ключевые слова для обозначения тела case и механизм выхода из тела case. Некоторые языки предоставляют операторы в стиле goto и longjmp, которые могут позволять произвольные передачи потока управления внутри функции или через границы функций.

Иногда разработчики приложений неправильно используют эти операторы потока управления способами, которые могут иметь последствия для безопасности, потому что эти ключевые слова часто перегружены. В C оператор break используется для выхода из оператора switch и для завершения цикла. Двойное использование этого оператора может приводить к нескольким потенциальным ошибкам. Разработчики приложений могут предположить, что оператор break может выйти из любого вложенного блока, и использовать его в неправильном месте. Или они могут предположить, что оператор выходит из всех окружающих циклов, а не только из самого ближайшего цикла. Еще одна проблема -- использование оператора continue внутри оператора switch для перезапуска сравнения switch. Опытные программисты не стали бы сознательно совершать такие ошибки, но они могут оставаться в коде, если вызваны, например, случайными ошибками редактирования и не проявляются сразу при использовании приложения. Однако чтобы такие ошибки остались в коде, они должны выглядеть достаточно правильно, чтобы беглый просмотр не поднял тревогу.

Уязвимость такого рода привела к широко освещенному сбою телефонной сети AT&T в 1990 году. Программист ошибочно использовал оператор break, чтобы выйти из блока кода if, вложенного в оператор switch. В результате был непреднамеренно прерван весь блок switch.

Операторы switch

При работе с подозрительным потоком управления операторы switch имеют несколько уникальных особенностей. Распространенная ловушка, в которую попадают разработчики при использовании операторов switch, -- забыть оператор break в конце каждой ветви case. Эта ошибка может привести к непреднамеренному выполнению кода, когда выполняется ошибочная ветвь case. Рассмотрим листинг 7-23.

Листинг 7-23. Уязвимость из-за пропущенного оператора break

Этот код допускает ошибку при работе с символом новой строки ('\n'). Оператор break отсутствует, поэтому каждый символ новой строки приводит к записи пробела в буфер назначения, за которым следует символ новой строки. Это происходит потому, что ветвь default выполняется каждый раз, когда выполняется ветвь '\n'. В результате код записывает в выходной буфер больше символов, чем ожидалось.

Примечание

В некоторых обстоятельствах программисты намеренно опускают оператор break и часто оставляют комментарий, например /* FALLTHROUGH */, показывающий, что отсутствие break намеренное.

При анализе кода, содержащего операторы switch, аудиторы также должны определить, нет ли неучтенных case. Иногда операторы switch без default case могут фактически не выполнять ничего, когда нет выражения case, соответствующего результату выражения в операторе switch. Такая ошибка часто является недосмотром разработчика и может приводить к непредсказуемым или нежелательным результатам. Листинг 7-24 показывает пример.

Листинг 7-24. Уязвимость из-за отсутствия default-ветви switch

Листинг 7-24 инициализирует объект на основе предоставленной переменной type. Функция init_object() предполагает, что предоставленная переменная type равна OBJ_STR, OBJ_INT или OBJ_BOOL. Если злоумышленники могут предоставить значение, не являющееся одним из этих трех значений, эта функция не инициализирует выделенную структуру объекта корректно, а значит неинициализированная память позже в программе может быть обработана как указатели.

Аудит функций

Функции -- повсеместный компонент современных программ, независимо от проблемной области приложения или языка программирования. Программисты обычно делят программы на функции, чтобы инкапсулировать функциональность, которую можно повторно использовать в других местах программы, и организовать программу в более мелкие части, которые легче осмыслить и контролировать. Объектно-ориентированные языки программирования поощряют создание member functions, организованных вокруг объектов. Как аудитор кода, когда вы встречаете вызов функции, важно осознавать последствия этого вызова. Спросите себя: какое состояние программы меняется из-за этого вызова? Что может пойти не так с этой функцией? Какую роль играют аргументы в том, как работает функция? Естественно, нужно сосредоточиться на аргументах и аспектах функции, на которые пользователи могут каким-либо образом влиять. Чтобы формализовать этот процесс, ищите четыре основных типа шаблонов уязвимостей, которые могут возникать при вызове функции:

• Возвращаемые значения неверно интерпретируются или игнорируются.

• Предоставленные аргументы каким-либо образом имеют неправильный формат.

• Аргументы обновляются неожиданным образом.

• Из-за вызова функции происходит неожиданное изменение глобального состояния программы.

Следующие разделы рассматривают эти шаблоны и объясняют, почему они потенциально опасны.

Журналы аудита функций

Поскольку функции являются естественным механизмом, с помощью которого программисты делят программы на более мелкие и управляемые части, они дают аудиторам кода отличный способ разделить анализ на управляемые части. Этот раздел описывает создание журнала аудита, где можно хранить заметки о местах программы, которые могут пригодиться при последующем анализе. Такой журнал организован вокруг функций и должен содержать заметки о назначении каждой функции и ее side effects. Многие аудиторы кода используют неформальный процесс ведения таких заметок, а пример журнала аудита в этом разделе синтезирует несколько таких неформальных подходов.

Для начала перечислите базовые компоненты записи, как показано в таблице 7-1, а затем можно расширять журнал по мере обсуждения уязвимостей, связанных с взаимодействием функций.

Таблица 7-1. Пример журнала аудита

Хотя пока не нужно понимать весь журнал целиком, ниже приведено краткое резюме каждой строки, к которому можно легко возвращаться:

• Имя функции. Полный прототип функции.

• Описание. Краткое описание того, что делает функция.

• Расположение. Место определения функции (файл и номер строки).

• Перекрестные ссылки. Места, которые вызывают это определение функции (файлы и номера строк).

• Тип возвращаемого значения. Возвращаемый C-тип.

• Смысл возвращаемого значения. Набор типов возврата и смысл, который они передают.

• Условия ошибки. Условия, которые могут заставить функцию вернуть ошибочные значения.

• Ошибочные возвращаемые значения. Возвращаемые значения, которые неточно представляют результат функции, например отсутствие возврата значения ошибки при возникновении условия отказа.

Проверка и интерпретация возвращаемых значений

Игнорируемые или неверно интерпретируемые возвращаемые значения являются причиной многих тонких уязвимостей в приложениях. По сути, каждая функция в приложении -- это обособленный фрагмент кода, предназначенный для выполнения одной конкретной задачи. Поскольку она делает это в стиле "черного ящика", детали результатов ее операций в значительной степени невидимы вызывающим функциям. Возвращаемые значения используются, чтобы сообщать вызывающим функциям некоторый статус. Часто этот статус обозначает успех или отказ либо предоставляет значение, являющееся результатом задачи функции: выделенную область памяти, integer-результат математической операции или просто Boolean true/false, показывающий, разрешена ли конкретная операция. В любом случае возвращаемое значение играет важную роль в вызове функции, поскольку передает некоторый результат между двумя отдельными функциональными компонентами. Если возвращаемое значение неверно интерпретируется или просто игнорируется, программа в результате может пойти по неправильным путям выполнения, что может иметь серьезные последствия для безопасности. Как видите, значительная часть информации в журнале аудита связана со смыслом возвращаемого значения и тем, как оно интерпретируется. Следующие разделы рассматривают процесс, через который должен пройти аудитор кода при анализе вызовов функций, чтобы определить, может ли возникнуть неправильная коммуникация между двумя компонентами и может ли эта неправильная коммуникация повлиять на общую безопасность программы.

Игнорирование возвращаемых значений

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

Довольно часто функция malloc() не проверяется на успех или отказ, как в предыдущем коде; разработчик предполагает, что она успешно выполнится. Очевидное следствие в этом примере -- приложение упадет, если malloc() можно заставить завершиться неудачно, поскольку отказ установит buf в NULL, а memcpy() вызовет разыменование NULL-указателя. Аналогично, программисты нередко не проверяют возвращаемое значение realloc(), как показано в листинге 7-25.

Листинг 7-25. Игнорирование возвращаемого значения realloc()

Как видите, элемент buf->data может быть перевыделен, но возвращаемое значение realloc() никогда не проверяется на отказ. Когда затем выполняется memcpy(), существует шанс эксплуатируемого повреждения памяти. Почему? В отличие от предыдущего примера с malloc(), этот код копирует по смещению от выделенного буфера. Если realloc() завершается неудачно, buf->data равен NULL, но добавленное к нему значение buf->used может быть достаточно большим, чтобы достичь действительной записываемой страницы памяти.

Игнорирование более тонких отказов, которые не вызывают немедленного падения, может приводить к гораздо более серьезным последствиям. Пол Старзец, опытный исследователь, обнаружил идеальный пример тонкого отказа в коде управления памятью ядра Linux. Код do_mremap() показан в листинге 7-26.

Листинг 7-26. Уязвимость Linux do_mremap()

Уязвимость в этом коде состоит в том, что функцию do_munmap() можно заставить завершиться неудачно. Несколько условий могут вызвать отказ; самое простое -- исчерпание максимальных resource limits при разделении существующей области виртуальной памяти. Если функция do_munmap() завершается неудачно, она возвращает код ошибки, который do_mremap() полностью игнорирует. Результат игнорирования этого возвращаемого значения состоит в том, что структуры virtual memory area (VMA), используемые для представления диапазонов страниц процессов, можно сделать несогласованными: page table entries могут перекрываться в двух VMA или появятся полностью неучтенные VMA. Через новый метод эксплуатации с использованием системы page-caching произвольные страницы могли быть ошибочно отображены в другие процессы, приводя к повышению привилегий. Дополнительная информация об этой уязвимости доступна по адресу www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt.

В общем случае, если вызов функции возвращает значение, в отличие от функции, которая ничего не возвращает (например, void-функции), за каждым вызовом функции должен следовать условный оператор, проверяющий успех или отказ. Заметные исключения -- случаи, где функция завершает приложение через вызов exit routine или ошибки обрабатываются механизмом исключений в отдельном блоке кода. Если проверка успеха или отказа функции не выполняется, аудитор кода должен отметить место, где значение остается непроверенным.

Продвигая это исследование на шаг дальше, аудитор может затем спросить, каковы последствия игнорирования этого возвращаемого значения. Ответ зависит от того, что именно может пойти не так в функции. Лучший способ точно выяснить, что может пойти не так, -- изучить целевую функцию и найти каждую точку, где функция может вернуть управление. Обычно существует несколько условий ошибки, заставляющих функцию вернуться, а также один возврат при успешном завершении ее задачи. Самые интересные случаи для анализа, естественно, те, где ошибки действительно возникают. После выявления всех способов, которыми функция может вернуться, у аудитора есть список возможных условий ошибки, которые могут незаметно уйти в приложение. После составления этого списка любые условия, которые пользователи не могут вызвать, можно классифицировать как более низкий риск, а аудиторы могут сосредоточиться на условиях, которые пользователи могут вызвать, даже косвенно, например отказ выделения памяти. Листинг 7-27 дает возможность применить этот процесс исследования к простому блоку кода.

Листинг 7-27. Поиск возвращаемых значений

Предположим, вы заметили случай, где вызывающий код не проверяет возвращаемое значение этой функции, и решили исследовать, что может пойти не так. Функция может вернуться тремя разными способами: если вызов calloc() завершается неудачно, если вызов read() завершается неудачно или если функция успешно возвращается. Очевидно, наиболее интересные случаи -- два условия ошибки, которые следует отметить в журнале аудита. Условие ошибки возникает, когда вызов calloc() завершается неудачно, потому что память процесса исчерпана. Заставить программу исчерпать память непросто, но это, безусловно, возможно и заслуживает рассмотрения. Условие ошибки также может возникнуть, когда read() возвращает ошибку или ноль, обозначая, что поток закрыт; это, вероятно, довольно легко вызвать. Последствия игнорирования возвращаемого значения этой функции зависят от операций после вызова функции в вызывающей процедуре, но можно сразу вывести, что они, вероятно, довольно серьезны. Откуда это известно? Аргументы buffer и length никогда не инициализируются, если функция завершается неудачно, поэтому если вызывающий код не проверяет отказ, он, скорее всего, продолжит обработку, предполагая, что буфер содержит указатель на некоторую действительную область памяти с байтами для обработки. Листинг 7-28 показывает пример того, как может выглядеть вызывающая функция такого типа.

Листинг 7-28. Игнорирование возвращаемых значений

Код написан с предположением, что read_data() успешно вернулась, и передает то, что должно быть символьным буфером и количеством байтов в нем, функции get_token(), предположительно чтобы получить ключевое слово из буфера запроса и определить тип выполняемого запроса. Поскольку read_data() не проверяется на успех, оказывается, что в get_token() могут быть переданы две неинициализированные стековые переменные: request, которая должна указывать на некоторую выделенную память, и len, которая должна обозначать количество байтов, прочитанных из сети в request. Хотя точные последствия этой ошибки зависят от того, как работает get_token(), из обсуждения ранее в этой главе вы знаете, что обработка неинициализированных переменных может иметь серьезные последствия, поэтому игнорирование возвращаемого значения read_data(), вероятно, имеет серьезные следствия. Эти следствия варьируются от лучшего сценария, где приложение просто падает, до худшего сценария, где память повреждается эксплуатируемым образом. Обращайте пристальное внимание на то, как небольшие различия в вызывающем коде могут влиять на значимость этих ошибок. Например, рассмотрим слегка измененную вызывающую функцию:

Здесь та же функция с одним ключевым отличием: стековые переменные, переданные в read_data(), инициализированы нулем. Это небольшое изменение кода резко влияет на серьезность игнорирования возвращаемого значения read_data(). Теперь худшее, что может произойти, -- программу можно заставить неожиданно упасть; это нежелательно, но далеко не так серьезно, как повреждение памяти, возможное в исходной версии функции. Тем не менее при оценке воздействия возвращаемых значений лучше ошибаться в сторону осторожности, поскольку падение приложения может быть не концом истории. В приложении могут быть signal handlers или exception handlers, которые выполняют некоторое обслуживание программы перед завершением процесса, и они могут предоставить некоторую возможность эксплуатации, хотя, вероятно, не в этом примере.

Неверная интерпретация возвращаемых значений

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

Такой тип ошибки программиста может казаться маловероятным или редким, но он довольно часто встречается в production-коде, особенно когда команда программистов разрабатывает приложение и использует сторонний код и библиотеки. Часто разработчики могут не полностью понимать корректное использование внешнего кода, внешний код может измениться в процессе разработки, или спецификации и документация для внешнего кода могут быть неправильными. Программисты также могут неправильно использовать хорошо известные API, например runtime library языка, из-за недостаточного знакомства или простой небрежности. Чтобы понять этот момент, рассмотрим следующий код:

Этот код содержит простую ошибку. На UNIX-машинах функция snprintf() обычно возвращает количество байтов, которое она записала бы в назначение, если бы места было достаточно. Поэтому первый вызов snprintf() может вернуть значение больше sizeof(buf), если переменная username очень длинная. В результате переменная ptr инкрементируется за пределы буфера, а второй вызов snprintf() может повредить память из-за integer overflow в макросе SIZE. Следовательно, пароль, записываемый в буфер, может быть произвольно большим.

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

1. Определите предполагаемый смысл возвращаемого значения функции. Когда код хорошо прокомментирован или документирован, аудитор может иметь хорошее представление о его смысле еще до просмотра кода; однако все равно важно проверить, действительно ли функция возвращает то, что утверждает документация.

2. Посмотрите каждое место в приложении, где вызывается функция, и проверьте, что оно делает с возвращаемым значением. Согласуется ли это с предполагаемым смыслом этого возвращаемого значения?

Первый шаг поднимает интересный момент: иногда вина за неверно интерпретированное возвращаемое значение лежит не на вызывающей функции, а на вызываемой функции. То есть иногда функция возвращает значение, выходящее за пределы документированного или заданного диапазона ожидаемых возвращаемых значений, или значение находится в диапазоне допустимых, но неверно для обстоятельств. Такая ошибка обычно вызвана небольшим недосмотром со стороны разработчика приложения, но последствия могут быть весьма серьезными. Например, рассмотрим листинг 7-29.

Листинг 7-29. Неожиданные возвращаемые значения

Предположим, что функция authenticate() в листинге 7-29 должна возвращать 1 для обозначения успеха или 0 для обозначения отказа. Однако можно видеть, что была допущена ошибка, потому что отказ может заставить функцию вернуть -1 вместо 0. Из-за способа проверки возвращаемого значения -- проверкой на ноль или неноль -- этот небольшой логический дефект может позволить пользователям войти в систему, даже если их учетные данные полностью недействительны. Однако эта программа не была бы уязвима, если бы проверка возвращаемого значения специально проверяла значение 1, как в этом примере:

Ненулевые значения представляют true в boolean-сравнении, поэтому легко понять, как может возникнуть такое недопонимание. Чтобы заметить эти ошибки, аудиторы могут использовать процесс, похожий на процесс выявления последствий игнорируемых возвращаемых значений:

1. Определите все точки функции, где она может вернуть управление. Обычно есть несколько точек возврата из-за ошибок и одна точка, где функция возвращается после успешного завершения.

2. Изучите возвращаемое значение. Находится ли оно в диапазоне ожидаемых возвращаемых значений? Подходит ли оно для обозначения условия, из-за которого функция вернулась?

Если вы находите место, где из функции возвращается неправильное значение, следует отметить его расположение, а затем оценить значимость на основе того, как возвращаемое значение интерпретируется в каждом месте вызова функции. Поскольку этот процесс очень похож на определение последствий игнорирования возвращаемого значения текущей функции, обе задачи можно и нужно объединять в один процесс для экономии времени. Например, предположим, что вы аудируете следующую функцию:

Журналы аудита функций, представленные ранее в этой главе, дают идеальный способ зафиксировать всю важную информацию о возвращаемых значениях функции read_data(), показанной здесь. Таблица 7-2 демонстрирует строки журнала аудита для этой функции, которые включают всю релевантную информацию об ожидаемых возвращаемых значениях этой функции.

Таблица 7-2. Возвращаемые значения из примера журнала аудита

Последствия неправильных возвращаемых значений или игнорирования возвращаемых значений вызывающей функцией не указаны в таблице, поскольку эти последствия зависят от вызывающей функции. Аудиторы могут отслеживать эту информацию в заметках, которые они ведут о функциях process_request() и process_login(). Ведение журнала для каждой функции в большом приложении было бы довольно утомительным, не говоря уже о затратах времени, поэтому можно отказаться от записи этой информации исходя из двух требований: функция никогда не вызывается в контексте, на который влияют пользователи, являющиеся потенциальными атакующими, например utility functions для конфигурационного файла; или функция настолько мала и проста, что легко запомнить, как она работает.

Ведение таких журналов может казаться чрезмерным, потому что после чтения кода вы знаете всю информацию, необходимую для аудита использования функции; однако есть две веские причины записывать эту информацию:

• Приложения могут быть сколь угодно сложными, и функции могут вызываться в сотнях разных мест, каждое с немного отличающимся набором обстоятельств.

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

Второй способ неверной интерпретации возвращаемых значений функций -- преобразование типов, которое меняет смысл возвращаемого значения. Эта неверная интерпретация является расширением первого вида неверной интерпретации: вызывающая функция просто неправильно понимает смысл значения. Вы уже изучили вопросы преобразования типов в главе 6, поэтому возвращаться к ним не нужно. Однако помните: когда возвращаемое значение проверяется и отбрасывается или сохраняется в переменной для последующего использования, важно определить преобразования типов, происходящие при каждом последующем использовании значения. Когда возвращаемое значение проверяется и отбрасывается, нужно учитывать правила преобразования типов, чтобы убедиться, что значение интерпретируется как задумано. Когда возвращаемое значение сохраняется, нужно изучить тип переменной, в которой оно сохраняется, чтобы убедиться, что он согласуется с типом возвращаемого значения функции.

Журнал возвращаемых значений, показанный в таблице 7-2, может помочь обнаружить уязвимости, связанные с преобразованиями типов возвращаемых значений. В частности, строки Return type и Return value meaning служат кратким резюме того, как предполагается использовать возвращаемое значение. Поэтому если происходит преобразование типов, можно быстро увидеть, могут ли части смысла возвращаемого значения быть потеряны или неверно интерпретированы преобразованием типов, например отрицательные значения.

Побочные эффекты функций

Побочные эффекты возникают, когда функция изменяет состояние программы помимо любых значений, которые она возвращает. Функция, которая не создает побочных эффектов, считается referentially transparent, то есть вызов функции можно напрямую заменить возвращаемым значением. Напротив, функция, вызывающая побочные эффекты, считается referentially opaque. Побочные эффекты функций являются важной частью большинства языков программирования. Они позволяют программисту изменять элементы состояния программы или возвращать дополнительные фрагменты данных сверх того, что может содержать возвращаемое значение. В этом разделе вы изучите воздействие двух очень конкретных побочных эффектов функций: манипулирование аргументами, переданными по ссылке (value-result arguments), и манипулирование переменными глобальной области видимости.

Уязвимости, возникающие из-за манипулирования pass-by-reference аргументами, могут появиться потому, что автор вызывающей функции не учитывает возможность изменения аргументов или потому, что функцию можно заставить манипулировать аргументами неожиданным или несогласованным образом. Одна из более распространенных ситуаций, где может возникнуть этот баг, -- использование realloc() для изменения размера буфера, переданного как аргумент-указатель. Уязвимость обычно возникает по одной из двух причин: вызывающая функция имеет указатель, который не был обновлен после вызова realloc(), или новый размер выделения неверен из-за ошибки вычисления длины. Листинг 7-30 показывает пример функции, которая перевыделяет буфер, переданный по ссылке, в результате чего вызывающая функция ссылается на устаревший указатель.

Листинг 7-30. Уязвимость устаревшего указателя

Функция process_token_string() читает пять токенов, разделенных символом двоеточия, которые могут расширяться на несколько строк. Во время обработки токена вызывается функция read_line(), чтобы получить еще одну строку данных из сети. Эта функция затем вызывает buffer_append(), которая перевыделяет буфер, когда места для новой прочитанной строки недостаточно. Проблема в том, что при перевыделении функция process_token_string() может остаться с двумя устаревшими указателями, которые ссылались на исходный буфер: tokstart и tokend. Затем оба этих устаревших указателя используются, что приводит к повреждению памяти.

Как видите, такие баги устаревших указателей обычно распределены между несколькими функциями, что делает их намного труднее для поиска. Поэтому полезно еще немного попрактиковаться в выявлении путей кода, уязвимых к таким проблемам. Листинг 7-31 показывает еще один пример использования устаревшего указателя из-за перевыделения буфера, на этот раз из ProFTPD 1.2.7 through 1.2.9rc2.

Листинг 7-31. Использование устаревшего указателя в ProFTPD

Функция _xlate_ascii_write() проверяет, сколько символов новой строки есть в передаваемом файле. В ASCII-режимах FTP каждой новой строке должен предшествовать carriage return, поэтому разработчики программы хотят выделить буфер, достаточно большой для этих дополнительных carriage returns, чтобы компенсировать ASCII file transfers. Перевыделяемый буфер -- это буфер назначения, первый аргумент функции _xlate_ascii_write(). Если происходит перевыделение, буфер назначения обновляется, как показано в следующем коде:

Предыдущий код сам по себе нормален, но посмотрите на код, который вызывает _xlate_ascii_write():

Функция data_xfer() имеет цикл для передачи определенного объема данных в каждой итерации. Однако каждая итерация цикла сбрасывает входной буфер на исходный session.xfer.buf, который мог быть перевыделен в _xlate_ascii_write(). Кроме того, session.xfer.bufsize передается как длина буфера, и _xlate_ascii_write() тоже могла обновить это значение. В результате, если _xlate_ascii_write() когда-либо перевыделяет буфер, все последующие итерации цикла используют устаревший указатель с недействительным размером.

Предыдущие примеры были сосредоточены на перевыделении блоков памяти. За последние несколько лет похожие ошибки были обнаружены во многих приложениях. Иногда возникают уникальные ситуации, которые менее очевидны. Код в листинге 7-32 взят из функции prescan() в Sendmail. Уязвимость связана с обновлением аргумента prescan() (аргумента delimptr) так, что он указывает на недействительные данные, когда определенные условия ошибки заставляют функцию неожиданно завершиться во время вложенного цикла. Эта уязвимость вращается вокруг переменной p, которая инкрементируется по мере того, как функция prescan() читает символ.

Листинг 7-32. Уязвимость обновления возвращаемого значения в Sendmail

Когда встречается конец строки, выполняется оператор break, и внутренний цикл прерывается. Затем токен записывается в выходной список токенов avp, как показано в следующем коде:

Если встречается условие ошибки (токен слишком длинный или токенов больше MAXATOM), ошибка обозначается, и функция возвращается. Однако аргумент delimptr обновляется так, что указывает за пределы предоставленной строки, как показано в этом коде:

Когда срабатывают показанные ранее условия ошибки, переменная p указывает на один байт после места, где был встречен NUL-байт, и delimptr вследствие этого обновляется так, что указывает на неинициализированные стековые данные. Затем переменная p используется, что создает возможность эксплуатации.

При анализе приложения аудиторы кода должны отмечать функции, важные для безопасности, которые манипулируют pass-by-reference аргументами, а также конкретный способ, которым они выполняют эту манипуляцию. Такие манипуляции аргументами часто используют opaque pointers со связанным набором функций манипулирования. Этот тип манипуляции также является неотъемлемой частью классов C++, поскольку они неявно передают ссылку на указатель this. Однако C++ member functions могут быть труднее для анализа из-за количества неявных функций, которые могут вызываться, и из-за того, что пути выполнения не следуют более прямой процедурной структуре. Независимо от языка, лучший способ определить риск pass-by-reference манипуляции -- следовать простому процессу:

1. Найдите все места в функции, где pass-by-reference аргументы изменяются, особенно аргументы-структуры, такие как структура буфера в листинге 7-25.

2. Различайте обязательное и необязательное изменение. Обязательное изменение происходит каждый раз, когда вызывается функция; необязательное изменение происходит при возникновении ненормальной ситуации. Программисты чаще пропускают исключительные условия, связанные с необязательным изменением.

3. Изучите, как вызывающие функции используют измененные аргументы после возврата функции.

Кроме того, отмечайте случаи, когда аргументы не обновляются, хотя должны. Вспомните функцию read_line(), которая использовалась для иллюстрации проверки возвращаемых значений (см. листинг 7-30). Когда функция выделения данных или чтения завершалась неудачно, аргументы, которые предполагалось обновлять каждый раз, не обновлялись. Также внимательно следите за тем, что происходит, когда функции возвращаются раньше из-за некоторой ошибки: не остаются ли по какой-либо причине необновленными аргументы, которые должны быть обновлены? Можно подумать, что если вызывающая функция корректно проверяет возвращаемые значения, отсутствие обновления аргументов не будет проблемой; однако в приложениях определенно есть случаи, когда аргументы должны обновляться даже при возникновении ошибок, как в примере Sendmail из листинга 7-32. Поэтому даже если ошибка может быть обнаружена правильно, программа все равно уязвима к неправильному использованию, потому что аргументы обновлены некорректно.

Чтобы помочь выявлять такие проблемы с манипуляцией аргументами, используйте журналы аудита функций для определения, где в функции изменяются pass-by-reference аргументы, и любых случаев, где pass-by-reference аргументы не изменяются. Затем изучите вызывающие функции, чтобы определить последствия (если они есть) этих обновлений или отсутствия обновлений. Чтобы включить такую проверку, можно добавить несколько строк в журнал аудита, как показано в таблице 7-3.

Таблица 7-3. Строки для добавления в журнал аудита функций

Аудит функций, которые изменяют глобальные переменные, требует по сути тех же мыслительных процессов, что и аудит функций, манипулирующих pass-by-reference аргументами. Процесс включает аудит каждой функции и перечисление ситуаций, в которых она изменяет глобальные переменные. Однако уязвимости, внесенные изменением глобальных переменных, могут быть более тонкими, потому что любое количество разных функций может использовать глобальную переменную и, следовательно, ожидать, что она находится в определенном состоянии. Это особенно верно для кода, который может выполняться в любой момент программы, например exception handler или signal handler.

На практике этот анализ можно проводить вместе с анализом манипуляции аргументами при создании журналов аудита функций. Можно помещать заметки об изменении глобальных переменных в строки для modifications. Однако при определении последствий изменения глобальных переменных может быть немного больше работы. Чтобы оценить риск изменения этих переменных (или отсутствия изменения, когда оно должно было произойти), просто посмотрите на каждый случай использования глобальной переменной. Если вы находите случай, где предполагается, что глобальная переменная инициализирована или обновлена определенным образом, злоумышленники могут использовать приложение, когда функции, которые должны работать с глобальной переменной, этого не делают или когда функции неожиданно ее изменяют. В листинге 7-4 вы видели пример такого рода уязвимости в OpenSSH с глобальными переменными структуры буфера. В этом коде функции уничтожения, вызываемые fatal(), делают предположение о согласованности своего состояния.

В объектно-ориентированных программах может быть намного труднее определить, подвержены ли глобальные переменные неправильному использованию из-за неожиданного изменения. Сложность возникает потому, что порядок выполнения составляющих member functions часто не ясен. В таких случаях лучше изучить каждую функцию, которая использует глобальную переменную, а затем попытаться придумать ситуацию, в которой может возникнуть уязвимость. Например, допустим, у вас есть два класса, C и D. У C есть member functions cX, cY и cZ, а у D -- member functions dX, dY и dZ. Если вы замечаете потенциально неожиданное изменение глобальной переменной в cX, а затем видите, что глобальная переменная используется в dY и dZ, задача состоит в том, чтобы определить, может ли функция cX быть вызвана так, что глобальная переменная обновляется неожиданным образом, а dY и dZ могут работать с глобальной переменной, когда она находится в этом несогласованном состоянии.

Смысл аргументов

Глава 2 представляла ясность как принцип проектирования, влияющий на безопасность системы. Вводящие в заблуждение или запутанные аргументы функций дают очень непосредственный пример именно этой проблемы. Любая путаница относительно предполагаемого смысла аргументов может иметь серьезные последствия для безопасности, потому что функция работает не так, как ожидал разработчик. "Предполагаемый смысл" аргумента обычно означает тип данных, который функция ожидает для этого аргумента, и то, что должны представлять данные, хранящиеся в этом аргументе.

При аудите функции на предмет уязвимостей, связанных с передачей неправильных аргументов, процесс следующий:

1. Перечислите тип и предполагаемый смысл каждого аргумента функции.

2. Изучите все вызывающие функции, чтобы определить, могут ли быть переданы преобразования типов или неправильные аргументы.

Первое, что нужно проверить, -- преобразования типов. Преобразования типов действительно часто происходят в аргументах, передаваемых функции, но чаще всего они не вызывают проблем, релевантных безопасности. Например, integers часто передаются в read() как третий аргумент, где преобразуются в size_t, но обычно это преобразование не важно, потому что integer является константным значением. Для каждого анализируемого вызова функции аудиторы кода должны отмечать любые преобразования типов, которые действительно происходят, и то, как этот аргумент используется в аудируемой функции. Преобразование может стать проблемой, если интерпретация аргумента может измениться из-за изменения знака. Проблема может быть значительной, если битовый шаблон аргумента меняется во время преобразования типа, как при расширении знака, потому что разработчик приложения, вероятно, не ожидал такого преобразования типа.

Затем изучите предполагаемый смысл аргумента; обычно его можно определить, наблюдая контекст, в котором он используется. Если интерфейс функции неясен или вводит в заблуждение, разработчик приложения может легко неправильно понять, как использовать функцию корректно, что может внести тонкие уязвимости. Глава 8, "Строки и метасимволы", представляет примеры с MultiByteToWideChar() и другими похожими функциями, иллюстрирующие распространенную ошибку в коде, работающем с wide characters. Часто в таких функциях аргументы длины обозначают размер буфера назначения в wide characters, а не в байтах. Спутать эти два размера данных легко, а результатом такой путаницы обычно является переполнение буфера.

Как же находить уязвимости такого рода? Нужно точно понимать, как работает функция и для чего используются ее аргументы. Общее правило таково: чем труднее разобраться в функции, тем вероятнее, что она будет использована неправильно. Как и с другими элементами аудита функций, рекомендуется вести журнал, записывая смысл разных аргументов. Этот журнал можно использовать вместе с журналом изменения аргументов, потому что записывается похожая информация: по сути нужно знать, какие аргументы требуются, как они используются и что происходит с этими аргументами на протяжении выполнения функции. Таблица 7-4 показывает пример журнала аргументов функции.

Таблица 7-4. Журнал аудита аргументов функции

Таблица 7-4 перечисляет прототип и предполагаемый смысл каждого аргумента. Вероятно, самая важная часть журнала -- список implications, который резюмирует, как программисты приложения могут использовать функцию неправильно, и отмечает любые особенности функции, способные вызвать эксплуатируемые условия. После составления этого списка можно обращаться к нему в каждом месте вызова функции и пытаться определить, могут ли какие-либо условия из списка быть истинными в вызывающих функциях. В примерной функции из таблицы 7-4 довольно много условий приводит к тому, что функция делает то, чего не должна. Это пример функции с неудобным интерфейсом, поскольку ее можно вызвать неправильно столь многими способами, что разработчику приложения было бы довольно легко использовать ее неверно.

В конечном счете секрет поиска уязвимостей, связанных с непониманием аргументов функций, в том, чтобы уметь концептуально рассматривать фрагмент кода изолированно. Когда вы пытаетесь понять, как работает функция, внимательно изучайте каждое условие, на которое напрямую влияют аргументы, и продолжайте думать о том, какие граничные условия могут привести к неправильному вызову функции. Эта задача требует большой практики, но чем больше времени вы ей уделяете, тем быстрее сможете распознавать потенциально опасные конструкции кода. Многие функции выполняют похожие операции, например копирование строк и расширение символов, и поэтому склонны к похожим неправильным использованиям. По мере накопления опыта аудита таких функций вы сможете наблюдать общие шаблоны исключительных условий и со временем эффективнее распознавать проблемы. Потратьте время на то, чтобы учесть все особенности функции и хорошо понимать, как функция может быть использована неправильно. Вы должны быть способны ответить на любые вопросы об особенностях функции и записать ответы, чтобы эта информация была легко доступна позже. Небольшие детали того, что происходит с аргументом во время выполнения функции, могут создать целый спектр возможностей для неправильного вызова функции. Наконец, особенно внимательно относитесь к преобразованиям типов, происходящим с аргументами, например усечению при работе с short integers, потому что они подвержены граничным проблемам, как обсуждалось в главе 6.

Аудит управления памятью

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

ACC-журналы

Ошибки управления памятью почти всегда являются результатом неправильного расчета длины, поэтому один из первых шагов при аудите управления памятью -- выработать хороший процесс выявления таких просчетов. Некоторые просчеты заметны сразу, но другие очень легко пропустить. Поэтому существует инструмент, помогающий находить даже самые тонкие ошибки расчета длины: журналы allocate-check-copy (ACC), то есть журналы "выделение-проверка-копирование". ACC-журнал предназначен просто для записи всех расхождений в размерах выделения, проверках длины и копировании элементов данных, которые происходят с блоком памяти. Для каждого выделения памяти ACC-журнал делится на три столбца. Первый столбец содержит формулу, описывающую размер выделяемой памяти; это может быть выражение или статическое число, если буфер имеет статический размер. Следующий столбец содержит все проверки длины, которым подвергаются элементы данных перед копированием в выделенный буфер. Третий столбец используется для перечисления элементов данных, копируемых в буфер, и способа их копирования. Отдельные операции копирования перечисляются одна за другой. Наконец, можно добавить необязательный четвертый столбец, где отмечаются интересные расхождения, выявленные из информации в первых трех столбцах. Рассмотрите пример функции в листинге 7-33, а затем соответствующий ACC-журнал в таблице 7-5.

Листинг 7-33. Пример ошибки расчета длины для построения ACC-журнала

Листинг 7-33 показывает код, который читает пакет из вымышленного протокола, выделяет память под разные элементы пакета и считывает их. Пример ACC-журнала показан в таблице 7-5.

Таблица 7-5. ACC-журнал

В ACC-журнале записываются подробности того, как выделяется буфер, какие проверки длины выполняются и как данные копируются в буфер. Такой компактный формат быстро резюмирует, как выполняются динамические выделения памяти и копирования и являются ли они безопасными. Обратите внимание, что запись для переменной cipherlist упоминает, что шифры копируются по одному. Эта деталь важна, когда вы определяете, безопасна ли операция. Если бы эта функция выполняла одно чтение размером ciphers_count * sizeof(struct cipher), длина выделения и длина копирования совпадали бы, так что код был бы безопасен независимо от того, произошло ли целочисленное переполнение. Иногда проверки выполняются перед выделением памяти; в таком случае можно переставить первые два столбца, чтобы запись было легче понимать.

ACC-журналы предназначены для помощи в выявлении проверок длины, которые могут привести к проблемам; однако они не являются полной оценкой безопасности операции с памятью. Чтобы понять этот момент, рассмотрите следующий пример:

В этом коде есть проверка длины, которую вы добавили бы в ACC-запись, но означает ли это, что можно считать копирование в память безопасным? Нет. Эта функция не использует системный распределитель для выделения cipherlist; вместо этого она использует пользовательскую функцию allocate(). Чтобы определить, безопасен ли этот код, нужно также обратиться к карточке оценки распределителя (этот инструмент будет представлен далее в разделе). Только после этого можно сделать вывод о безопасности выделения.

Следующие разделы приводят несколько примеров неправильного расчета длины буфера, на которых можно потренировать навык ведения ACC-журналов. Эти примеры знакомят с разнообразными ситуациями, где возникают ошибки расчета длины, чтобы вы увереннее распознавали похожие случаи при собственных оценках кода.

Непредвиденные условия

Ошибки расчета длины могут возникать, когда при обработке данных появляются непредвиденные условия. В следующем примере код выводит некоторые пользовательские данные в шестнадцатеричном виде:

Однако разработчик предполагает, что snprintf() успешно записывает два байта в буфер, потому что цикл всегда увеличивает dst на 2 (как показано в выделенной строке). Если в буфере не осталось байтов или остался только один байт, dst будет продвинут слишком далеко, а последующие вызовы snprintf() получат отрицательный аргумент размера. Этот размер будет преобразован в size_t и, следовательно, интерпретирован как большое положительное значение, что позволит записывать байты за пределами буфера назначения.

Предположения о данных

Довольно часто при аудите кода, работающего с двоичными данными, видно, что программисты склонны чрезмерно доверять содержимому, особенно в приложениях с закрытыми форматами файлов и протоколами. Так происходит потому, что они не продумали последствия некоторых действий или предполагают, что клиентские данные или файлы будут генерироваться только их приложениями. Часто разработчики считают, что никто не станет заниматься обратной разработкой структур данных, необходимых для взаимодействия с их программой. Однако история говорит совсем другое. Люди могут, и регулярно делают это, анализировать закрытые продукты методом обратной разработки ради поиска проблем безопасности. Более того, исследователи обычно даже охотнее и лучше готовы изучать сложные закрытые протоколы с помощью ручного анализа, black-box тестирования и автоматического фаззинга.

Один из самых простых примеров ошибок предположений о данных -- ситуации, где разработчики делают предположения о максимально возможном размере элемента данных, даже когда длина указана перед полем переменной длины. Листинг 7-34 показывает пример из библиотеки NSS, использовавшейся в Netscape Enterprise (и производных от Netscape веб-серверах) для обработки SSL-трафика.

Листинг 7-34. *Переполнение буфера в ssl2_HandleClientHelloMessage из библиотеки NSS*

В листинге 7-34 сервер берет поле длины данных challenge, предоставленное клиентом, а затем копирует указанное количество данных из пакета в буфер ss->sec.ci.ClientChallenge, статически ограниченный 32 байтами. Код просто забывает проверить, что предоставленная длина меньше буфера назначения. Такая простая ошибка довольно распространена, а в закрытых приложениях -- еще более распространена.

Порядок действий

Действия, выполненные в неправильном порядке, также могут привести к ошибке расчета длины. Листинг 7-35 показывает тонкий пример того, как может возникнуть такая проблема.

Листинг 7-35. Операторы в неправильном порядке

Листинг 7-35 содержит ошибку в месте, где строка времени, возвращаемая get_time_string(), записывается в буфер. Переменная ptr увеличивается до конца строки времени, а затем длина строки ptr вычитается из maxsize. Эти две операции выполняются в неправильном порядке. Поскольку ptr уже был увеличен, maxsize уменьшается на ноль. Поэтому maxsize не учитывает строку времени, и при вызове vsnprintf() с неправильной длиной может произойти переполнение буфера.

Несколько расчетов длины для одного и того же ввода

Распространенная ситуация, приводящая к ошибкам расчета длины в приложениях, -- когда данные обрабатываются больше одного раза в разных местах программы: обычно сначала выполняется проход для определения длины, а затем последующий проход для копирования данных. В такой ситуации аудитор должен определить, есть ли различия между фрагментом кода, рассчитывающим длину, и фрагментом, копирующим данные. Следующий код из библиотеки NSS Netscape Enterprise/Mozilla отвечает за обработку строк данных UCS2. Функция проходит по строке и рассчитывает объем места, необходимого для вывода, а если буфер назначения достаточно велик, сохраняет результат. Листинг 7-36 показывает цикл для этого расчета.

Листинг 7-36. Ошибка расчета длины UCS2 в библиотеке Netscape NSS

Обратите внимание, что при фактическом копировании данных далее в той же функции есть небольшое отличие, как показано в следующем коде:

Видите ошибку? При расчете длины ожидается только один байт вывода, когда в потоке символов встречается байт NUL, потому что смещение H_0 в inBuf используется в расчете длины дважды. Видно, что разработчик хотел проверить следующий байт, чтобы понять, установлен ли старший бит, но использовал H_0 вместо H_1. При фактическом копировании эта ошибка не повторяется. Во время операции копирования ясно видно, что если у следующего байта установлен старший бит, в выходной буфер записываются два байта, потому что во втором условии if выполняется дополнительная проверка. Поэтому, передав данные с последовательностью байтов 0x00, 0x80, можно заставить функцию записать в выходной буфер больше данных, чем изначально ожидалось. Как выяснилось, в Netscape эту уязвимость нельзя эксплуатировать, потому что выходной буфер довольно велик и нельзя передать достаточно входных данных, чтобы перезаписать произвольную память. Но даже если ошибка неэксплуатируема, функция все равно неверно рассчитывает длину, поэтому ее стоит изучить.

Функции выделения памяти

Проблемы могут возникать, когда функции выделения памяти ведут себя не так, как ожидает программист. Почему они могут вести себя иначе? Вы передаете размер, а функция возвращает блок памяти такого размера. Просто, правда? Однако код не всегда ведет себя именно так, как ожидается; при работе с выделением памяти нужно помнить о необычных случаях.

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

В целом можно считать, что системные библиотеки выделения памяти широко используются и, предположительно, достаточно надежны; однако о прикладных распределителях этого сказать нельзя, потому что их качество бывает каким угодно. Поэтому ревьюеры кода должны искать ошибочную обработку запросов, а не предполагать, что пользовательские процедуры надежны. Их следует аудировать так же, как любой другой сложный код: вести журнал семантики этих процедур и отмечать возможные условия ошибок и последствия этих ошибок.

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

Законно ли выделять 0 байт?

Многие аудиторы кода знают, что запрос выделения 0 байт в большинстве процедур выделения памяти ОС является допустимым. Возвращается блок некоторого минимального размера (обычно 12 или 16 байт). Эта информация важна при поиске целочисленных уязвимостей. Рассмотрите код в листинге 7-37.

Листинг 7-37. Целочисленное переполнение с проверкой выделения 0 байт

В этом коде атакующие могут задать длину, которая увеличивается и передается в my_malloc(). Вызову my_malloc() будет передано значение 0, когда переменная length содержит максимальное представимое целое число (0xFFFFFFFF), из-за целочисленного переполнения. Затем строковые данные длиной length байт читаются в блок памяти, возвращенный распределителем. Если бы этот код напрямую вызывал системные процедуры выделения malloc() или calloc(), можно было бы заключить, что это уязвимость: атакующие могут заставить программу скопировать большой объем данных прямо в очень маленький буфер, тем самым повредив кучу. Однако код не использует системные библиотеки напрямую; он использует пользовательскую процедуру выделения. Вот код my_malloc():

Хотя процедура выделения почти ничего не делает, кроме роли обертки над системной библиотекой, одна ее особенность существенна: она специально проверяет выделения 0 байт и завершает запрос неудачей, если такое выделение запрошено. Поэтому функция get_string_from_network(), хотя и написана небезопасно, не является уязвимой (или, точнее, не является эксплуатируемой) к описанной выше ошибке целочисленного переполнения.

Пример в листинге 7-37 очень распространен. Разработчики часто пишут небольшие обертки над процедурами выделения, которые проверяют выделения 0 байт, а также обертки над функциями free(), которые проверяют указатели NULL. Кроме того, потенциальные уязвимости, такие как в get_string_from_network(), часто встречаются при обработке двоичных протоколов или форматов файлов. Нередко нужно добавить заголовок фиксированного размера или дополнительное место для символа NUL перед выделением блока памяти. Поэтому необходимо знать, законны ли выделения 0 байт: от этого может зависеть, является ли код уязвимым к удаленной порче памяти.

Выполняет ли процедура выделения округление запрошенного размера?

Обертки функций выделения почти всегда округляют запрошенный размер выделения до некоторой границы (8-байтовой, 16-байтовой и так далее). Обычно такая практика допустима и часто необходима; однако при неправильной реализации она может открыть функцию для уязвимости целочисленного переполнения. Процедура выделения потенциально подвергает себя этой уязвимости, когда округляет запрошенный размер до следующей подходящей границы, предварительно не выполнив никаких sanity checks запрошенного размера. Листинг 7-38 показывает пример.

Листинг 7-38. Уязвимость округления в распределителе

Назначение выделенной строки в этой функции -- округлить size до следующей 16-байтовой границы, добавив 15 к запрошенному размеру, а затем обнулив младшие четыре бита маской. Однако функция не проверяет, что size меньше 0xFFFFFFF1. Если передать именно такой размер запроса (или любой размер от 0xFFFFFFF1 до 0xFFFFFFFF включительно), функция переполнит 32-битное беззнаковое целое и приведет к выделению 0 байт. Имейте в виду, что эта функция не была бы уязвимой, если бы size проверялся на 0 после операции округления. Часто разница между уязвимым и безопасным кодом -- небольшое изменение порядка действий, как и здесь.

Выполняются ли над размером запроса другие арифметические операции?

Хотя округление непроверенного размера запроса -- самая распространенная ошибка, открывающая процедуру выделения для целочисленных уязвимостей, другие арифметические операции тоже могут привести к уязвимостям целочисленного оборачивания. Вторая по распространенности ошибка возникает, когда приложение строит дополнительный слой управления памятью поверх управления ОС. Обычно процедуры управления памятью приложения запрашивают у ОС крупные блоки памяти, а затем делят их на меньшие блоки для отдельных запросов. К блоку обычно добавляется некоторый заголовок, и поэтому размер такого заголовка прибавляется к запрошенному размеру блока. Листинг 7-39 показывает пример.

Листинг 7-39. Распределитель со структурой заголовка

Эта простая операция сложения создает возможность целочисленного переполнения, очень похожую на проблему из листинга 7-37. В данном случае функция my_malloc3() уязвима к целочисленному переполнению при любых значениях size между 0xFFFFFFFF и 0xFFFFFFFF - sizeof(struct block_hdr). Любое значение в этом диапазоне приведет к выделению маленького буфера для запроса чрезвычайно большой длины.

Функции повторного выделения памяти также подвержены целочисленным переполнениям, потому что при определении размера нового блока памяти обычно требуется операция сложения. Поэтому, если пользователи могут задать один из этих размеров, есть высокая вероятность целочисленного оборачивания. Достаточные sanity checks редко выполняются для обеспечения безопасности функций повторного выделения, поэтому ревьюеры кода должны внимательно проверять наличие этих проверок. Листинг 7-40 показывает функцию, увеличивающую буфер, чтобы освободить место для добавления данных.

Листинг 7-40. Целочисленное переполнение при повторном выделении

Выделенный код в листинге 7-40 показывает потенциально опасную операцию сложения. Если пользователи могут задавать значение bytes, выражение bytes + buf->alloc_size можно заставить обернуться, и realloc() вернет маленький блок, в котором недостаточно места для нужных данных.

Согласованы ли типы данных для размеров запросов?

Иногда функции выделения памяти ведут себя неожиданно из-за проблем типизации. Многие вопросы типизации, обсуждавшиеся в главе 6, особенно релевантны при работе с распределителями, поскольку почти любая ошибка преобразования типов, скорее всего, приведет к уязвимости порчи памяти, которая легко эксплуатируется.

Иногда встречаются распределители памяти, использующие 16-битные размеры. Эти функции более уязвимы к проблемам типизации, чем обычные распределители, потому что максимальное представимое ими значение равно 65535 байтам, и пользователи с большей вероятностью могут задать блоки данных такого размера или больше. Листинг 7-41 показывает пример.

Листинг 7-41. Опасное использование типа данных

Чтобы вызвать уязвимость, достаточно найти место в коде, где my_malloc4() может быть вызвана со значением больше 65535 (0xFFFF) байт. Если можно спровоцировать выделение размера вроде 0x00010001 (что, в зависимости от приложения, не так уж невероятно), значение усекается до short, что приводит к выделению 1 байта.

Появление 64-битных систем также может сделать процедуры выделения уязвимыми. Глава 6 подробнее обсуждает 64-битные проблемы типизации, но проблемы могут возникать при смешивании типов данных long, size_t и int. В модели компилятора LP64 типы данных long и size_t являются 64-битными, тогда как типы int занимают только 32 бита. Поэтому взаимозаменяемое использование этих типов может давать непреднамеренные и неожиданные результаты. Чтобы увидеть, как это может стать проблемой, снова рассмотрите предыдущий пример.

Как уже говорилось, эта обертка выделения почти ничего не делает, кроме проверки выделения нулевой длины. Однако она делает одну существенную вещь: принимает параметр unsigned int, а не size_t, который принимает функция malloc(). В 32-битной системе эти типы данных эквивалентны; однако в системах LP64 это, конечно, не так. Представьте, что эта функция вызывается как в листинге 7-42.

Листинг 7-42. Проблемы с 64-битными системами

Функция read_string() специально проверяет целочисленные переполнения перед вызовом процедуры выделения. В 32-битных системах этот код корректен, но что насчет 64-битных систем? Переменная length в read_string() имеет тип size_t, то есть 64 бита. Если предположить, что get_network_integer() возвращает int, внимательно посмотрите на проверку целочисленного переполнения:

В системе LP64 обе стороны этого выражения являются 64-битными целыми, поэтому проверка может подтвердить только то, что 64-битное значение не переполняется. Однако при вызове my_malloc() результат усекается до 32 бит, потому что эта функция принимает 32-битный целочисленный параметр. Поэтому в 64-битной системе этот код может пройти первую проверку со значением 0x100000001, а затем быть усечен до гораздо меньшего значения 0x1 при передаче в качестве 32-битного параметра.

Также становится очень важным, являются ли значения, передаваемые процедурам выделения памяти, знаковыми. Каждую процедуру выделения памяти следует проверить на это условие. Если процедура выделения ничего не делает, кроме передачи целого числа в ОС, может быть неважно, является ли параметр size знаковым. Однако если процедура сложнее и выполняет вычисления и сравнения на основе параметра size, знаковость значения определенно важна. Обычно чем сложнее процедура выделения, тем вероятнее, что знаковость параметров size станет проблемой.

Есть ли максимальный размер запроса?

Многие из предыдущих условий уязвимости были связаны с отсутствием sanity check размеров запросов. Иногда разработчики приложения решают произвольно встроить максимальный предел объема памяти, который код выделяет, как показано в листинге 7-43. Максимальный размер запроса часто пресекает многие потенциальные атаки на процедуры выделения. Аудиторы кода должны определить, существует ли максимальный предел, поскольку он может повлиять на потенциальные уязвимости порчи памяти в других местах программы.

Листинг 7-43. Максимальный предел выделения памяти

Распределитель в листинге 7-43 довольно ограничителен: он разрешает выделять только небольшие блоки. Поэтому он не подвержен целочисленным переполнениям при округлении размера запроса после проверки размера. Однако если бы округление выполнялось до проверки размера, а не после нее, распределитель все равно был бы уязвим к целочисленному переполнению. Также отметьте, является ли параметр size знаковым. Если бы этот аргумент был отрицательным, можно было бы обойти проверку максимального размера (и обернуть целое через нулевую границу во время последующего округления).

Возвращается ли когда-нибудь блок памяти другого размера, чем был запрошен?

Практически все уязвимости целочисленного оборачивания становятся эксплуатируемыми по одной причине: возвращается блок памяти другого размера, чем был запрошен. Когда это происходит, появляется возможность эксплуатации. Хотя это редко, иногда процедура выделения памяти может изменить размер запроса. Листинг 7-44 показывает слегка измененный предыдущий пример.

Листинг 7-44. Уязвимость максимального предела выделения памяти

Функция my_malloc6() в листинге 7-44 не выделяет блок больше MAX_MEMORY_BLOCK. Когда запрашивается блок большего размера, функция изменяет размер запроса вместо того, чтобы завершиться неудачей. Это очень опасно, когда вызывающий код передает размер, который может быть больше MAX_MEMORY_BLOCK, и предполагает, что получил блок памяти именно запрошенного размера. Фактически вызывающая функция никак не может узнать, ограничила ли my_malloc6() размер запроса значением MAX_MEMORY_BLOCK, если только каждая функция, вызывающая ее, не проверяет заранее, что не собирается запросить блок больше MAX_MEMORY_BLOCK, что крайне маловероятно. Чтобы вызвать уязвимость в такой программе, атакующим достаточно найти место, где они могут запросить больше MAX_MEMORY_BLOCK байт. Запрос молча усекается до меньшего, чем ожидалось, размера, и вызывающая процедура неизбежно копирует в этот блок больше данных, чем было выделено, что приводит к порче памяти.

Карточки оценки распределителей и области ошибок

При ревью приложений нужно выявлять процедуры выделения памяти на раннем этапе аудита и выполнять их беглую проверку. Как минимум следует охватить каждую потенциально опасную область, оценивая процедуры выделения по связанным с ними вопросам уязвимости, то есть создавая своего рода карточку оценки. Такую карточку можно использовать как краткий способ работы с распределителями, чтобы не вести объемный журнал аудита. Однако все равно нужно искать и отмечать уникальные ситуации, не покрытые карточкой, особенно когда процедура выделения сложна. Посмотрите, как могут выглядеть такие карточки распределителей, в таблице 7-6.

Таблица 7-6. Карточка оценки распределителя

Эта карточка резюмирует все потенциальные проблемные области распределителя. В ней нет столбца, указывающего, являются ли значения знаковыми, и нет перечисления 16-битных проблем, потому что эту информацию можно мгновенно вывести из прототипа функции. Если у функции есть внутренние проблемы, вызванные знаковостью значений, перечислите их в строке Notes карточки. Для простых распределителей можно выполнить еще более компактное резюме в виде областей ошибок. Область ошибок -- это набор значений, которые при передаче в функцию порождают одно из исключительных условий, способных привести к порче памяти. Таблица 7-7 показывает пример резюмирования одной области ошибок для функции.

Таблица 7-7. Область ошибок

У каждого распределителя может быть несколько областей ошибок, каждая со своими последствиями. Такое краткое резюме -- полезный инструмент аудита кода, потому что к нему можно обратиться и сразу понять: если распределитель вызывается с одним из перечисленных значений, существует уязвимость. Можно быстро проходить каждый вызов распределителя и проверять, возможна ли такая ситуация. Преимущество этого инструмента в компактности, но недостаток в потере части деталей. Для более сложных распределителей может потребоваться обращаться к более подробным заметкам и журналам аудита функций.

Таблицы областей ошибок можно использовать с любыми аудируемыми функциями, не только с распределителями; однако есть и недостатки. Функции выделения обычно малы и конкретны, и вы более или менее точно знаете, что они делают. Карточки распределителей и таблицы областей ошибок помогают фиксировать различия между использованием системных процедур выделения и прикладных оберток над ними. С другими функциями, выполняющими более сложные задачи, при попытке столь компактного резюмирования можно потерять слишком много информации.

Двойное освобождение

Иногда разработчики ошибочно освобождают объекты дважды (или больше раз), что может иметь последствия столь же серьезные, как и любая другая форма порчи кучи. Освобождать объекты более одного раза опасно по нескольким причинам. Например, что если блок памяти освобожден, а затем снова выделен и заполнен другими данными? При втором free() по адресу, переданному в качестве параметра free(), уже нет управляющей структуры, а находятся какие-то произвольные данные программы. Что помешает этой области памяти содержать специально подготовленные данные для эксплуатации процедур управления кучей?

Угроза есть и в том случае, если память не переиспользуется между последовательными вызовами free(), потому что блок памяти может быть помещен в список свободных блоков дважды. Позже в программе один и тот же блок памяти может быть возвращен из запроса выделения два раза, и программа может попытаться хранить два разных объекта по одному адресу, возможно позволяя выполнить произвольный код. Второй пример сегодня встречается реже, потому что большинство библиотек управления памятью (в частности, реализации Windows и GNU libc) обновили свои распределители так, чтобы проверять, используется ли блок, переданный в free(); если нет, распределители ничего не делают. Однако в некоторых ОС есть распределители, не защищающие от атаки double free, поэтому ошибки такого рода все еще считаются серьезными.

При аудите кода, использующего динамическое выделение памяти, нужно отслеживать каждый путь на протяжении жизни переменной, чтобы понять, не освобождается ли она случайно функцией free() больше одного раза. Листинг 7-45 показывает пример уязвимости double free.

Листинг 7-45. Уязвимость double free

В этом примере видно, что выделенный путь кода освобождает data дважды, когда не распознает допустимое ключевое слово. Хотя такой ошибки кажется легко избежать, в сложных приложениях часто есть тонкости, из-за которых подобные промахи труднее заметить. Листинг 7-46 -- реальный пример из OpenSSL 0.9.7. Корневая причина проблемы находится в функции CRYPTO_realloc_clean().

Листинг 7-46. Уязвимость double free в OpenSSL

Как видно, функция CRYPTO_realloc_clean() освобождает переданный ей параметр str независимо от того, завершилась она успешно или неудачно. Такой интерфейс довольно неинтуитивен и легко приводит к ошибкам double free. Функция CRYPTO_realloc_clean() используется внутри процедуры управления буфером BUF_MEM_grow_clean(), показанной в следующем коде:

В результате вызова OPENSSL_realloc_clean() функция BUF_MEM_grow_clean() фактически может освободить собственный элемент data. Однако она не устанавливает data в NULL, когда происходит такая ошибка повторного выделения. Это странное поведение делает ошибку double free вероятной в функциях, использующих структуры BUF_MEM. Посмотрите на этот вызов в asn1_collate_primitive():

Эта функция пытается увеличить структуру BUF_MEM b, но при возврате ошибки освобождает все имеющиеся ресурсы и возвращает 0. Как вы теперь знаете, если BUF_MEM_grow_clean() завершается неудачно из-за ошибки в CRYPTO_realloc_clean(), она освобождает b.data, но не устанавливает его в NULL. Поэтому выделенный код освобождает b.data второй раз.

Аудиторы кода должны быть особенно внимательны к double free при аудите C++-кода. Иногда трудно отслеживать внутреннее состояние объекта, а неожиданные состояния могут приводить к double free. Обращайте внимание на члены, которые освобождаются более чем в одной функции-члене объекта (например, в обычной функции-члене и в деструкторе), и пытайтесь определить, используется ли класс когда-либо так, что объект может быть уничтожен после того, как некоторые переменные-члены уже были освобождены.

Ошибки double free могут появляться и другими способами. Многие процедуры повторного выделения памяти в операционных системах освобождают буфер, который должны были перераспределить, если новый размер буфера равен 0. Это верно для большинства реализаций UNIX. Поэтому, если атакующий может вызвать realloc() с новым размером 0, тот же буфер позже может быть освобожден снова; кроме того, есть высокая вероятность, что в только что освобожденный буфер затем будут записаны данные. Листинг 7-47 показывает простой пример.

Листинг 7-47. Уязвимость double free при повторном выделении

Этот код показывает несколько типичных процедур управления буфером. Из того, что вы уже узнали о процедурах выделения, можно выделить пару интересных характеристик buffer_grow(). В первую очередь, она проверяет целочисленные переполнения при увеличении буфера, но округление выполняется после проверки. Поэтому всякий раз, когда new_size и buf->used складываются и дают результат между 0xFFFFFFF1 и 0xFFFFFFFF, округление вызывает целочисленное переполнение, и значение 0 передается в realloc(). Также обратите внимание: если realloc() завершается неудачей, buf->data не устанавливается в указатель NULL. Это важно, потому что когда realloc() освобождает буфер из-за параметра нулевой длины, она возвращает NULL. Следующий код показывает возможные последствия:

Функция process_login() пытается увеличить буфер настолько, чтобы сохранить последующие данные. Если предоставленная длина достаточно велика, чтобы вызвать целочисленное оборачивание, член buf->data освобождается дважды: один раз во время buffer_grow(), когда в realloc() передается размер 0, и еще раз в buffer_free(). Этот пример специально охватывает несколько функций: часто ошибки такого рода распределены именно так и менее очевидны. Эту ошибку было бы легко пропустить, если не обратить пристального внимания на работу buffer_grow() (чтобы заметить целочисленное переполнение) и на нюансы работы realloc().

Резюме

Эта глава была посвящена базовым компонентам, из которых состоит язык программирования: использованию переменных, потоку управления, вызовам функций и управлению памятью. Изучая потенциальные уязвимости безопасности с точки зрения каждого из этих строительных блоков, можно выделять повторяющиеся шаблоны уязвимостей в программном обеспечении. Кроме того, вы увидели, как целенаправленно искать области, где программист с большей вероятностью внесет уязвимости при переводе проекта в итоговую реализацию. Наконец, вы изучили несколько инструментов для отслеживания своей работы и упрощения процесса выявления уязвимостей.

В этой главе рассматриваются уязвимости безопасности, связанные с обработкой текстовых форматов данных, содержащихся в строках. Материал охватывает основные области работы со строками: порчу памяти из-за неправильной обработки строк; уязвимости из-за внутриполосных управляющих данных в виде метасимволов; и уязвимости, возникающие при преобразованиях между кодировками символов в разных языках. Понимая распространенные шаблоны, связанные с такими уязвимостями, вы сможете выявлять и предотвращать их появление.

Работа со строками в C

В C нет встроенного типа для строк; вместо этого строки формируются как массивы данных типа char, где символ NUL (0x00) отмечает конец строки (иногда его называют NULL-символом или EOS). Такое представление строки означает, что длина строки не связана с буфером, который ее содержит, и часто неизвестна до времени выполнения. Эти детали требуют от программистов вручную управлять строковыми буферами, обычно одним из двух способов. Они могут оценить, сколько памяти нужно зарезервировать (выбрав консервативный максимум) для массива статического размера, или использовать доступные в системе API выделения памяти, чтобы динамически выделять память во время выполнения, когда становится известен объем места, необходимый для блока данных.

Второй вариант кажется более разумным, но у него есть недостатки. Динамическое выделение памяти связано с гораздо большими накладными расходами, а программистам нужно гарантировать, что память корректно освобождается на каждом возможном пути выполнения, чтобы избежать утечек. Стандартная библиотека C++ предоставляет класс строк, который абстрагирует внутренние детали, так что программистам не нужно явно заниматься проблемами размеров памяти. Поэтому строковый класс C++ немного безопаснее и менее подвержен уязвимостям, возникающим при работе с символами в C. Однако программистам часто приходится преобразовывать строки C и строковые классы C++ друг в друга, чтобы использовать API, требующие строки C; поэтому даже программа на C++ может быть уязвима к ошибкам обработки строк C. Большинство уязвимостей обработки строк C является результатом небезопасного использования небольшой группы функций, которые рассматриваются в следующих разделах.

Неограниченные строковые функции

Первая группа функций -- традиционно небезопасные функции манипуляции строками. Главная проблема этих функций в том, что они неограниченные, то есть размер буфера назначения не учитывается при копировании данных. Это означает, что если длина исходных строковых данных, переданных этим функциям, превышает размер буфера назначения, может возникнуть переполнение буфера, часто приводящее к эксплуатируемой порче памяти. Аудиторы кода должны систематически изучать каждое появление таких функций в кодовой базе, чтобы определить, вызываются ли они небезопасным образом. Проще говоря, аудиторы должны выяснить, достижимы ли эти функции в ситуации, где буфер назначения недостаточно велик для исходного содержимого. Анализируя все пути кода, ведущие к этим небезопасным процедурам, можно установить, существует ли проблема, и классифицировать вызов как безопасный или небезопасный.

scanf()

Функции scanf() используются при чтении данных из файлового потока или строки. Каждый элемент данных, заданный в строке формата, сохраняется в соответствующем аргументе. Когда в строке формата задаются строки (с помощью спецификатора формата %s), соответствующий буфер должен быть достаточно большим, чтобы вместить строку, считанную из потока данных. Функция scanf() кратко описана в следующем списке:

• Функция: int scanf(const char *format, ...);

• API: libc (UNIX и Windows)

• Похожие функции: _tscanf, wscanf, sscanf, fscanf, fwscanf, _snscanf, _snwscanf

• Назначение: функция scanf() разбирает ввод согласно формату, указанному в аргументе format.

Следующий код показывает пример неправильного использования scanf():

Код в этом примере читает ответ IDENT (определенный в www.ietf.org/rfc/rfc1413.txt) от клиента. Как видно, считывается до 1024 байт, а затем данные разбираются в последовательность целых чисел и строк, разделенных двоеточиями. Переменные user, rtype и addinfo имеют длину всего 32 байта, поэтому если клиент передаст любое из этих полей строкой длиннее 32 байт, произойдет переполнение буфера.

sprintf()

Функции sprintf() в прошлом стали причиной множества уязвимостей безопасности. Если буфер назначения, переданный первым параметром, недостаточно велик для входных элементов данных, может произойти переполнение буфера. Переполнения буфера возникают главным образом из-за печати больших строк (с использованием спецификаторов формата %s или %[]). Хотя это менее распространено, другие спецификаторы формата (например, %d или %f) также могут приводить к переполнениям буфера. Если пользователи могут частично или полностью контролировать аргумент формата, может возникнуть другой тип ошибки, известный как уязвимости "строки формата". Они подробнее обсуждаются далее в этой главе в разделе "Строки формата C". Функция sprintf() кратко описана в следующем списке:

• Функция: int sprintf(char *str, const char *format, ...);

• API: libc (UNIX и Windows)

• Похожие функции: _stprintf, _sprintf, _vsprintf, vsprintf, swprintf, vswprintf, _wsprintfA, _wsprintfW

• Назначение: функции sprintf() печатают форматированную строку в буфер назначения.

Следующий пример взят из модуля Apache JRUN:

Этот пример -- классическое неправильное использование vsprintf(). Размер буфера назначения вообще не учитывается, поэтому если функцию vsprintf() можно вызвать с любой строкой длиннее 2048 байт, произойдет переполнение буфера.

Примечание

Функции _wsprintfA() и _wsprintfW() копируют в буфер назначения максимум 1024 символа, в отличие от других функций sprintf(), которые копируют столько, сколько требуется.

strcpy()

Семейство функций strcpy() печально известно тем, что за годы вызвало большое количество уязвимостей безопасности во многих приложениях. Если буфер назначения может быть меньше длины исходной строки, может произойти переполнение буфера. Функции wscpy(), wcscpy() и mbscpy() похожи на strcpy(), но работают с wide- и multibyte-символами и распространены в приложениях Windows. Следующий список резюмирует функции strcpy():

• Функция: char *strcpy(char *dst, char *src)

• API: libc (UNIX и Windows)

• Похожие функции: _tcscpy, lstrcpyA, wcscpy, _mbscpy

• Назначение: strcpy() копирует строку, расположенную по адресу src, в место назначения dst. Копирование прекращается при встрече символа конца строки (байта NUL).

Следующий код является примером неправильного использования strcpy():

Этот код очевидно неправильно использует strcpy(). Исходный буфер легко может содержать строку длиннее буфера назначения, поэтому может быть вызвано переполнение буфера. Ошибки такого рода когда-то были очень распространены, но теперь встречаются реже, поскольку разработчики лучше осведомлены о неправильном использовании strcpy(); однако они все еще возникают, особенно в закрытых приложениях, которые не распространяются широко.

strcat()

Конкатенация строк часто используется при построении строк, состоящих из нескольких компонентов (например, путей). При вызове strcat() буфер назначения (dst) должен быть достаточно большим, чтобы вместить уже находящуюся там строку, присоединяемую строку (src) и завершающий NUL. Следующий список резюмирует функцию strcat():

• Функция: char *strcat(char *dst, char *src)

• API: libc (UNIX и Windows)

• Похожие функции: _tcscat, wcscat, _mbscat

• Назначение: функции strcat() отвечают за объединение двух строк. Строка src добавляется к dst.

Следующий код показывает пример неправильного использования strcat():

Код в этом примере выполняет несколько копирований строк, причем каждое включает проверку длины, чтобы предоставленный буфер не переполнил буферы назначения. Однако когда имя узла передается без завершающего домена, значение строки по умолчанию небезопасно присоединяется к буферу (как показано в выделенной строке). Уязвимость возникает потому, что не выполняется проверка размера, гарантирующая, что длина default_domain плюс длина delim меньше длины буфера domain.

Ограниченные строковые функции

Ограниченные строковые функции были разработаны, чтобы дать программистам более безопасную альтернативу функциям, обсуждавшимся в предыдущем разделе. Эти функции включают параметр, задающий длину (или границы) буфера назначения. Этот параметр длины облегчает безопасное использование ограниченных функций, но они все равно подвержены более тонким неправильным использованиям. Например, важно перепроверять, действительно ли указанная длина является правильным размером результирующего буфера. Хотя такая проверка звучит очевидно, ошибки расчета длины или ошибочные параметры длины часто встречаются при использовании этих функций. Вот условия, из-за которых параметр длины может быть неправильным:

• Небрежность

• Ошибочный ввод

• Неправильный расчет длины

• Арифметические граничные условия

• Преобразованные типы данных

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

snprintf()

Функция snprintf() -- ограниченная замена sprintf(); она принимает максимальное количество байтов, которое можно записать в выходной буфер. Эта функция кратко описана в следующем списке:

• Функция: int snprintf(char *dst, size_t n, char *fmt, ...)

• API: libc (UNIX и Windows)

• Похожие функции: _sntprintf, _snprintf, _snwprintf, vsnprintf, _vsnprintf, _vsnwprintf

• Назначение: snprintf() форматирует данные согласно спецификаторам формата в строку, как и sprintf(), но имеет параметр размера.

Интересная оговорка об этой функции состоит в том, что она работает немного по-разному в Windows и UNIX. В ОС Windows, если места недостаточно, чтобы вместить все данные в результирующий буфер, возвращается значение -1, и NUL-терминация не гарантируется. И наоборот, реализации UNIX гарантируют NUL-терминацию в любом случае и возвращают количество символов, которое было бы записано, если бы места хватило. То есть если результирующий буфер недостаточно велик, чтобы вместить все данные, он NUL-терминируется, а возвращается положительное целое число, большее предоставленного размера буфера. Такое различие поведения может приводить к ошибкам в следующих ситуациях:

• Разработчик, знакомый с одной ОС, пишет код для другой и не знает об их различиях.

• Приложение собирается для работы и в Windows, и в UNIX, поэтому корректно работает в одной ОС, но некорректно в другой.

Листинг 8-1 -- пример уязвимости, возникшей из-за предположения о UNIX-поведении vsnprintf() в приложении Windows.

Листинг 8-1. *Разное поведение vsnprintf() в Windows и UNIX*

Код в листинге 8-1 прекрасно работает в UNIX. Он проверяет, что в буфере остается как минимум два байта для завершающего символа новой строки, или сокращает буфер так, чтобы вызов strcat() не переполнил его. Однако если тот же код выполняется в Windows, история другая. Если buffer заполнен, n устанавливается в -1, поэтому проверка длины проходит, и символ новой строки записывается за пределами buffer.

strncpy()

Функция strncpy() -- "безопасная" альтернатива strcpy(); она принимает максимальное количество байтов, которое нужно скопировать в место назначения. Следующий список резюмирует функцию strncpy():

• Функция: char *strncpy(char *dst, char *src, size_t n)

• API: libc (UNIX и Windows)

• Похожие функции: _tcsncpy, _csncpy, wcscpyn, _mbsncpy

• Назначение: strncpy() копирует строку, расположенную по адресу src, в место назначения dst. Копирование прекращается при встрече символа конца строки (байта NUL) или когда в буфер назначения записано n символов.

Функция strncpy() не гарантирует NUL-терминацию строки назначения. Если исходная строка больше буфера назначения, strncpy() копирует столько байтов, сколько указано параметром размера, а затем прекращает копирование, не добавляя NUL-терминатор в буфер. Это означает, что любые последующие операции над результирующей строкой могут дать неожиданные результаты, способные привести к уязвимости безопасности. Листинг 8-2 показывает пример неправильного использования strncpy().

Листинг 8-2. *Опасное использование strncpy()*

Код копирует данные в буфер с помощью strncpy(), но после этого не выполняет явную NUL-терминацию буфера. Затем буфер передается как аргумент функции is_username_valid(), которая выполняет на нем strchr(). Функция strchr() ищет конкретный символ в строке (в данном случае :). Если strchr() находит символ, она возвращает указатель на него; иначе она возвращает NULL, если символ не найден. Поскольку в этом буфере нет NUL-символа, strchr() может выйти за пределы буфера и найти искомый символ в другой переменной или, возможно, в управляющей информации программы (например, в frame pointer, адресе возврата на стеке или заголовке блока в куче). Затем этот байт изменяется, что потенциально влияет на состояние программы непредсказуемым или небезопасным образом.

Функция wcscpyn() -- безопасная альтернатива wcscpy(). Она подвержена тем же неправильным использованиям, что и strncpy(). Если исходная строка больше буфера назначения, NUL-терминатор не добавляется к результирующей строке. Кроме того, при работе с wide characters разработчики приложений часто ошибочно передают размер буфера назначения в байтах вместо количества wide characters, которые помещаются в буфер назначения. Этот вопрос обсуждается далее в этой главе в разделе "Unicode-функции Windows".

strncat()

Функция strncat(), кратко описанная ниже, предназначена как безопасная альтернатива функции strcat():

• Функция: char *strncat(char *dst, char *src, size_t n)

• API: libc (UNIX и Windows)

• Похожие функции: _tcsncat, wcsncat, _mbsncat

• Назначение: strncat() объединяет две строки. Строка, на которую указывает src, добавляется к строке, на которую указывает dst. Копируется не более n байтов.

Однако strncat() почти так же опасна, как strcat(), потому что ее очень легко использовать неправильно. В частности, параметр размера может сбивать с толку: он указывает объем пространства, оставшегося в буфере. Первая распространенная ошибка разработчиков приложений -- передача размера всего буфера вместо оставшегося места в нем. Эта ошибка показана в следующем примере:

Этот код ошибочно передает общий размер буфера, а не оставшийся размер, тем самым позволяя тому, кто контролирует аргумент username, переполнить буфер.

При использовании strncat() можно совершить и более тонкую ошибку. Как уже говорилось, аргумент размера представляет количество байтов, оставшихся в буфере. Это утверждение было слегка упрощено: размер не учитывает завершающий байт NUL, который всегда добавляется в конец строки. Поэтому параметр размера должен быть равен объему свободного места в буфере минус один; иначе байт NUL записывается на один байт за пределами буфера. Следующий пример показывает, как эта ошибка обычно выглядит в коде приложения:

Этот код не учитывает завершающий байт NUL, поэтому это уязвимость off-by-one. Обратите внимание: даже при передаче корректного параметра длины в strncat (то есть sizeof(buf) - strlen(buf) - 1) может произойти целочисленное переполнение вниз, также приводящее к переполнению буфера.

strlcpy()

Функция strlcpy() -- BSD-специфичное расширение строковых API libc. Она пытается устранить недостатки функции strncpy(). В частности, она гарантирует NUL-терминацию буфера назначения. Эта функция -- одна из самых безопасных альтернатив strcpy() и strncpy(); однако она используется не слишком широко по причинам переносимости. Следующий список резюмирует функцию strlcpy():

• Функция: size_t strlcpy(char *dst, char *src, size_t n)

• API: libc (BSD)

• Похожие функции: нет

• Назначение: strlcpy() действует почти так же, как strncpy(), за исключением того, что гарантирует NUL-терминацию буфера назначения. Аргумент длины включает место для байта NUL.

При аудите кода, использующего strlcpy(), помните, что возвращаемый размер -- это длина исходной строки (без учета байта NUL), поэтому возвращаемое значение может быть больше размера буфера назначения. Следующий пример показывает уязвимый код:

Параметр длины, возвращенный strlcpy(), в этом коде используется неверно. Если параметр username, переданный этой функции, длиннее 1024 байт, параметр размера strlcat() переполняется вниз и позволяет копировать данные за границы буфера. Такие уязвимости не распространены, потому что возвращаемое значение обычно отбрасывается. Однако игнорирование результата этой функции может приводить к усечению данных.

strlcat()

Функция strlcat(), кратко описанная в следующем списке, -- еще одно BSD-специфичное расширение API libc, предназначенное для устранения недостатков функции strncat():

• Функция: size_t strlcat(char *dst, char *src, size_t n)

• API: libc (BSD)

• Похожие функции: нет

• Назначение: strlcat() объединяет две строки почти так же, как strncat().

Параметр размера изменен так, чтобы разработчикам было проще пользоваться функцией. Параметр размера для strlcat() -- это общий размер буфера назначения, а не оставшееся свободное место в буфере, как у strncat(). Функция strlcat() гарантирует NUL-терминацию буфера назначения. Снова же, это одна из самых безопасных альтернатив strcat() и strncat(). Как и strlcpy(), strlcat() возвращает общее количество байтов, необходимое для хранения результирующей строки. То есть она возвращает длину строки буфера назначения плюс длину исходной строки. Есть одно исключение: когда строковый буфер назначения уже длиннее параметра n, буфер остается неизменным и возвращается параметр n.

Распространенные проблемы

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

Неограниченные копирования

Проще всего заметить неограниченные копирования, которые вообще не проверяют границы буферов назначения, примерно как уязвимое использование strcpy() в разделе "Неограниченные строковые функции". Листинг 8-3 показывает пример.

Листинг 8-3. *Цикл, похожий на strcpy()*

Листинг 8-3 показывает прямолинейную уязвимость. Если длина исходной строки больше размера hname, при выполнении выделенного кода произойдет переполнение стека. Полезно отмечать функции, которые выполняют столь явно непроверенные копирования, и смотреть, вызываются ли они когда-либо уязвимым образом.

Расширение символов

Расширение символов происходит, когда программа кодирует специальные символы, в результате чего строка становится длиннее исходной. Это часто встречается при обработке метасимволов, как обсуждается на протяжении этой главы, но также может происходить, когда сырые данные форматируются для удобства чтения человеком. Код расширения символов может быть уязвим, если результирующая расширенная строка слишком велика для буфера назначения, как в примере из листинга 8-4.

Листинг 8-4. Переполнение буфера при расширении символов

В листинге 8-4 видно, что при встрече непечатаемых символов выделенный участок кода записывает шестнадцатеричное представление символа в буфер назначения. Поэтому на каждой итерации цикла программа может записать два выходных символа на один входной символ. Передав большое количество непечатаемых символов, атакующий может вызвать переполнение буфера назначения.

Неправильное увеличение указателей

Уязвимости безопасности могут возникать, когда указатели могут увеличиваться за пределы обрабатываемой строки. Эта проблема возникает главным образом в одном из двух случаев: когда строка некорректно NUL-терминирована; или когда NUL-терминатор может быть пропущен из-за ошибки обработки. В листинге 8-2 вы видели, что strncpy() может стать причиной отсутствия NUL-терминации строки. Часто, когда строка завершена некорректно, дальнейшая обработка этой строки довольно опасна. Например, рассмотрите строку, в которой с помощью функции strchr() ищется определенный разделитель. Если NUL-терминатор отсутствует, поиск не остановится в конце данных, предоставленных пользователем, как предполагалось. Искомый символ может находиться в неинициализированной памяти или соседних переменных, что является потенциальной уязвимостью. Следующий пример показывает похожую ситуацию:

Пример забывает NUL-терминировать buf, поэтому последующий поиск символа может выйти за границы буфера. Еще хуже, что искомый символ заменяется байтом NUL, так что переменные или состояние программы могут быть повреждены. Другое интересное следствие отсутствия NUL-терминации буфера состоит в том, что может быть внесено условие переполнения буфера, если программист делает предположения о максимальной длине строки в буфере. Следующий код показывает распространенный пример такого предположения:

Функция process_address() написана с предположением, что read_data() корректно NUL-терминирует массив символов netbuf. Поэтому последующие операции strcpy() должны быть безопасными. Однако если функция read_data() не завершает буфер должным образом, длина данных, считанных в netbuf, может быть больше 256, в зависимости от того, что находится на стеке программы после него. Следовательно, операции strcpy() могут переполнить буфер username.

Есть и странная ситуация, когда код, обрабатывающий текстовые строки, не распознает встреченный байт NUL из-за упущения в обработке. Такая ошибка может произойти потому, что код ищет определенный символ в строке, но не проверяет байт NUL, как показано в следующем примере:

Обратите внимание, что этот цикл специально ищет символ @, но если его нет в строке, цикл продолжает увеличивать указатель за конец строки, пока не найдет такой символ. Есть и небольшие вариации этой ошибки, как в следующем примере:

Второй цикл построен правильнее и завершается при встрече символа @ или байта NUL. Однако после завершения цикла программист все равно предположил, что цикл остановился потому, что нашел символ @, а не байт NUL. Поэтому, если символ @ не найден, указатель увеличивается за байт NUL.

Третий пример увеличения указателя за границы буфера обычно возникает, когда программисты делают предположения о содержимом разбираемого буфера. Атакующий может использовать намеренно искаженные данные, чтобы воспользоваться этими предположениями и заставить программу сделать то, чего она не должна. Допустим, у вас есть строка, содержащая переменные, отправленные формой с веб-сайта, и вы хотите разобрать и сохранить эти переменные. Этот процесс включает декодирование шестнадцатеричных последовательностей вида %XY, где X и Y -- шестнадцатеричные символы (0-9, a-f и A-F), представляющие значение байта. Если приложение не гарантирует, что один из двух символов после % не является NUL-терминатором, оно может попытаться декодировать шестнадцатеричную последовательность, затем пропустить байт NUL и продолжить обработку неинициализированной памяти. Листинг 8-5 показывает пример этой ошибки.

Листинг 8-5. Уязвимая процедура шестнадцатеричного декодирования URI

В этом коде выделенная строка содержит простую ошибку: разработчик предполагает, что после символа % следуют два допустимых символа, а это также предполагает, что строка не завершается на этих двух байтах. Однако строки часто имеют более сложную структуру, чем ожидает разработчик. Поскольку несколько переменных состояния влияют на то, как функция разбора интерпретирует текст, появляется больше возможностей совершить такую ошибку. Листинг 8-6 показывает еще один пример ошибки такого типа. Он взят из модуля Apache mod_dav и используется для разбора некоторых HTTP-заголовков.

Листинг 8-6. *Уязвимость обработки заголовка If в модуле Apache mod_dav*

Этот код некорректно проверяет NUL-терминаторы, когда встречает символ N. Ветвь N должна проверять наличие слова Not, а затем пропускать его. Однако код пропускает следующие два символа каждый раз, когда встречает символ N. Атакующий может указать строку заголовка, заканчивающуюся символом N, то есть символом N, за которым следует NUL-символ. Обработка продолжится за NUL-символом, по данным в памяти рядом с разбираемой строкой. Уязвимый путь кода демонстрируется выделенными строками в листинге.

Простые опечатки

Уязвимости обработки текста могут возникать из-за простых ошибок, которые почти не поддаются классификации. Обработку символов легко испортить, и чем сложнее код, тем вероятнее, что разработчик допустит ошибку. Одна из периодических ошибок -- простая ошибка использования указателя: разработчик случайно разыменовывает указатель неправильно или не разыменовывает его, когда это необходимо. Такие ошибки часто являются результатом простых опечаток и особенно распространены при работе с несколькими уровнями косвенности. Листинг 8-7 показывает пример отсутствующего разыменования указателя в модуле Apache mod_mime.

Листинг 8-7. *Ошибка обработки текста в Apache mod_mime*

Этот блок кода находится в функции analyze_ct(), участвующей в разборе содержимого MIME (Multipurpose Internet Mail Extensions). Если функция is_quoted_pair() возвращает значение больше нуля, переменная cp увеличивается на два. Следующий код показывает определение is_quoted_pair():

Обратите внимание: функция должна проверять escape-последовательность из обратной косой черты (\), за которой следует не-NUL байт. Однако программист забыл разыменовать (s + 1), поэтому проверка никогда не завершится неудачей, потому что результат сравнения всегда истинен. Это очень тонкая опечатка -- всего лишь отсутствующий символ *, -- но она полностью меняет смысл кода, приводя к потенциальной уязвимости.

Метасимволы

Для многих типов данных программа также поддерживает метаданные (или метаинформацию), которые отслеживает вместе с основными данными; метаданные -- это просто информация, описывающая или дополняющая основные данные. Они могут включать сведения о том, как форматировать данные для отображения, инструкции обработки или информацию о том, как части данных хранятся в памяти. Есть две основные стратегии представления программных данных вместе с их метаданными: встраивать метаданные внутрь потока данных или хранить их отдельно, вне полосы.

Внутриполосное представление встраивает метаданные в сами данные. При встраивании метаданных в текстовые данные такая информация обозначается специальными символами, называемыми метасимволами или последовательностями метасимволов. Один из простейших примеров внутриполосного представления -- NUL-терминатор в строке C. Внеполосное представление хранит метаданные отдельно от данных и связывает их через некоторый внешний механизм. Строковые типы данных в других языках дают простой пример внеполосных данных. Многие языки программирования (например, C++, Java, PHP, Python и Pascal) не имеют символа-терминатора строки; вместо этого такие языки хранят длину строки во внеполосной переменной.

Во многих отношениях внутриполосное представление является лучшим форматом, поскольку оно часто компактнее и удобнее для чтения человеком. Однако с внутриполосным представлением метаданных связан ряд ловушек безопасности, которые не актуальны для внеполосных метаданных. Эти ловушки существуют потому, что внутриполосное представление создает возможность перекрывающихся доменов доверия там, где требуются явные границы. По сути, внутриполосное представление метаданных помещает и данные, и метаданные в один и тот же домен доверия, а процедуры разбора должны обрабатывать логические границы доверия между данными и метаданными. Однако функции разбора часто очень сложны, и разработчикам бывает крайне трудно учесть последствия безопасности для всех возможных сочетаний данных и метаданных.

До сих пор эта глава обсуждала уязвимости, которые могут возникать из-за неправильной обработки одного внутриполосного метасимвола: NUL-терминатора. Однако в текстовых форматах данных распространены разные внутриполосные представления. Например, метасимвол slash (/) в имени файла указывает начало или конец сегмента пути, метасимвол точка (.) в имени узла указывает поддомен, а метасимвол пробел в ASCII-протоколе часто обозначает конец входного токена. Нередко приложения строят строки, включая в них данные, контролируемые пользователем, как в следующих распространенных ситуациях:

• Построение имени файла

• Построение пути реестра (специфично для Windows)

• Построение адреса электронной почты

• Построение SQL-оператора

• Добавление пользовательских данных в текстовый файл

Следующие разделы рассматривают потенциальные последствия для безопасности, возникающие при недостаточно тщательной очистке пользовательского ввода при построении строк, содержащих метасимволы. Хотя эти разделы охватывают только общие ситуации, далее в главе вы сосредоточитесь на конкретных примерах в современных приложениях, включая печально известные случаи злоупотребления метасимволами.

Встроенные разделители

Самый простой случай уязвимостей метасимволов возникает, когда пользователи могут встроить символы-разделители, используемые для обозначения конца поля. Уязвимости такого рода вызываются недостаточно очищенным пользовательским вводом, включенным в форматированную строку. Например, допустим, у вас есть файл данных с парами имени пользователя и пароля, где каждая строка файла имеет формат username:password.

Можно вывести, что используются два разделителя: символ двоеточия (:) и символ новой строки (\n). Что если у вас есть имя пользователя bob, но можно указать пароль test\nnewuser:newpassword\n? Запись пароля будет записана в файл так:

Можно добавить произвольную новую учетную запись пользователя, что, вероятно, не входило в намерения разработчика для обычных пользователей.

Как же выглядит уязвимое приложение? По сути, вы ищете шаблон, в котором приложение берет пользовательский ввод, недостаточно его фильтрует и использует как вход для функции, интерпретирующей форматированную строку. Обратите внимание, что эта интерпретация может не происходить немедленно: строка может быть записана во вторичное хранилище и интерпретирована позже. Атака такого рода иногда называется "инъекцией второго порядка".

Примечание

Фраза "инъекция второго порядка" была введена для обозначения отложенных SQL-атак и атак cross-site scripting, но она может применяться к любым сохраненным данным с метасимволами, которые интерпретируются позже.

Чтобы увидеть пример приложения, уязвимого к базовой атаке внедрения разделителя, посмотрите листинг 8-8, который содержит код, записывающий показанный выше файл паролей.

Листинг 8-8. Пример встроенного разделителя

Листинг 8-8 не выполняет реальной очистки; он просто записывает предоставленный параметр password в файл, поэтому атакующий может добавить лишние разделители.

В общем случае обнаружение уязвимостей такого рода состоит из нескольких шагов:

1. Найдите код, работающий со строками метасимволов, включая распространенные примеры, представленные на протяжении этой главы. Веб-приложения часто имеют множество строк с метасимволами, потому что постоянно работают с URL, данными сеансов, запросами к базам данных и так далее. Некоторые из этих форматов рассматриваются в этой главе; однако веб-приложения подробнее разбираются в главах 17, "Веб-приложения", и 18, "Веб-технологии".

2. Определите все символы-разделители, которые обрабатываются специальным образом. В зависимости от ситуации разные символы получают специальный смысл. В известных примерах, таких как строки формата и SQL, эта глава указывает символы, о которых нужно знать. Однако в уникальных ситуациях нужно изучать код, интерпретирующий данные, чтобы найти специальные символы.

3. Определите, какая фильтрация выполняется для ввода, и посмотрите, какие символы или последовательности символов фильтруются (как описано далее в этой главе в разделе "Входные фильтры").

4. Исключите из составленного списка потенциально опасные символы-разделители, которые успешно отфильтрованы. Любые оставшиеся разделители указывают на уязвимость.

Используя эту простую процедуру, можно быстро оценить построение строк и определить, какие разделители или специальные последовательности символов могут быть незаметно внедрены во ввод. Последствия возможности внедрить разделители в строку сильно зависят от того, что строка представляет и как она интерпретируется. Чтобы увидеть эту технику в действии, посмотрите листинг 8-9, представляющий CGI-приложение, запускаемое веб-сервером.

Листинг 8-9. Несколько встроенных разделителей

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

1. Найдите код, работающий со строками формата. Входная строка форматируется несколькими способами, прежде чем в итоге становится именем файла. Сначала она добавляется в буфер статического размера и получает префикс "\\\\?\\%TEMP%\\". Затем она передается в ExpandEnvironmentStrings(), где, предположительно, %TEMP% разворачивается во временный каталог. Наконец, она используется как часть имени файла.

2. Определите набор символов-разделителей, которые обрабатываются специальным образом. Прежде всего требуется доступ к специальному файлу или directory traversal, что включает символы вроде '/', '\' и последовательность "..". Также обратите внимание, что строка передается в ExpandEnvironmentStrings(). Переменные окружения обозначаются символами %. Интересно.

3. Определите, какая фильтрация выполняется. Функция strrchr() используется для поиска последнего slash, после чего указатель увеличивается за него. Поэтому slash исключается. Код также специально проверяет последовательность двух точек "..", так что она тоже исключается.

4. Вы исключили все обычные трюки directory traversal, но остается символ %, который интерпретируется ExpandEnvironmentStrings(). Эта интерпретация позволяет подставлять в путь произвольные переменные окружения. Учитывая, что этот код является CGI-программой, клиенты фактически могут передать ряд переменных окружения, например QUERY_STRING. Эта переменная окружения может содержать все последовательности, уже проверенные в исходном имени файла. Если в QUERY_STRING передать "..\..\..\any\pathname\file.txt", клиент сможет записывать в произвольные места файловой системы.

Внедрение NUL-символа

Как вы уже видели, C использует метасимвол NUL как разделитель строки, но языки более высокого уровня (например, Java, PHP и Perl) используют counted strings, где строка содержит свою длину, а NUL-символ не имеет специального смысла. Это различие в интерпретации создает ситуации, где NUL-символ можно внедрить, чтобы управлять поведением C API, вызываемых языками более высокого уровня. На самом деле эта проблема -- частный случай встроенного разделителя, но она достаточно уникальна, чтобы обсудить ее отдельно.

Примечание

Внедрение NUL-байта является проблемой независимо от технологии, потому что на некотором уровне язык counted strings в конечном счете может взаимодействовать с ОС. Даже настоящая среда виртуальной машины, такая как Java или .NET, в итоге вызывает базовые функции ОС для действий вроде открытия и закрытия файлов.

Вы знаете, что NUL-терминированные строки необходимы при вызове процедур C из ОС и многих внешних API. Поэтому уязвимость может существовать, когда атакующие могут включить NUL-символы в строку, которая позже обрабатывается как строка в стиле C. Например, допустим, приложение Perl открывает файл на основе некоторого пользовательского ввода. Приложению нужны только текстовые файлы, поэтому разработчик добавляет фильтр, требующий, чтобы файл заканчивался расширением .txt. Рисунок 8-1 показывает пример допустимого имени файла, размещенного в памяти.

Рисунок 8-1. Строки C в памяти

Но что если один из байтов является NUL-терминатором? В конце концов, Perl не рассматривает NUL-символ как метасимвол. Тогда результирующая строка может выглядеть как на рисунке 8-2.

Рисунок 8-2. Строка C с внедрением NUL-байта в памяти

Функция, отвечающая за открытие этого файла, будет считать первый NUL-байт концом строки, поэтому расширение .txt исчезнет и будет открыт файл bob.

Такой сценарий на самом деле довольно распространен в CGI и серверных языках веб-скриптинга. Проблемы возникают при декодировании шестнадцатерично закодированных данных (подробнее это обсуждается далее в этой главе в разделе "Шестнадцатеричное декодирование"). Если во входе встречается последовательность %00, она декодируется в один NUL-символ. Если NUL-символ не обработан корректно, атакующие могут искусственно усекать строки, одновременно удовлетворяя любым другим требованиям фильтрации. Следующий Perl-код -- простой пример, который может создать измененное имя файла, показанное на рисунке 8-2:

Переменная username в этом коде не проверяется на NUL-символы. Поэтому атакующие могут NUL-терминировать строку и создавать любые расширения файлов по своему выбору. Строка на рисунке 8-2 -- лишь один пример, но NUL-символ можно использовать для эксплуатации сервера. Например, передача execcmd.pl%00 в качестве username создаст файл с именем execcmd.pl. Файл с расширением .pl на многих веб-серверах может использоваться для выполнения произвольного кода.

Большинство программ C/C++ не склонны к внедрению NUL-байтов в пользовательские данные, потому что работают со строками как с обычными массивами символов C. Однако существуют ситуации, где неожиданные NUL-символы могут появляться в строках. Чаще всего это происходит, когда строковые данные читаются напрямую из сети, как показано в листинге 8-10.

Листинг 8-10. Внедрение NUL-байта с порчей памяти

Функция read_string() в листинге 8-10 читает строку и возвращает ее пользователям после удаления завершающих пробельных символов. Однако разработчик предполагает, что строка включает завершающий перевод строки и не содержит NUL-символов (кроме конца). Если первый байт является NUL-символом, код удаляет пробелы перед началом буфера, что может привести к порче памяти.

То же самое можно сказать о работе с файлами. Когда примитивы чтения используются для чтения некоторого количества байтов из файла в буфер, они тоже могут заполнить его неожиданными NUL-символами. Эта ошибка может привести к проблемам вроде описанной выше в листинге 8-10. Например, функция fgets(), используемая для чтения строк из файлов, предназначена для чтения текстовых строк из файла в буфер. То есть она читает байты из файла, пока не произойдет одно из следующего:

• Закончится место в буфере назначения.

• Будет встречен символ новой строки (\n) или конец файла (EOF).

Итак, функция fgets() не прекращает чтение при встрече NUL-байта. Поскольку она специально предназначена для работы со строками, иногда это застает разработчиков врасплох. Следующий пример показывает, как эта функция может стать проблемой:

Этот код написан с предположением, что завершающий символ новой строки нужно удалить. Однако если первый символ является NUL-байтом, этот код записывает еще один NUL-байт перед началом буфера, тем самым повреждая другую переменную или управляющую информацию программы.

Усечение

Ошибки усечения -- одна из самых недооцененных областей обработки строк формата, но они могут давать множество интересных результатов. Разработчики, использующие небезопасные по памяти языки, могут динамически изменять размер памяти во время выполнения, чтобы принять пользовательский ввод, или использовать буферы статического размера на основе ожидаемой максимальной длины ввода. В буферах статического размера ввод, превышающий длину буфера, должен быть усечен, чтобы поместиться в буфер и избежать переполнений. Хотя усечение предотвращает порчу памяти, можно наблюдать интересные побочные эффекты из-за потери данных в укороченной входной строке. Чтобы увидеть, как это работает, допустим, программист заменил вызов sprintf() на вызов snprintf(), чтобы избежать переполнений буфера, как в листинге 8-11.

Листинг 8-11. Уязвимость усечения данных

Функция snprintf() (показанная выделением) в листинге 8-11 безопасна от переполнений буфера, но был внесен потенциально интересный побочный эффект: имя файла может иметь максимум только 64 символа. Поэтому если предоставленное username близко к 60 байтам или превышает их, буфер полностью заполняется и расширение .txt никогда не добавляется. Этот результат особенно интересен в веб-приложении, потому что атакующие могут указать новое произвольное расширение файла (например, .php), а затем напрямую запросить файл у веб-сервера. Тогда файл будет интерпретирован совершенно иначе, чем предполагалось; например, указание расширения .php заставит файл выполняться как PHP-скрипт.

Примечание

Пути файлов -- один из самых распространенных примеров уязвимостей усечения; они могут позволить атакующему отсечь обязательный компонент пути файла (например, расширение файла). Получившийся путь может обойти ограничение безопасности, которое разработчик намеревался реализовать в коде.

Листинг 8-12 показывает немного другой пример усечения путей файлов.

Листинг 8-12. Уязвимость усечения данных 2

Для листинга 8-12 предположим, что вы хотите читать чувствительные файлы в каталоге /data/, но они не заканчиваются на _profile.txt. Даже если можно усечь конец имени файла, чувствительный файл нельзя просмотреть, если имя файла не имеет ровно нужного количества символов, чтобы заполнить этот буфер, верно? На самом деле это неважно, потому что буфер можно заполнить slash-символами. В компонентах имен файлов любое количество подряд идущих slash рассматривается как один разделитель пути; например, /////// и / обрабатываются одинаково. Кроме того, можно многократно использовать запись текущего каталога (.), чтобы заполнить буфер шаблоном вроде ././././././.

Совет по аудиту

Код, использующий snprintf() и аналоги, часто делает это потому, что разработчик хочет объединить данные, контролируемые пользователем, со статическими строковыми элементами. Такое использование может указывать, что можно встроить разделители или выполнить некоторый уровень усечения. Чтобы заметить возможность усечения, сосредоточьтесь на статических данных, следующих за контролируемыми атакующим элементами, которые могут быть чрезмерно длинными.

Еще один момент, который нужно учитывать, -- особенности API-функций при работе с данными, которые им приходится усекать. Вы уже видели примеры низкоуровневых проблем, связанных с памятью, у функций семейства strncpy(), но нужно рассматривать поведение каждой функции, когда она получает данные, не помещающиеся в буфер назначения. Она просто переполняет буфер назначения? Если она усекает данные, корректно ли NUL-терминирует буфер назначения? Есть ли у вызывающего кода способ узнать, что данные были усечены? Если да, проверяет ли вызывающий код это усечение? Эти вопросы нужно задавать при изучении функций, манипулирующих строковыми данными. Некоторые функции ведут себя не так, как ожидается, что приводит к потенциально интересным результатам. Например, функция Windows GetFullPathName() имеет следующий прототип:

Эта функция получает полный путь lpFileName и сохраняет его в lpBuffer, длина которого составляет nBufferLength элементов TCHAR. Затем она возвращает длину выведенного пути или 0 при ошибке. Что происходит, если полный путь длиннее nBufferLength элементов TCHAR? Функция оставляет lpBuffer нетронутым (неинициализированным) и возвращает число элементов TCHAR, необходимых для хранения полного пути. Такой случай отказа обрабатывается очень неинтуитивно. Листинг 8-13 показывает корректный вызов этой функции.

Листинг 8-13. *Корректное использование GetFullPathName()*

Как вы, вероятно, уже догадались, вызывающий код нередко ошибочно проверяет только то, равно ли возвращаемое значение 0, и забывает проверить, не больше ли код возврата указанной длины. В результате, если параметр lpFileName достаточно длинный, вызов GetFullPathName() вообще не трогает выходной буфер, а программа использует неинициализированную переменную как путь. Листинг 8-14 из кодовой базы Apache 2.x показывает уязвимый вызов GetFullPathName().

Листинг 8-14. *Вызов GetFullPathName() в Apache 2.2.0*

В листинге 8-14 видно, что случай усечения не проверяется. В результате переменная wroot может быть использована, хотя GetFullPathName() мог ее не инициализировать. Можно встретить и другие функции с похожим поведением, поэтому держите глаза открытыми.

Примечание

ExpandEnvironmentStrings() -- одна из функций, ведущих себя похоже на GetFullPathName().

Распространенные форматы метасимволов

В предыдущем разделе вы изучили некоторые базовые проблемы построения строк с метасимволами из данных, поддающихся изменению пользователем. Следующие разделы представляют конкретные вопросы для ряда распространенных форматов метасимволов. Это ни в коем случае не исчерпывающий список, но он охватывает несколько самых распространенных форматов. Изучение этих форматов должно закрепить предыдущее обсуждение и дать контекст, необходимый для выявления уязвимых случаев в форматах метасимволов, не рассмотренных здесь.

Метасимволы путей

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

Многие системы организуют объекты в некоторую иерархию, которую можно представить текстово, построив строку, где каждый компонент иерархического пути отделен последовательностью-разделителем. Для файловых систем таким разделителем обычно является прямой slash (/) в UNIX или обратный slash (\) в Windows. Наличие этих символов-разделителей в недоверенном вводе может вызвать уязвимости, если программа не обрабатывает их должным образом. Эксплуатация таких уязвимостей может позволить атакующему получить доступ к объектам, которых разработчик не хотел открывать. Как аудитор кода, вы должны определять, когда программы обращаются к ресурсам небезопасно, то есть когда недоверенный пользовательский ввод используется для построения компонентов пути к ресурсу и когда этот ввод можно использовать для указания объектов, которые не должны быть доступны. В качестве быстрой проверки полезно перечислить ресурсы, к которым приложение должно иметь доступ, и сравнить этот список с тем, что приложение фактически разрешает.

При изучении кода, работающего с каноникализацией путей, помните, что введенные ранее проблемы усечения особенно релевантны: часто есть возможность отсечь элементы пути, например расширения файлов или подключи для объектов реестра.

Каноникализация файлов

Приложения часто получают имена файлов или пути, которые затем создаются или открываются для обработки. CGI-скрипты и серверные веб-приложения, HTTP-серверы, LPD-серверы, FTP-серверы и привилегированные локальные процессы -- лишь несколько примеров мест, где имена файлов поступают из недоверенных источников. Приложения, которые не проверяют недоверенные имена файлов адекватно, могут в итоге раскрыть клиентам чувствительные данные или, что хуже, позволить им записывать данные в файлы, к которым у них не должно быть доступа, что может привести к полной компрометации системы.

Каждый файл в файловой системе имеет базовое строковое представление, уникально определяющее его местоположение. Обычно это представление состоит из имени устройства (необязательно), за которым следует абсолютный путь, например:

Устройство обозначается C:, затем идет абсолютный путь, где находится файл, \WINDOWS\system32, и имя файла calc.exe. Хотя этот метод является самым простым способом сослаться на данный файл, он, конечно, не единственный. На самом деле существует много способов сослаться на тот же файл, как показано в этих примерах:

Процесс преобразования всех этих разных представлений в простейшую форму называется каноникализацией файла. Когда приложение запрашивает операцию открытия файла, ядро разрешает путь и проверяет разрешения на каждом иерархическом уровне, пока не будет найден файл назначения. Однако приложение может оказаться под угрозой при построении имен файлов из данных недоверенных источников, например если оно неправильно предвидит, как ядро разрешает запрошенный путь файла. Тема каноникализации файлов широка и существенно различается в Windows и UNIX. Поэтому в этом разделе рассматриваются общие проблемы, а детали UNIX и Windows разбираются в главе 9, "UNIX I: привилегии и файлы", и главе 11, "Windows I: объекты и файловая система".

Самая распространенная эксплуатация имен файлов происходит, если приложение забывает проверить directory traversal. В этом случае атакующий обращается к родительскому каталогу с помощью пути "..". Когда приложение строит путь, включающий пользовательский ввод, иногда им можно манипулировать так, чтобы приложение непреднамеренно создавало или открывало файлы вне подкаталога, которым операции с файлами должны были быть ограничены. Приложения уязвимы к этим проблемам, когда не проверяют directory traversal специально или не выполняют полную каноникализацию пути перед проверкой, что он находится в ожидаемых границах файловой системы. Листинг 8-15 показывает простой пример на Perl.

Листинг 8-15. Уязвимость directory traversal

Скрипт в листинге 8-15 пытается открыть профиль пользователя, который предположительно находится в каталоге /users/profiles, но не выполняет никакой очистки переменной username, получаемой напрямую из строки запроса текущего обслуживаемого веб-запроса. Это означает, что атакующие могут просто указать имя пользователя ../../../../../etc/passwd и использовать этот скрипт для вывода файла паролей (или любого другого файла по своему выбору).

Как уже упоминалось, проблемы обработки путей можно диагностировать, сопоставляя ресурсы, необходимые программе, с ресурсами, к которым она фактически способна обращаться. В листинге 8-15 ресурсы, к которым программа намерена обращаться, -- это профили пользователей (любые файлы в каталоге /users/profiles). Однако, учитывая то, что вы знаете о traversal файловой системы, видно, что ресурсы, доступные этой программе, потенциально включают любые файлы в системе, в зависимости от пользовательского контекста процесса.

Реестр Windows

Операционные системы Windows используют реестр как центральное хранилище общесистемных настроек, которые программы могут свободно запрашивать и изменять для своих целей. Ниже перечислены базовые функции манипуляции реестром Windows:

• **RegOpenKey() и RegOpenKeyEx():** эти функции используются для открытия ключа реестра, который затем может использоваться в запросах значений.

• **RegQueryValue() и RegQueryValueEx():** эти функции используются для чтения данных из указанного ключа реестра.

• **RegCreateKey() и RegCreateKeyEx():** эти функции используются для создания нового подключа.

• **RegDeleteKey(), RegDeleteKeyEx() и RegDeleteValue():** первые две функции используются для удаления подключа из реестра. RegDeleteValue() оставляет ключ нетронутым, но удаляет связанное с ним значение.

При обработке путей реестра есть несколько важных соображений. Первая серьезная проблема -- усечение при работе с фиксированными буферами. Атакующие могут отсечь часть ключа и заставить программу запросить неправильный ключ. Следующий запрос реестра уязвим к усечению:

Эта программа читает конфигурационный параметр, используя строку версии, переданную в данных с удаленного узла. Если строка версии достаточно длинная, она может заполнить буфер и усечь завершающий subkey2. Как и файлы, ключи реестра могут иметь несколько slash для разделения элементов подключей, поэтому "\\SOFTWARE\\MyProduct" эквивалентно "\\SOFTWARE\\\\\\\\MyProduct" при доступе к ключу. Кроме того, завершающие slash тоже усекаются, так что "\\SOFTWARE\\MyProduct" также эквивалентно "\\SOFTWARE\\MyProduct\\\\\\\\". Следовательно, всякий раз, когда недоверенные данные используются как часть ключа реестра, существует опасность усечения.

Примечание

Строка подключа, передаваемая в RegOpenKey() и RegOpenKeyEx(), может иметь длину не более MAX_PATH символов. Если строка длиннее, функция возвращает ошибку.

Как вы, вероятно, уже догадались, если атакующие могут передавать дополнительные разделители подключей (\), они могут использовать их для запроса произвольных подключей или даже базового ключа в строке. Единственное смягчающее обстоятельство состоит в том, что ключи реестра открываются в два этапа: сначала должен быть открыт ключ, а затем конкретное значение изменяется другим набором функций. Однако этот двухэтапный процесс не отменяет уязвимость усечения, потому что атака все еще может быть жизнеспособной в следующих ситуациях:

• Атакующий может напрямую манипулировать именем ключа.

• Атакующий хочет манипулировать ключами, а не значениями.

• Приложение использует API более высокого уровня, которое скрывает разделение ключа и значения.

• Атакующий хочет манипулировать значением по умолчанию (безымянным).

• Имя значения соответствует значению, которым атакующий хочет манипулировать в другом ключе.

Строки формата C

Строки формата -- это класс ошибок в семействах функций printf(), err() и syslog(). Все эти функции преобразуют и печатают значения данных разных типов в место назначения (строку или файловый поток). Выходные данные форматируются согласно строке формата, которая содержит буквальные данные, и спецификаторам формата, указывающим, где элемент данных должен быть вставлен в поток и в какой тип данных он должен быть преобразован и выведен. Поэтому эти функции принимают переменное число аргументов в соответствии с количеством спецификаторов формата в строке формата. Следующий код показывает пример вызова функции fprintf():

Этот код печатает строку (спецификатор формата %s) и системную ошибку (спецификатор формата %m).

Примечание

Спецификатор формата %m -- исключение из правила, что каждому спецификатору формата соответствует аргумент. Он печатает строку системной ошибки на основе значения глобального индикатора ошибки errno.

Проблемы возникают, когда недоверенный ввод используется как часть или вся строка формата в любой из упомянутых выше функций. Очевидно, если пользователи могут передать спецификаторы формата, которых не ожидали, соответствующих аргументов не существует, а отображаемые значения основаны на случайных данных, которые оказались на стеке программы. Это может позволить пользователям увидеть стек программы или даже аварийно завершить программу, используя спецификатор формата, ожидающий соответствующий аргумент-указатель (например, %s, который ожидает существования указателя на символы на стеке). Кроме того, один спецификатор формата создает еще больше проблем: %n. Спецификатор %n уникален тем, что не записывает никаких данных в выходной поток; вместо этого он принимает соответствующий аргумент-указатель на целое число, которому присваивается количество символов, выведенных к текущему моменту. Легитимное использование %n выглядит так:

Печатается строка test, а количество выходных символов записывается в num (в данном случае четыре). Однако этот спецификатор формата очень полезен атакующим. Спецификатор %n можно эксплуатировать для записи произвольного значения в произвольное место памяти, что обычно приводит к выполнению кода, контролируемого атакующим, в текущем процессе.

При аудите кода нужно убедиться, что ни один вызов этих функций не имеет строки формата, полученной из недоверенного ввода. Можно подумать, что программа, позволяющая пользователям задавать строку формата, маловероятна: в конце концов, зачем разработчикам хотеть, чтобы пользователи могли задавать преобразования формата? Однако это происходило в ряде приложений. Один из самых известных примеров -- команда SITE EXEC популярного демона WU-FTP. Основная проблема в том, что контролируемые пользователем данные передаются функции lreply(), как показано ниже:

В этом коде пользователь напрямую контролирует переменную cmd. Листинг 8-16 показывает, что происходит в lreply().

Листинг 8-16. Уязвимость строки формата в WU-FTPD

Как видно, второй аргумент lreply() -- это строка формата, напрямую передаваемая в vreply(); затем функция vreply() передает эту строку как спецификатор формата в vsnprintf(). Этот пример показывает, как обычно возникают уязвимости строк формата. Они чаще всего появляются, когда функция принимает переменное число аргументов и передает эти данные API-функции для форматирования. Такой тип кода чаще всего встречается в процедурах журналирования, как показано в листинге 8-17.

Листинг 8-17. Уязвимость строки формата в процедуре журналирования

Листинг 8-17 показывает процедуру журналирования, которая форматирует данные и передает результат в syslog(). Однако syslog() тоже выполняет форматирование, поэтому этот код уязвим к атаке на строку формата.

Совет по аудиту

При попытке найти уязвимости строк формата ищите все экземпляры функций printf(), err() или syslog(), которые принимают нестатический аргумент строки формата, а затем прослеживайте аргумент формата назад, чтобы увидеть, может ли какая-либо его часть контролироваться атакующими.

Если функции приложения принимают переменные аргументы и без проверок передают их в функции printf(), syslog() или err(), ищите каждый экземпляр их использования с нестатическими аргументами строки формата так же, как искали бы printf() и так далее.

Поскольку поиск строк формата -- довольно прямолинейный процесс, создать программы, способные анализировать код (как исходный, так и бинарный) и автоматически находить эти уязвимости, не слишком сложно. Многие инструменты статического анализа имеют такую возможность, включая обсуждавшиеся в главе 2. Использование этих инструментов может быть полезным при проверке, безопасен ли код от атак на строки формата.

Метасимволы shell

Часто приложение вызывает внешнюю программу для выполнения задачи, на которой эта внешняя программа специализируется, как в следующих примерах:

• CGI-скрипт запускает почтовую программу для отправки собранных данных формы.

• Изменение информации учетной записи в системе может включать запуск редактора (например, chpass).

• Демоны запланированного выполнения (cron и at) вызывают запланированные к запуску программы, а также почтовую программу для отправки результатов (в некоторых случаях).

• Серверные веб-приложения могут вызывать внешние программы для некоторой back-end обработки.

Эти примеры -- лишь несколько возможностей. Выполнение внешних приложений происходит часто и может быть подвержено проблемам безопасности. Программы обычно запускаются двумя способами: прямым запуском программы с помощью функции вроде execve() или CreateProcess() либо запуском через командный shell с функциями вроде system() или popen(). Запуск процесса через системный вызов exec() заменяет текущий выполняющийся процесс новым или, возможно, порождает новый экземпляр процесса (как в CreateProcess()), например так:

В этом случае приложение пытается отправить email; однако после вызова execve() текущее приложение заменяется процессом sendmail. Это не дает исходному процессу записать данные письма. Чтобы это сделать, программист должен создать новый процесс через fork и настроить pipe descriptors. В качестве другого варианта программа может просто запустить sendmail через shell-интерфейс popen(). Второй вариант выполняет всю настройку и обработку pipe внутри себя и гораздо проще в кодировании. Листинг 8-18 показывает пример.

Листинг 8-18. Уязвимость внедрения метасимволов shell

При открытии команд этим методом любой ввод подлежит интерпретации shell, поэтому при появлении некоторых символов во входном потоке могут быть нежелательные последствия. Чтобы лучше понять эти последствия, вернитесь к следующей строке из листинга 8-18:

Когда popen() запускает эту команду, он фактически строит следующую командную строку (предполагая, что переданный email-адрес равен user@host.com):

Программа запускается через командный shell (sh), и любые метасимволы shell интерпретируются так же, как если бы они были введены в командной строке или shell-скриптах. Возвращаясь к предыдущему примеру, что если имя пользователя задано так?

Командная строка, которую теперь строит popen(), выглядит так:

Точка с запятой (;) интерпретируется как разделитель команд, поэтому передача такого имени пользователя не просто открывает sendmail, как предполагалось; она также отправляет xterm на удаленный узел. Разбор метасимволов shell при использовании popen() и похожих вызовов представляет непосредственную угрозу приложению, когда недоверенные данные используются для построения командной строки. При аудите приложений, использующих возможности shell, нужно определить, могут ли произвольные команды выполняться через внедрение метасимволов. Поскольку shell обладает обширными возможностями сценариев, атакующим может быть полезно довольно много символов. Следующий список показывает обычных подозреваемых.

Опасные символы shell

Разные shell интерпретируют данные по-разному, поэтому этот список не полон, но он охватывает самые распространенные символы. Конечно, не все эти символы опасны во всех ситуациях.

Также нужно внимательно относиться к запускаемому приложению. Некоторые приложения по своей природе опасны, в зависимости от их функции и реализации. Часто существуют ограничения на передачу данных таким приложениям; однако запускаемое приложение потенциально представляет новую точку воздействия для вызывающего кода. (Помните: цепь настолько прочна, насколько прочно ее самое слабое звено.) Кроме того, вызываемое приложение может иметь собственную внутриполосную обработку управляющих данных. Один заметный пример -- почтовая программа, как показано в листинге 8-19.

Листинг 8-19. Пример опасного использования программы

Для этого примера предположим, что email-адрес был адекватно отфильтрован. Безопасна ли программа? Нет. Почтовая программа интерпретирует строки, начинающиеся с тильды (~), как команду для запуска, поэтому если задать имя или адрес значением \n~xterm -display 1.2.3.4:0, почтовая программа породит xterm.

Очевидно, поддерживать подробное знание внутренней работы всех программ на платформе или даже всех приложений, написанных вашей командой, может быть весьма сложно. Несмотря на эту трудность, когда разработчики решают вызвать другое приложение, они пересекают границу доверия и полностью передают управление за пределы своего приложения. Такая передача управления создает возможность того, что вызываемая программа подорвет все ограничения безопасности вызывающего приложения. По этой причине стоит потратить время на изучение программ, создаваемых аудируемым приложением, особенно если в эти программы передается недоверенный ввод.

Наконец, помните, что ввод не обязательно должен передаваться внешней программе напрямую, чтобы создавать уязвимости. Атакующие могут неблагоприятно влиять на приложение рядом других способов, в зависимости от того, как вызывается программа и в каком окружении она работает. Однако эти детали обычно специфичны для ОС, поэтому они подробнее рассматриваются в главах 9-12.

Perl open()

Стоит отметить многоцелевые возможности функции Perl open(). Эта функция может открывать и файлы, и процессы, поэтому выполняет работу функций C open() и popen(). Функцию open() можно вызывать с тремя аргументами (file handle, режим и имя файла) или с двумя аргументами (file handle и имя файла). Второй метод определяет режим открытия файла, интерпретируя метасимволы, которые могут находиться в начале или конце имени файла. Эти символы режима, перечисленные в таблице 8-1, также могут указать, что вызов open() должен запустить данные как команду, а не открыть файл.

**Таблица 8-1. Интерпретация символов режима в функции Perl open()**

Когда символы режима не указаны, файл открывается только для чтения, как если бы файловый аргумент содержал начальный <. Однако такая практика программирования опасна, потому что если атакующие могут указать имя файла (или хотя бы начальный компонент имени файла), они могут выбрать режим, в котором файл будет открыт. Вот пример опасного вызова:

Второй аргумент не содержит начальных символов режима, позволяя пользователям задавать произвольные символы режима. Самый опасный -- символ pipe, который приводит к выполнению произвольной команды. Например, указав username как "| xterm -d 1.2.3.4:0;", пользователи могут породить удаленный xterm этим скриптом. То же самое применимо, если можно указать последнюю часть имени файла, как в следующем примере:

В этом случае удаленного выполнения можно добиться, задав username вроде "blah; xterm -d 1.2.3.4:0 |". Если пользователи не могут контролировать начало или конец имени файла, они не могут вставить pipe для запуска команд.

Примечание

Можно подумать, что если атакующие контролируют небольшой объем данных в середине файлового аргумента, они могут добиться удаленного выполнения, указав аргумент вроде "blah; xterm -d 1.2.3.4:0|%00" и используя технику внедрения NUL-байта. Хотя эта техника отсекает любые символы после переменной, Perl не интерпретирует pipe (|) как последний символ имени файла, поэтому pipe не создается.

Также помните, что режим +> открывает файл для чтения и записи и усекает файл до 0 байт. Этот режим несколько уникален, потому что файл можно изменить. Допустим, недоверенные данные передаются как переменная username в следующем вызове:

Если переменная username начинается с >, файл открывается в режиме добавления и не усекается. В зависимости от особенностей приложения этот результат может иметь интересные последствия, например чтение данных, созданных предыдущим пользовательским сеансом.

Помимо этого особого случая, если режим открытия файла указан, вызов безопасен, верно? Нет, есть еще кое-что. Функция Perl open() также умеет дублировать файловые дескрипторы. Если за аргументом режима следует амперсанд (&) и имя известного file handle (STDIN, STDOUT, STDERR), open() дублирует файловый дескриптор с соответствующим режимом (например, с начальным < для STDOUT). Кроме того, можно указать любой номер файлового дескриптора с помощью синтаксиса &=<fd number>. Рассмотрите этот пример:

Этот фрагмент кода предполагает, что файл ADMIN не был закрыт к моменту второго вызова open(). Он позволяет атакующим записывать в файл /data/admin/admin.conf. Им нужно только знать правильный номер файлового дескриптора и передать его как значение userprofile, например &=3, если admin.conf открыт как файловый дескриптор 3. Обратите внимание, что вызов open() может быть эксплуатируемым и в следующем примере:

Если атакующие могут вставлять NUL-байты, они могут передать значение userprofile как &=3, и файловый дескриптор будет корректно продублирован. Однако трехаргументная версия open() сделала бы этот код больше неуязвимым, потому что она требует явно задать режим во втором параметре. Поэтому трехаргументные вызовы open() в основном можно считать безопасными.

Совет по аудиту

Вы можете найти уязвимость, позволяющую продублировать файловый дескриптор. Если у вас есть доступ к окружению, похожему на то, в котором выполняется скрипт, используйте lsof или похожий инструмент, чтобы определить, какие файловые дескрипторы открыты при работе процесса. Этот инструмент поможет понять, к чему вы потенциально можете получить доступ.

SQL-запросы

SQL -- стандартный язык взаимодействия с системой управления реляционными базами данных (RDBMS). Скорее всего, вы встречаете SQL в контексте веб-приложений, когда изучаете серверные скрипты или приложения, которые обрабатывают ввод из браузеров и отправляют запросы к back-end базе данных. Некорректная обработка ввода для таких запросов может приводить к серьезным уязвимостям. Это обсуждение сосредоточено на динамически построенных запросах в обычном синтаксисе SQL. Глава 17, "Веб-приложения", расширяет этот материал, охватывая параметризованные запросы и хранимые процедуры.

Самая распространенная уязвимость, связанная с SQL, -- SQL injection. Она возникает, когда ввод берется из данных запроса (POST-переменных, форм или cookie) и конкатенируется в строку запроса, отправляемого базе данных. Листинг 8-20 -- простой пример на PHP и MySQL.

Листинг 8-20. Уязвимость SQL injection

Этот запрос уязвим к SQL injection, потому что пользователи могут передавать нефильтрованный ввод для переменных passwd и username. Атакующие легко могут отправить строку вроде следующей для обоих параметров:

В результате к базе данных будет отправлен такой запрос:

В этом примере атакующие используют то, что скрипт не фильтрует символ одинарной кавычки ('), позволяющий им передать закрывающую кавычку и включить собственные SQL-операторы. Конечно, одинарная кавычка -- не единственный способ манипулировать SQL-запросом. Работа с неограниченными целочисленными полями (или любыми данными, не заключенными в кавычки) тоже может вызывать проблемы. Разработчики не ожидают, что такие поля будут содержать нечисловые данные, поэтому часто не проверяют другие типы данных, особенно если данные берутся из скрытого поля или cookie. Рассмотрите этот пример:

Этот пример похож на предыдущий, за исключением того, что значение order_id получено из скрытой переменной, которая должна содержать целочисленное значение. Этот оператор можно скомпрометировать, передав для hid_order_id значение вроде:

В этом случае можно ожидать, что приложение вернет все заказы в системе.

Примечание

PHP и MySQL предоставляют механизмы очистки строк, помогающие снизить риск этой атаки. Примеры фильтрующих функций: mysql_real_escape_string(), dbx_escape_string() и pg_escape_string(). Однако фильтрация -- не самый надежный способ решить эту проблему, поскольку это все еще внутриполосное представление, которое может быть уязвимо к непредвиденным векторам атаки и ошибкам в процедурах фильтрации. Глава 17 обсуждает параметризованные запросы как внеполосный метод запросов, обеспечивающий более эффективную защиту.

Последствия уязвимостей SQL injection различаются в зависимости от RDBMS и структуры базы данных. Некоторые базы данных ограничивают внедренные запросы областью исходного оператора; например, уязвимость в операторе Oracle SELECT позволяет внедрять только дополнительные SELECT или вызовы функций. На другом конце спектра некоторые базы данных дают внедренному оператору почти неограниченную функциональность; Microsoft SQL Server позволяет завершить текущий оператор точкой с запятой, а затем добавить другой оператор.

Во многих случаях содержимое базы данных является конечной целью атакующих, поэтому им подходит любая уязвимость, дающая произвольное взаимодействие с базой данных. Однако атака может быть расширена и на хост-систему. Многие реализации RDBMS имеют хранимые процедуры для запуска системных команд или произвольных процессов. Атакующие могут использовать эти процедуры, если сеансу базы данных явно не запрещен доступ. Если этот подход не сработает, сама реализация RDBMS может раскрывать уязвимости. Многие хранимые процедуры и функции реализованы на других языках, что может открывать множество других потенциальных уязвимостей (подробнее обсуждается в главе 17).

Также может потребоваться учитывать проблемы усечения, которые способны привести к SQL injection, как и при обработке файлов. Эта ошибка может возникать в языках, использующих буферы фиксированного размера: атакующие могут заполнить буфер настолько, чтобы устранить завершающие условия. Конечно, большинство разработчиков предпочитают использовать языки с counted string classes при работе с SQL-запросами. Тем не менее стоит помнить об этой атаке, если вы встретите C/C++ front end, манипулирующий SQL. Листинг 8-21 показывает пример.

Листинг 8-21. Уязвимость усечения SQL

Предположим, что функция search_orders() в листинге 8-21 позволяет пользователям искать только по собственным заказам, но не по чужим. Функция escape_sql() не дает пользователям внедрять управляющие символы, а переменная sess_account предоставляется из сеанса. Это означает, что пользователи могут манипулировать только длиной и содержимым переменной post_detail. Однако они могут дополнить post_detail достаточным количеством знаков процента (%), чтобы snprintf() отсекла условие AND, ограничивающее запрос текущими пользователями. Получившийся запрос извлечет все заказы независимо от пользователя.

Фильтрация метасимволов

Потенциальные проблемы, связанные с метасимволами, часто требуют более оборонительной стратегии программирования. Обычно эта стратегия включает попытку обнаружить потенциальные атаки или очистить ввод до его интерпретации. Есть три базовых варианта:

• Обнаружить ошибочный ввод и отклонить то, что похоже на атаку.

• Обнаружить и удалить опасные символы.

• Обнаружить и закодировать опасные символы escape-последовательностью метасимвола.

Каждый из этих вариантов полезен по-своему, и каждый открывает возможность новых уязвимостей. Первые два варианта пытаются полностью устранить метасимволы, поэтому у них есть общие черты, рассматриваемые в следующем разделе. Третий вариант включает ряд уникальных вопросов, поэтому он обсуждается отдельно в разделе "Экранирование метасимволов".

Устранение метасимволов

Отклонение недопустимых запросов и удаление опасных символов -- похожие стратегии; обе включают пропуск пользовательских данных через некоторую процедуру очистки, часто с использованием регулярного выражения. Если запрещенный ввод отклоняется, любой запрос, содержащий незаконные метасимволы, просто отбрасывается. Такой подход обычно включает некоторую ошибку, объясняющую, почему ввод не разрешен, как показано в этом примере:

В этом примере переменная input_data проверяется на наличие любого символа, который не является буквенно-цифровым, подчеркиванием или пробелом. Если такие символы найдены, сигнализируется ошибка и обработка завершается.

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

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

Оба подхода должны учитывать, насколько сильна их реализация фильтра; если они не ловят весь опасный ввод, все последующее уже мало что значит. Есть два основных типа фильтров: фильтры явного запрета (black lists) и фильтры явного разрешения (white lists). При фильтре явного запрета все данные считаются допустимыми, кроме конкретных символов, признанных опасными. Листинг 8-22 -- пример реализации фильтра явного запрета.

Листинг 8-22. Фильтр символов по черному списку

Как видно, этот фильтр разрешает любые символы, кроме входящих в набор bad_characters. И наоборот, фильтр явного разрешения проверяет символы, заведомо допустимые, а все остальное считается недопустимым, как показано в листинге 8-23.

Листинг 8-23. Фильтр символов по белому списку

Этот пример похож на листинг 8-22, но проверяет наличие каждого символа в наборе допустимых символов, а не ищет недопустимые символы. Фильтры по белому списку по своей природе гораздо более ограничительны, поэтому обычно считаются более безопасными. Однако когда набор допустимого ввода велик, фильтр явного запрета может быть уместнее.

При ревью кода, содержащего фильтры любого вида, нужно определить, не забыло ли приложение учесть какой-либо опасный ввод. Для этого следует выполнить такие шаги:

1. Составьте список всего ввода, разрешенного фильтром.

2. Составьте список всего ввода, опасного, если он останется во входном потоке.

3. Проверьте, есть ли результаты пересечения этих двух списков.

Шаг 1 прямолинеен и может быть выполнен простым чтением кода; однако шаг 2 может потребовать больше творческого подхода. Чем больше вы знаете о компоненте или программе, интерпретирующей данные, тем более тщательный анализ сможете выполнить. Следовательно, хороший аудитор кода должен быть знаком с любыми форматами данных, встречающимися при оценке. Например, shell-программирование и SQL -- форматы метаданных, часто используемые в веб-приложениях.

Недостаточная фильтрация

Когда у вас уже есть глубокое знание форматов, с которыми вы работаете, обычно возникает соблазн не составлять списки разрешенного ввода. Вместо этого можно опереться на имеющиеся знания для оценки силы фильтра. Такой подход может быть достаточным, но он также повышает вероятность пропустить тонкие уязвимости, как и разработчик приложения. Например, посмотрите листинг 8-24, демонстрирующий уязвимость фильтрации в сервере PCNFSD.

Листинг 8-24. Уязвимость метасимволов в PCNFSD

Фильтр создан для удаления опасных символов перед передачей данных в popen(). У разработчиков довольно полный набор запрета, но они пропустили один символ. Видите какой? Верно: символ новой строки ('\n'). Если во входной поток вставить символ новой строки, shell рассматривает данные до него как одну команду, а данные после него -- как новую команду, тем самым позволяя атакующим выполнять произвольные команды. Этот пример интересен потому, что символ новой строки часто забывают при фильтрации данных для проблем shell-выполнения. Люди думают о других разделителях команд, например точках с запятой, но часто забывают отфильтровать символ новой строки; это демонстрирует, что даже опытные программисты могут хорошо знать систему и все равно допускать упущения, приводящие к уязвимостям.

Даже когда формат вам знаком, нужно помнить о разных реализациях или версиях программы. Уникальные расширения могут создавать возможность вариаций стандартных атак, а данные могут интерпретироваться больше одного раза по разным правилам. Например, при очистке ввода для вызова popen() нужно понимать, что любые данные, переданные вызываемой программе, интерпретируются командным shell, а затем повторно и иначе интерпретируются выполняемой программой.

Уязвимости удаления символов

При удалении недопустимых символов вместо простого отклонения запроса возникают дополнительные риски. Причина в том, что у разработчиков появляется больше возможностей ошибиться. Помимо пропуска потенциально опасных символов, они могут ошибиться в реализации процедур очистки. Иногда реализации должны фильтровать многосимвольные последовательности; например, рассмотрите CGI-скрипт, который открывает файл в серверном каталоге данных. Разработчики хотят позволить пользователям открывать любой файл в этом каталоге и, возможно, даже данные в подкаталогах ниже него. Поэтому и точка (.), и slash (/) являются допустимыми символами. Но они, конечно, не хотят разрешать имена файлов, предоставленные пользователем, вне каталога данных, например ../../../etc/passwd; поэтому разработчики удаляют вхождения последовательности ../. Реализация такого фильтра показана в листинге 8-25.

Листинг 8-25. Уязвимость при фильтрации последовательности символов

К сожалению, у этого алгоритма фильтрации есть серьезный изъян. Когда встречается ../, оно удаляется из потока копированием остального пути поверх ../. Однако указатель src увеличивается на три байта, поэтому он не обрабатывает три байта, непосредственно следующие за последовательностью ../. Следовательно, чтобы обойти фильтр, атакующему достаточно поместить одно двойное многоточие сразу после другого, потому что второе будет пропущено. Например, ввод ../../test.txt преобразуется в ../test.txt. Листинг 8-26 показывает, как исправить некорректный фильтр.

Листинг 8-26. Уязвимость при фильтрации последовательности символов #2

Теперь алгоритм удаляет последовательности ../, но видите ли вы, что проблема все еще есть? Что произойдет, если передать файловый аргумент вроде ....//hi? Таблица 8-2 пошагово проходит алгоритм.

**Таблица 8-2. Ручная проверка clean_path с вводом ....//hi**

Этот алгоритм демонстрирует тонкую проблему, распространенную во многих многосимвольных фильтрах, удаляющих недопустимый ввод. Передавая символы вокруг запрещенных шаблонов так, чтобы после удаления они складывались в запрещенный шаблон, вы заставляете сам фильтр построить вредоносный ввод, удалив промежуточные байты.

Совет по аудиту

При аудите многосимвольных фильтров попытайтесь определить, возможно ли построить недопустимые последовательности через создание встроенных недопустимых шаблонов, как в листинге 8-26.

Также обратите внимание, что такие атаки возможны, когда разработчики используют один шаблон подстановки с регулярными выражениями, например:

Этот подход распространен в нескольких языках программирования (особенно Perl и PHP).

Экранирование метасимволов

Экранирование опасных символов отличается от других методов фильтрации, потому что по сути является неразрушающим. То есть оно не запрещает и не удаляет метасимволы, а обрабатывает их в более безопасной форме. Методы экранирования различаются между форматами данных, но самый распространенный способ -- добавить escape-метасимвол (обычно обратный slash) перед любыми потенциально опасными метасимволами. Этот метод позволяет безопасно интерпретировать такие символы как двухсимвольную escape-последовательность, так что приложение не будет интерпретировать метасимвол напрямую.

При ревью таких реализаций нужно внимательно относиться к escape-символу. Если этот символ не обрабатывается осторожно, его можно использовать для подрыва остального фильтра символов. Например, следующий фильтр предназначен для экранирования кавычек из MySQL-запроса с использованием обратного slash как escape-метасимвола:

Этот запрос заменяет опасные символы кавычек экранированной версией символа. Например, username:

будет заменен на:

Поэтому атакующие не смогут выйти за пределы одинарных кавычек и скомпрометировать приложение. Однако шаблон регулярного выражения забывает экранировать символ обратного slash (\), поэтому у атакующих остается путь атаки через передачу следующего:

После фильтрации этот ввод создаст следующий запрос:

Сервер MySQL интерпретирует последовательность двойного обратного slash после bob как экранированный обратный slash. Это не дает вставленному обратному slash экранировать одинарную кавычку, позволяя атакующему изменить запрос.

Примечание

Escape-символы различаются между реализациями SQL. Обычно база данных поддерживает escape-последовательности slash-quote (\') или двойного апострофа (''). Однако разработчики могут перепутать, какая escape-последовательность поддерживается, и случайно использовать неверную последовательность для целевой базы данных.

Обход метасимволов

Одно из самых интересных последствий экранирования метасимволов для безопасности состоит в том, что закодированные символы можно использовать для обхода других механизмов фильтрации. Как аудитор кода, вы должны определить, когда данные могут быть закодированы способом, подрывающим безопасность приложения. Для этого нужно связывать фазы декодирования с релевантными решениями безопасности и последующими действиями в коде. Следующие шаги -- базовая процедура:

1. Определите каждое место в коде, где экранированный ввод декодируется.

2. Определите связанные решения безопасности, основанные на этом вводе.

3. Если декодирование происходит после принятия решения, у вас проблема.

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

Шестнадцатеричное кодирование

HTTP подробнее обсуждается в последующих главах; однако это обсуждение кодирования было бы неполным без стандартной формы кодирования для URI и данных запросов. В основном все буквенно-цифровые символы передаются напрямую через HTTP, а все остальные символы (исключая управляющие) экранируются с помощью трехсимвольной схемы кодирования. Эта схема использует символ процента (%), за которым следуют две шестнадцатеричные цифры, представляющие значение байта. Например, символ пробела (шестнадцатеричное значение 0x20) использует трехсимвольную последовательность %20.

HTTP-транзакции также могут включать Unicode-символы. Детали Unicode рассматриваются далее в этой главе в разделе "Наборы символов и Unicode", но для этого обсуждения нужно помнить только то, что Unicode-символы могут представляться последовательностями из одного или двух байтов. Для однобайтовых последовательностей HTTP использует уже обсужденный метод шестнадцатеричного кодирования. Однако для двухбайтовых последовательностей Unicode-символы могут кодироваться шестисимвольной последовательностью, состоящей из строки %u или %U, за которой следуют четыре шестнадцатеричные цифры. Эти цифры представляют 16-битное значение Unicode-символа. Такие альтернативные кодировки являются потенциальной угрозой для протаскивания опасных символов через символьные фильтры. Чтобы понять проблему, посмотрите пример кода в листинге 8-27.

Листинг 8-27. Уязвимость имени пути с hex-кодированием

У этого, признаем, искусственного примера есть вопиющая проблема безопасности: переменная username проверяется на slash (/) до декодирования шестнадцатеричных символов. Используя описанную ранее технику связывания, можно сопоставить фазы декодирования, решения безопасности и действия следующим образом:

• Решение: если username содержит символ /, это опасно (см. строку 3 в листинге 8-27).

• Декодирование: шестнадцатеричное декодирование выполняется над вводом после решения (см. строку 10).

• Действие: username используется для открытия файла (см. строку 10).

Поэтому username вроде ..%2F..%2Fetc%2Fpasswd приводит к тому, что программа открывает системный файл паролей. Обычно такие уязвимости не настолько очевидны. Проблемы декодирования чаще возникают, когда программа разделена на компоненты, а отдельные модули изолированы от процесса декодирования. Поэтому разработчик, использующий модуль декодирования, обычно не знает, что происходит.

Примечание

Шестнадцатеричное кодирование также является популярным методом обхода защитного ПО (например, IDS), используемого для обнаружения атак на веб-серверы. Если IDS не декодирует hex-кодированные запросы или декодирует их неправильно, атаку можно провести без генерации предупреждения.

Обработка встроенных шестнадцатеричных последовательностей обычно проста. В целом декодер может ошибиться двумя способами:

• Пропустить NUL-байт.

• Декодировать недопустимые символы.

Ранее в этой главе вы изучили ошибочную реализацию, которая не проверяла NUL-байты (см. листинг 8-5). Поэтому здесь мы сосредоточимся на второй ошибке: декодировании недопустимых символов. Такая ошибка может случиться, когда делаются предположения о данных, следующих за знаком %. Ожидается, что после знака % идут две шестнадцатеричные цифры. Листинг 8-28 показывает типичную реализацию преобразования этих значений в данные.

Листинг 8-28. Декодирование некорректных значений байтов

Функция convert_byte() ошибочна: она предполагает, что байт является цифровым символом, если он явно не является шестнадцатеричной буквой (как показано в выделенных строках). Поэтому недопустимые hex-символы, переданные этой функции (включая символы A-F), создают неожиданные декодированные байты. Последствие такого неправильного декодирования для безопасности просто: любые фильтры, обрабатывающие данные на более раннем этапе, пропускают значения, которые могут появиться в результирующем выходном потоке.

HTML- и XML-кодирование

Документы HTML и XML могут содержать закодированные данные в форме entities, которые используются для кодирования метасимволов HTML-рендеринга. Entities строятся с помощью амперсанда (&), за которым следует сокращение entity, и завершаются точкой с запятой. Например, для представления амперсанда используется сокращение amp, так что & является закодированной HTML entity. Полный список entities доступен на сайте World Wide Web Consortium (W3C) по адресу www.w3c.org.

Еще интереснее то, что символы также могут кодироваться как числовые codepoints в десятичном и шестнадцатеричном виде. Чтобы представить codepoint в десятичном виде, перед значением codepoint ставится &#. Например, символ пробела имеет десятичное значение 32, поэтому он представляется как  . Hex-кодирование похоже, только перед значением ставится &#x, так что символ пробела (0x20) представляется как  . Двухбайтовые Unicode-символы также можно задавать последовательностями из пяти десятичных или четырех шестнадцатеричных цифр. Эта форма кодирования подвержена тем же базовым уязвимостям, что могут быть у шестнадцатеричных декодеров: внедрению NUL-символов, обходу фильтров и предположению, что после последовательности &# идет как минимум два байта.

Примечание

Помните, что HTML-декодирование обычно выполняется клиентским браузером. Однако использование этой формы кодирования в XML-данных действительно открывает возможность разных атак, направленных на сервер.

Несколько слоев кодирования

Иногда данные декодируются несколько раз и несколькими разными способами, особенно когда перед использованием ввода по назначению выполняется несколько слоев обработки. Многократное декодирование чрезвычайно затрудняет валидацию, поскольку более высокие слои видят данные в промежуточном формате, а не в финальном незакодированном содержимом.

В сложных многоуровневых приложениях факт, что ввод проходит через ряд фильтров или преобразований, может быть неочевиден сразу или может проявляться только при определенных условиях. Например, данные, отправленные на HTTP веб-сервер, могут пройти base64-декодирование, если заголовок Content-Encoding задает такое поведение, UTF-8 декодирование, потому что именно этот формат кодирования указан в заголовке Content-Type, и наконец шестнадцатеричное декодирование, которое выполняется для всего HTTP-трафика. Кроме того, если данные предназначены для веб-приложения или скрипта, вполне возможно, что они пройдут еще один уровень шестнадцатеричного декодирования. Рисунок 8-3 показывает такое поведение.

Рисунок 8-3. Закодированные веб-данные

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

Этот пример поднимает еще один интересный момент: уязвимости такого рода также могут быть результатом недостатков операционной безопасности. Как вы узнали в главе 3, "Операционный обзор", приложения не работают в вакууме, особенно интегрированные части ПО, такие как веб-приложения. Веб-сервер и платформенные модули могут предоставлять методы кодирования, которые атакующие способны использовать для нарушения безопасности приложения.

Наборы символов и Unicode

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

Unicode

Стандарт Unicode описывает символы любого языка уникальным и недвусмысленным образом. Он в первую очередь предназначался для устранения ограничений набора символов ASCII и распространения потенциально несовместимых наборов символов для других языков. В результате появился стандарт, определяющий "согласованный способ кодирования многоязычного текста, который позволяет обмениваться текстовыми данными международно и создает основу для глобального ПО". Стандарт Unicode (доступен на www.unicode.org) определяет символы как серию codepoints (числовых значений), которые могут кодироваться в нескольких форматах, каждый с разными размерами code units. Code unit -- это отдельная сущность с точки зрения процедур кодирования и декодирования; каждый размер code unit может быть представлен в любом порядке байтов: big endian (BE) или little endian (LE). Таблица 8-3 показывает разные форматы кодирования в Unicode.

Таблица 8-3. Форматы кодирования Unicode

Обратите внимание, что спецификацию порядка байтов (BE или LE) можно опустить; в таком случае marker порядка байтов (BOM) в начале ввода может использоваться для указания порядка байтов.

Эти схемы кодирования широко используются в HTTP-коммуникациях для данных запросов или XML-документов. Они также используются во множестве ПО на базе Microsoft, потому что современные операционные системы Windows внутренне используют Unicode для представления строк. Codespace Unicode находится в диапазоне от 0 до 0x10FFFF, поэтому 16-битные и 8-битные code units могут быть неспособны представить целый Unicode-символ из-за ограничений размера. Однако символы могут кодироваться многобайтовыми потоками; то есть несколько закодированных байтов подряд могут вместе представлять один Unicode-символ.

Аудит программ, использующих Unicode-символы и схемы кодирования Unicode, требует от ревьюеров проверить:

• Можно ли закодировать символы для обхода проверок безопасности.

• Содержит ли реализация кодирования и декодирования собственные уязвимости.

Первая проверка требует убедиться, что символы не преобразуются после того, как код фильтра уже проверил целостность ввода. Например, серьезная ошибка была обнаружена в веб-сервере Microsoft Internet Information Services (IIS). Она возникла из-за того, что ПО веб-сервера не декодировало Unicode escapes перед проверкой, пытается ли пользователь выполнить атаку directory traversal (double dot); поэтому оно не ловило закодированные последовательности ../ и ..\. Пользователи могли выполнить следующий запрос:

Таким образом они могли выполнять произвольные команды с правами, используемыми веб-сервером.

Примечание

Подробности этой уязвимости можно найти по адресу www.microsoft.com/security/technet/bulletin/MS00-078.mspx.

Поскольку многие приложения используют Unicode-представление, атака такого рода всегда является серьезной угрозой. Учитывая, что для выражения данных доступен диапазон схем кодирования, существует довольно много способов представить один и тот же codepoint. Вы уже знаете, что значение можно представить в 8-, 16- или 32-битных code units (в любом порядке байтов), но меньшие code units имеют несколько способов представления отдельных code points. Чтобы лучше это понять, нужно подробнее узнать, как code points кодируются; это объясняется в следующих разделах.

UTF-8

Codepoints, закодированные в UTF-8, представляются как одно- или многобайтовые последовательности. Для диапазонов значений от 0x00 до 0x7F требуется только один байт, поэтому UTF-8 кодировка для codepoints U.S. ASCII идентична ASCII. Для других значений, которые нельзя представить 7 битами, используется lead byte, за которым следует переменное число trailing bytes (до четырех), вместе представляющих кодируемое значение. Lead byte состоит из установленного старшего бита плюс ряда других битов в старшем слове, указывающих, сколько байтов входит в этот многобайтовый набор. Поэтому число непрерывно установленных битов в старшем слове lead byte задает число trailing bytes, как показано в таблице 8-4.

Таблица 8-4. Схема кодирования lead byte в UTF-8

Примечание

Правила битовых шаблонов в таблице 8-4 немного упрощены, но достаточны для целей этого обсуждения. Заинтересованным читателям рекомендуется посмотреть текущую спецификацию на www.unicode.org.

Биты, замененные x, используются для хранения части представляемого значения. Каждый trailing byte начинается с двух старших битов 10 и имеет младшие 6 битов, установленные для хранения части представляемого значения. Поэтому trailing byte не может быть меньше 0x80 или больше 0xBF, а lead byte также не может начинаться с 10 (поскольку это сделало бы его неотличимым от trailing byte).

До недавнего времени Unicode-значения можно было кодировать любой поддерживаемой многобайтовой длиной. Так, например, символ / можно было представить как:

• 0x2F

• 0xC0 0xAF

• 0xE0 0x80 0xAF

• 0xF0 0x80 0x80 0xAF

Стандарт Unicode 3.0, выпущенный в 1999 году, был пересмотрен так, чтобы разрешать только кодирование в кратчайшей форме; например, единственная допустимая UTF-8 кодировка в предыдущем списке -- 0x2F. Windows XP и более поздние версии принудительно применяют правило кратчайшей формы. Однако не все реализации Unicode соответствуют этому требованию. В частности, ASCII-символы часто принимаются как одно- или двухбайтовые последовательности, что может быть полезно при обходе символьных фильтров. Например, фильтр, ищущий slash в аргументе пути (0x2F), может пропустить последовательность 0xC0 0xAF; если UTF-8 преобразования выполняются позже, этот символьный фильтр можно полностью обойти для любого произвольного ASCII-символа.

Примечание

Daniel J. Roelker опубликовал интересную статью о сочетании этих разных многобайтовых кодировок с несколькими другими техниками шестнадцатеричного кодирования для обхода IDS-фильтрации HTTP-трафика. Она доступна по адресу http://docs.idsresearch.org/http_ids_evasions.pdf.

UTF-16

UTF-16 выражает codepoints как 16-битные слова, чего достаточно для представления большинства часто используемых символов в основных языках. Однако некоторые символы требуют больше 16 бит. Помните, codespace Unicode находится в диапазоне от 0 до 0x10FFFF, а максимальное значение, которое может представить 16-битное целое, равно 0xFFFF. Поэтому UTF-16 также может содержать многоэлементные последовательности, так что codepoints, закодированные в UTF-16, могут состоять из одного или двух units. Codepoint выше 0xFFFF требует двух code units для представления и кодируется как суррогатная пара; то есть пара code units со специальной ведущей битовой последовательностью, которая вместе представляет codepoint. Вот правила кодирования Unicode codepoints в UTF-16 (взяты из RFC 2781):

1. Если U < 0x10000, закодировать U как 16-битное беззнаковое целое и завершить.

2. Пусть U' = U - 0x10000. Поскольку U меньше или равно 0x10FFFF, U' должно быть меньше или равно 0xFFFFF. То есть U' можно представить 20 битами.

3. Инициализировать два 16-битных беззнаковых целых, W1 и W2, значениями 0xD800 и 0xDC00 соответственно. У каждого целого есть 10 свободных битов для кодирования значения символа, всего 20 битов.

4. Назначить 10 старших битов 20-битного U' в 10 младших битов W1, а 10 младших битов U' -- в 10 младших битов W2. Завершить.

Поскольку к битам, считанным из суррогатной пары, добавляется постоянное значение 0x100000, нельзя кодировать произвольные значения так, как это было возможно в UTF-8. В UTF-16 есть только один способ представить codepoint.

UTF-32

UTF-32 выражает codepoints как 32-битные значения. Поскольку он может представить любой codepoint одним значением, суррогатные пары никогда не требуются, как в UTF-8 и UTF-16. Единственный способ изменить представление codepoint в UTF-32 -- изменить endian-формат потока данных (используя специальный BOM, упомянутый после таблицы 8-3).

Уязвимости в декодировании

Как уже упоминалось, сложность корректной фильтрации Unicode-данных в том, что одно и то же значение можно представить множеством способов: разными word-size кодировками, сменой порядка байтов и злоупотреблением уникальной способностью UTF-8 представлять одно значение более чем одним способом. Приложение не будет подвержено обходу фильтров, если выполняется только одно декодирование, то есть данные декодируются, проверяются и затем используются. Однако в контексте HTTP-трафика одно декодирование случается редко. Почему? Веб-приложения резко увеличили сложность HTTP-обменов, и данные часто могут декодироваться несколько раз и несколькими способами. Например, веб-сервер IIS декодирует шестнадцатеричные последовательности в запросе, затем позже выполняет UTF-8 декодирование, а затем может передать данные ISAPI-фильтру или веб-приложению, которое выполнит еще одно шестнадцатеричное декодирование.

Примечание

Отличную информацию о проблемах безопасности Unicode можно найти в TR36 -- техническом отчете Unicode Security Considerations. На момент написания он доступен по адресу www.unicode.org/reports/tr36/.

Гомографические атаки

Гомографические атаки полезны прежде всего как форма социальной инженерии; Evgeniy Gabrilovich и Alex Gontmakher впервые описали их в статье "The Homographic Attack", опубликованной в февральском выпуске Communications of the ACM за 2002 год. Эти атаки используют Unicode-гомограф, то есть разные символы, имеющие одинаковое визуальное представление. На самом простом уровне гомографическая атака не обязательно требует Unicode. Например, цифра 1 (ASCII 0x31) может быть похожа на строчную букву l (ASCII 0x6c). Однако при внимательном рассмотрении их можно различить. В отличие от этого, Unicode-гомографическая атака включает два графических представления, которые идентичны, хотя лежащие в основе символы различны. Например, кириллический символ с codepoint 0x0441 выглядит очень похоже на символ Latin-1 (ASCII) 0x0063. В общем случае оба фактически отображаются как строчная c.

Глава 17 включает пример широко освещавшейся гомографической атаки в обсуждении phishing. Пока достаточно понимать, что атакующие могут использовать эти простые приемы, когда вы ревьюите приложение, показывающее пользователям данные из внешних источников. Даже если данные не вредны напрямую, атакующие могут использовать их, чтобы обмануть ничего не подозревающих пользователей.

Unicode-функции Windows

Операционная система Windows внутренне работает со строковыми данными как с wide characters (закодированными как UTF-16). Поскольку многие приложения работают со строками ASCII (или, возможно, с другими одно- или многобайтовыми наборами символов), Windows предоставляет функции для преобразования между двумя форматами, а также ASCII-обертки для всех открытых API-функций, которые иначе требовали бы строки wide characters.

Преобразование между кодировками символов происходит сходным образом независимо от того, использует приложение ASCII-обертки или явно преобразует данные. Правила этих преобразований в первую очередь определяются поведением двух функций: MultiByteToWideChar() и WideCharToMultiByte(). Детали того, как эти функции выполняют преобразования, имеют ряд последствий для безопасности: от ошибок порчи памяти до преобразований, создающих неожиданные результаты, как обсуждается в следующих разделах.

MultiByteToWideChar()

Функция MultiByteToWideChar() используется для преобразования многобайтовых и однобайтовых строк символов в Unicode-строки. В выходной буфер (lpWideCharString) можно записать максимум cchWideChar символов. Распространенная ошибка разработчиков приложений при использовании этой функции -- указать размер буфера назначения в байтах как параметр cchWideChar. Это означает, что в выходной буфер может быть записано вдвое больше байтов, чем было выделено места, и может произойти переполнение буфера. Функция MultiByteToWideChar() кратко описана в следующем списке:

• Функция:

• API: Win32 API

• Похожие функции: mbtowc

• Назначение: MultiByteToWideChar() отображает одно- или многобайтовую строку символов в строку wide characters.

Следующий код -- пример неправильного использования MultiByteToWideChar():

Этот код является примером только что упомянутой проблемы. Выделенная строка показывает, что счетчик wide characters установлен равным размеру выходного буфера, который в этом случае равен MAX_PATH * sizeof(WCHAR). Однако WCHAR занимает два байта, поэтому выходной размер, переданный MultiByteToWideChar(), интерпретируется как MAX_PATH * 2 байт, то есть вдвое больше реальной длины выходного буфера.

WideCharToMultiByte()

Функция WideCharToMultiByte() является обратной к MultiByteToWideChar(); она преобразует строку wide characters в строку narrow characters. Разработчики значительно реже вызывают переполнение буфера при использовании этой функции, потому что выходной размер задается в байтах, а не в wide characters, поэтому смысл параметра размера труднее понять неправильно. Функция WideCharToMultiByte() кратко описана в следующем списке:

• Функция:

• API: Win32 API

• Похожие функции: wctombc

• Назначение: WideCharToMultiByte() отображает строку wide characters в одно- или многобайтовую строку символов.

Поскольку wide characters являются более крупным типом данных, их информация иногда должна представляться последовательностью одиночных байтов, называемой многобайтовым символом. Правила кодирования wide characters в многобайтовые символы определяются кодовой страницей, указанной первым аргументом этой функции.

Проблемы NUL-терминации

Функции MultiByteToWideChar() и WideCharToMultiByte() не гарантируют NUL-терминацию, если буфер назначения заполнен. В таких случаях функции возвращают 0, а не количество преобразованных символов. Предполагается, что пользователи этих функций проверяют возвращаемое значение; однако часто это не так. Листинг 8-29 показывает короткий пример.

Листинг 8-29. *Проверка возвращаемого значения MultiByteToWideChar()*

Поскольку возвращаемое значение не проверяется, факт, что buf недостаточно велик для хранения преобразуемого имени, не обнаруживается, и buf не NUL-терминируется. Это заставляет wcsncat() неправильно вычислить оставшийся размер буфера как отрицательное число, которое, как вы знаете, преобразуется в большое положительное число, если посмотреть прототип wcsncat(), перечисленный в разделе strncat().

У MultiByteToWideChar() могут быть дополнительные проблемы при преобразовании многобайтовых наборов символов. Если указан флаг MB_ERR_INVALID_CHARS, функция вызывает ошибку при встрече недопустимой многобайтовой последовательности. Вот пример потенциально опасного вызова:

Снова, поскольку возвращаемое значение функции не проверяется, функция convert_string() не ловит недопустимые последовательности символов. Проблема в том, что MultiByteToWideChar() возвращает ошибку, когда видит недопустимую последовательность символов, но не NUL-терминирует буфер назначения (в данном случае outstr). Поскольку возвращаемое значение не проверяется, функция не обрабатывает эту ошибку и возвращает вызывающему коду незавершенную wide string. Из-за этого любая последующая обработка этой строки может привести к порче памяти.

Уязвимости манипуляции Unicode

Проблемы управления памятью также могут возникать при использовании любых ограниченных многобайтовых или wide character функций. Посмотрите пример с wcsncpy():

На первый взгляд кажется, что этот код корректен, но, конечно, параметр размера должен указывать, насколько велик буфер назначения в wide characters, а не размер в байтах; поэтому третий аргумент фактически вдвое больше длины выходного буфера. Такую ошибку легко допустить, поэтому аудиторам кода следует следить за ней.

Еще одна интересная особенность -- ошибки при работе со строками многобайтовых символов, предоставленными пользователем. Если кодовая страница приложения указывает, что используется double-byte character set (DBCS), символы могут занимать один или два байта. Приложения, обрабатывающие такие строки, должны определять, является ли каждый обрабатываемый байт отдельным символом или частью двухбайтовой последовательности; в Windows эта проверка выполняется функцией IsDBCSLeadByte(). Уязвимости, при которых указатель может быть увеличен за границы буфера, легко возникают, если приложение определяет, что байт является первым байтом двухбайтовой последовательности, и забывает проверить следующий байт, чтобы убедиться, что это не завершающий NUL-байт. Листинг 8-30 показывает пример.

Листинг 8-30. *Опасное использование IsDBCSLeadByte()*

Когда код в листинге 8-30 встречает lead byte двухбайтовой последовательности, он никак не проверяет второй байт этой последовательности. Если строка, переданная этой функции, заканчивается DBCS lead byte, lead byte и завершающий NUL-байт записываются в буфер назначения. Указатель src увеличивается за NUL-байт и продолжает обрабатывать байты за границами строки, переданной этой функции. Эта ошибка может привести к переполнению буфера newstring, поскольку выделенная длина основана на длине исходной строки.

Примечание

Когда интерпретируются последовательности многобайтовых символов, изучайте код, чтобы понять, что произойдет, если вторым байтом последовательности окажется завершающий NUL-байт строки. Если второй байт не проверяется, может быть возможна обработка данных за границами буфера.

Предположения о кодовой странице

При преобразовании из многобайтовых символов в wide characters аргумент кодовой страницы влияет на поведение MultiByteToWideChar(), поскольку он задает набор символов, в котором закодирована многобайтовая строка. В большинстве случаев эта функция используется с системной кодовой страницей по умолчанию (CP_ACP, ANSI Code Page), которая делает не так много. Однако в некоторых ситуациях атакующие могут влиять на кодовую страницу, создавая последовательности многобайтовых символов, обходящие фильтры на более ранних слоях. Листинг 8-31 -- пример уязвимого фрагмента кода.

Листинг 8-31. Пример несоответствия кодовой страницы

Как видно, кодирование выполняется после проверки на slash, поэтому, закодировав slash, атакующие, нацеливающиеся на ранние версии Windows, могут обойти эту проверку и, предположительно, позднее сделать то, чего они не должны иметь возможности сделать. Akio Ishida и Yasuo Ohgaki обнаружили интересную вариацию этой уязвимости в API баз данных PostgreSQL и MySQL (доступно по адресу www.postgresql.org/docs/techdocs.50). Как упоминалось, управляющие символы SQL обычно экранируются символом обратного slash (\). Однако некоторые наивные реализации этой техники могут неправильно учитывать многобайтовые символы. Рассмотрите следующую последовательность байтов:

На самом деле это строка, в которой первые два байта являются допустимым японским символом в кодировке Shift-JIS, а последний байт является одинарной ASCII-кавычкой ('). Наивный фильтр не определит, что первые два байта относятся к одному символу; вместо этого он интерпретирует байт 0x5c как символ обратного slash. Экранирование этой последовательности приведет к следующим байтам:

Передача результирующей строки базе данных, осведомленной о многобайтовых символах, может вызвать проблему, потому что первые два байта интерпретируются как один японский символ. Затем оставшиеся два байта 0x5c интерпретируются как экранированная последовательность обратного slash. Наконец, последний байт остается неэкранированным символом одинарной кавычки. Эту неверно интерпретированную кодировку можно эксплуатировать для внедрения SQL-операторов в приложение, которое иначе не должно быть уязвимым.

Использование многобайтовых наборов символов с MultiByteToWideChar() может иметь дополнительные осложнения, связанные с порчей памяти. Листинг 8-32 показывает интересный вызов этой функции.

Листинг 8-32. NUL-байты в многобайтовых кодовых страницах

Функция MultiByteToWideChar() в листинге 8-32 уязвима к переполнению буфера при использовании многобайтовой кодовой страницы. Почему? Потому что длина выходной строки рассчитывается умножением длины входной строки на два. Однако этого расчета недостаточно, поскольку NUL-байт в строке может быть частью многобайтового символа; следовательно, NUL-байт может быть пропущен, а символы за границами продолжат обрабатываться и записываться в выходной буфер. В UTF-8, если NUL-байт появится в многобайтовой последовательности, он сформирует недопустимый символ; однако MultiByteToWideChar() выполняет замену по умолчанию или пропускает символ (в зависимости от версий Windows), если во втором аргументе не указан флаг MB_ERR_INVALID_CHARS. Когда этот флаг указан, функция возвращает ошибку при встрече недопустимой последовательности символов.

Эквивалентность символов

Использование WideCharToMultiByte() имеет интересные последствия при декодировании данных. Если преобразования выполняются после символьных фильтров, код столь же подвержен протаскиванию недопустимых символов через фильтры. Однако при преобразовании wide characters в multibyte риск возрастает по двум основным причинам:

• Даже с кодовой страницей по умолчанию несколько 16-битных значений часто отображаются в один и тот же 8-битный символ. Например, если нужно, чтобы во входном потоке преобразованного набора символов появился обратный slash, можно передать три разных wide characters, которые преобразуются в байт обратного slash (0x5c): 0x00 0x5c, 0x22 0x16 и 0xff 0x0c. Это возможно не потому, что символ обратного slash имеет три Unicode-представления, а потому, что выходной символ представляет ближайшее совпадение, когда точное преобразование невозможно. Такое поведение можно переключить флагом WC_NO_BEST_FIT_CHARS.

• Когда встречается символ, который нельзя преобразовать в многобайтовый символ и для него не удается найти близкую замену (или установлен флаг WC_NO_BEST_FIT), в выходной поток вставляется символ замены по умолчанию; для ANSI code page используется символ ., если не указано иное. Если этот символ замены фильтруется, широкий диапазон значений может породить этот символ в выходном потоке.

Аудит кода, использующего MultiByteToWideChar() или WideCharToMultiByte(), требует внимательного отношения ко всем этим факторам:

• Проверьте, должны ли данные проходить через фильтр до преобразования, а не после него.

• Проверьте, является ли кодовая страница многобайтовой или может ли она задаваться пользователем.

• Если флаг MB_ERR_INVALID_CHARS установлен для преобразования многобайтовых потоков, пользовательский ввод может преждевременно завершить обработку и оставить выходной буфер незавершенным. Если он опущен, можно задать многобайтовую последовательность, включающую завершающий NUL-байт, что потенциально создает проблемы для плохо написанного кода.

• Если флаг WC_NO_BEST_FIT_CHARS присутствует при преобразовании wide character данных, пользователи могут передать несколько значений данных, которые переводятся в один и тот же однобайтовый символ. Правила best-fit matching устарели на годы, и большинству разработчиков все равно не следует их использовать.

• Ищите любые другие флаги, влияющие на то, как эти функции могут быть использованы неправильно.

• Убедитесь, что возвращаемое значение проверяется. Если ошибка преобразования не обнаружена, незавершенные буферы могут использоваться неправильно.

• Проверьте размеры входных и выходных буферов, как упоминалось в обсуждении порчи памяти в главе 5.

Резюме

В этой главе вы изучили уязвимости, которые могут возникать при обработке текстовых данных как строк. Большинство таких уязвимостей является результатом обработки внутриполосных текстовых метаданных в форме метасимволов. Неправильная обработка этих внутриполосных данных может приводить к порче памяти, как это часто бывает при некорректной обработке NUL-символа с помощью API строк C. Однако существует много других проблем безопасности, которые могут возникать с более сложными представлениями метасимволов, такими как имена путей, строки формата и SQL. Эти проблемы дополнительно усугубляются, когда разные схемы кодирования и наборы символов позволяют форматировать данные способами, которые разработчики не предвидят и не учитывают. Как аудитор, вы должны понимать риски, связанные с уязвимой обработкой внутриполосных данных, а также то, как их выявлять и предотвращать.