Журнал "Information Security/ Информационная безопасность" #5, 2024

• 59 Безопасный Linux www.itsec.ru вились к их исправлению, однако в даль- нейшем произошли интересные события, которые заставили нас пересмотреть последовательность действий. Дело в том, что всякий раз, как мы собирались начать нашу работу, выяснялось, что ошибка исправления не требует, так как авторами уже внесены соответствующие изменения в коде. История не ограничи- лась минорными ошибками. В анализи- руемой версии мы обнаружили также и ошибки средней критичности, для которых впоследствии обнаружили выпу- щенные исправления. Все это наглядно демонстрирует, поче- му разработчикам продукта необходимо регулярно отслеживать версии компо- нентов Open Source, используемых в про- цессе разработки. Актуальные техноло- гии позволят не только идти в ногу со временем, но и обеспечить безопасность конечных решений. Вместо тысячи слов Занимаюсь статическим и динамиче- ским анализом кода. В работе часто приходится коммуницировать с разра- ботчиками. Иногда приходится аргумен- тированно доносить свой взгляд на про- блему другим участникам работы, а также воспринимать критику по отно- шении к себе. Со временем в такой работе начинает помогать интуиция, полученная из прошлого опыта. Процесс трудный, но интересный, так как виден его результат, то есть принятая и исправ- ленная международным сообществом проблема. Про системный подход Несмотря на то что статический анализ действительно является мощным инстру- ментом по выявлению уязвимостей, у него есть недостаток, заключающийся в наличии ложноположительных сраба- тываний, так называемых False Positive. Это ситуации, когда анализатор видит уязвимости там, где их нет. В связи с этим эксперту нужно прово- дить разметку результатов работы ана- лизатора, то есть проверять код в тех местах, где анализатор видит ошибки, и выяснять, действительно ли в них есть уязвимости. Во многом этот процесс завязан на экспертной оценке, то есть зависит от человеческого фактора. Если специалист, проводящий разметку, будет делать ее недостаточно тщательно, то он может пропустить часть уязвимостей, или наоборот, найти их там, где они отсутствуют. А теперь представьте, вам дают несколько сотен, а может и тысяч, мар- керов анализатора и просят в короткие сроки полностью их разметить, при этом никакого ревью вашей работы никто не проводит. Разумеется, качество такого анализа оставит желать лучшего. Из-за сжатых сроков вы не будете глубоко анализировать код, а просто пометите все подозрительные участки программы как уязвимости, тем самым не отсеяв ложноположительные срабатывания ана- лизатора. Затем результаты вашей рабо- ты передадут разработчику, который столкнется с тем, что, разбирая резуль- таты анализа, он тратит большую часть своего времени на обработку ложных срабатываний вместо того, чтобы улуч- шать свой продукт, добавляя к нему новые функции. Конечно, он во всем этом неблагодарном деле разочаруется и не будет относится к результатам ста- тического анализа всерьез. Получается, чтобы статический анализ кода был эффективен и приводил к реальному улучшению безопасности программного обеспечения, процесс его проведения должен быть правильно налажен. Я успел позаниматься статическим анализом в нескольких организациях, но нигде не встречал настолько грамот- ного выстроенного процесса проведения анализа, как в Центре. Согласно нашему регламенту, помимо выделения адек- ватных сроков на проведения разметки, нужно проводить ее в несколько этапов. Сначала выполняется первичная раз- метка, в рамках которой у эксперта есть возможность полноценно разобраться в том, как работает код. Затем полученные результаты подвергаются выборочной кросс-верификации со стороны экспер- тов из других организаций, что позволяет добиться максимальной точности про- водимого анализа. В тех случаях, когда эксперт понимает, как можно исправить найденную им уязвимость, он может самостоятельно подготовить исправле- ние и передать его разработчикам. Как итог, у нашего Центра получается достичь высокой точности статического анализа и значительно улуч- шить безопасность иссле- дуемого программного обес- печения, при этом сведя дополнительную нагрузку на разработчиков к минимуму. История про вирус в issue Некий бразилец (никак не связанный и даже близко не стоявший с проектом) взял и предложил 6 попробовать скачать и запустить у себя exe-шник из запароленного архива с mediafire (может, в качестве решения или дебага), который, как оказа- лось, содержал трояны. Квест по доставке исправлений Результаты статического анализа исходного кода GnuTLS показали нали- чие множественных ошибок категории "утечка памяти". Наша команда завела обращение в репозиторий разработчи- ков, и получив в дальнейшем офици- альное подтверждение неисправностей, инициировала процесс по исправлению ошибок и доставке их в мастер-ветку репозитория. Все шло штатно, поэтому неотрабо- танный по нашему запросу пайплайн на слияние оказался большим сюрпри- зом для всей команды. Причина была проста: GitLab-аккаунт сегодня невоз- можно верифицировать в связи с отсут- ствуем поддержки телефонных номеров с кодом RU +7. Мы пошли другим путем – довели информацию до разра- ботчика, который собственным запро- сом на слияние принял коммит с исправлениями ошибок. Мы видим, что сегодня поддержка компонентов Open Source становится все более затруднительной и требует от отечественных исследователей творче- ского подхода к решению вопросов по доставке исправлений до международ- ного сообщества. Не Nginx-ом единым Анализ исходного кода Nginx может закончиться исправлением ошибки в совершенно другом проекте Open Source – к такому выводу мы пришли в ходе разбора срабатываний статиче- ского анализатора Svace для компонента Nginx. В состав анализируемой сборки были включены, помимо самого компонента Nginx, также и иные дополнительные модули, обеспечивающие его работу. Соответственно, при последующей раз- метке срабатываний статического ана- лизатора исследованиям был подвергнут в том числе исходный код иных компо- нентов Open Source. По результатам анализа Nginx, нашей командой были направлены патчи не только в репозиторий этого проекта, но и для компонентов gRPC и Lua. l 6 clck.ru/3EnaTX