Безопасность систем с открытым кодом

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

Криспин Кован

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

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

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

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

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

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

Аудит программного обеспечения

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

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

Sardonix

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

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

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

Статические анализаторы

Статические анализаторы проверяют исходные тексты и сообщают о подозрительных строках кода, которые могут оказаться уязвимыми. В отличие от компиляторов «строго типизированных» языков, таких как Java и ML, статические анализаторы могут посчитать подозрительными совершенно безопасные фрагменты кода. Однако излишняя подозрительность приводит к увеличению соотношения ложных/истинных тревог. Если статический анализатор слишком часто поднимает тревогу, разработчики начинают относиться к нему с недоверием и зачастую вообще отказываются от него. Так что избирательность для анализатора исходных текстов абсолютно необходима. С другой стороны, анализатор должен обладать достаточно высокой восприимчивостью. Если анализатор пропускает некоторые случаи патологий, на поиск которых он рассчитан (нераспознавание ошибки), он внушает разработчикам ложное чувство уверенности.

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

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

• BOON - инструментарий, который на основе глубокого семантического анализа автоматизирует процесс сканирования исходных текстов на Си в поисках уязвимых мест, способных приводить к переполнению буфера. Он выявляет возможные дефекты, предполагая, что некоторые значения являются частью неявного типа с конкретным размером буфера [3].
• CQual - инструментарий анализа на базе типов для поиска ошибок в программах на Си. Он расширяет систему типов языка Си, добавляя к ним определенные пользователем идентификаторы типов. Программисты снабжают свои программы аннотациями, а CQual выполняет вывод идентификаторов, проверяя, корректны ли эти аннотации. Недавно в CQual были внесены изменения, благодаря которым этот инструментарий теперь может проверять согласованность и полноту использования "хуков" Linux Security Module в ядре Linux [4]. Также было расширено понятие аннотации типа с тем, чтобы инструментарий мог выявлять уязвимые места, возникающие из-за использования строки формата оператора printf [5].
• MOPS (MOdel checking Programs for Security) - инструментарий для поиска ошибок в защите в программах на Си и проверки отсутствия таких ошибок. MOPS использует модель аудита программного обеспечения, которая призвана помочь выяснить, соответствует ли программа набору правил, определенному для создания безопасных программ. Исследования продолжаются [6].

RATS. Инструментарий Rough Auditing Tool for Security — утилита для проверки безопасности программ, написанных на языках Си, C++, Python, Perl и PHP. Сканирует исходный текст в поисках потенциально опасных вызовов функций. Цель разработки заключается не в том, чтобы непременно найти ошибки, — необходимо сделать обоснованные выводы, опираясь на которые специалист сможет вручную выполнять проверку кода. RATS использует сочетание проверок надежности защиты, от семантических проверок в ITS4 [7] до глубокого семантического анализа в поисках дефектов, способных привести к переполнению буфера, полученных из MOPS [3]. RATS распространяется в соответствии с лицензией GNU Public License (GPL).

FlawFinder. Как и RATS, это статический сканер исходных текстов программ, написанных на Си и C++. Выполняет поиск функций, которые чаще всего используются некорректно, присваивает им коэффициенты риска (опираясь на такую информацию, как передаваемые параметры) и составляет список потенциально уязвимых мест, упорядочивая их по степени риска. FlawFinder распространяется бесплатно и с исходными текстами в соответствии с условиями GPL.

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

PScan. В июне 2000 года исследователи обнаружили новый и достаточно обширный класс уязвимых мест, получивший название «ошибки формата» [8]. Проблема связана с описателем формата %n оператора форматного вывода строк printf, который указывает число байт, выводимых для соответствующего аргумента printf, при условии, что данный аргумент существует и имеет тип int *. Этот описатель может быть использован для нарушения защиты, если программа позволяет передавать «неотфильтрованные» данные непосредственно как первый аргумент printf.

Это действительно «дыра»: раньше повсеместно считалось, что строки формата совершенно безопасны. Впоследствии же в широко применяемых инструментальных средствах обнаружились десятки дефектов, связанных с форматами [9].

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

07.08.2003г