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

58 • СПЕЦПРОЕКТ Таким образом, на этапе преобразо- вания типов может возникнуть ошибка, которая никак не будет обработана. История вторая Бывают случаи интересные не сами по себе, а обсуждениями, которые они порождают, – когда каждый размечаю- щий смотрит на проблему 4 по-своему. В таких случаях начинается длительный "бокс по переписке", сокращенный вари- ант которой мы приводим ниже. Наша статистика Большинство ошибок, выявляемых в ходе разметки, – это все-таки тривиаль- ные типовые случаи, вызванные невни- мательностью. Проекты и авторы раз- ные, а ошибки – одинаковые и уже набившие оскомину: l неиспользуемые переменные, когда переменную создали и просто забыли про нее, – это лишь косметическая ошибка, хоть потенциально и она может вызвать проблемы; l разыменование нуля – одна из наибо- лее опасных ошибок, которая может привести к серьезным уязвимостям, а возникает она при частом сценарии, когда разработчик передает результат вызова функции без проверки; так что крайне важно всегда тщательно прове- рять указатели и избегать разыменова- ния нуля, чтобы гарантировать стабиль- ность и безопасность разрабатываемого кода; l забыли сделать проверку на ноль; l забыли очистить память. В большинстве случаев такие ошибки и обеспечивают нас с коллегами рабо- той. Бывают и просто забавные случаи – во время проверки потенциально опас- ного участка кода проверил репозиторий проекта на GitHub и наткнулся на инте- ресный комментарий разработчика, оставленный после проблемной строки в своем проекте: "Может произойти разыменование нуля". Это означает, что разработчик признает наличие серьез- ной ошибки, либо уже нашел ее сам, либо знал о ней с самого начала, но по какой-то причине не стал ее исправлять, а просто оставил комментарий, что знает о ней и, видимо, заводить issue на исправление уже бессмысленно. Рассинхронизация Есть забавный случай с разметкой компонента cups, где мы по заданию размечали одну из версий компонента и нашли проблему 5 . Сообщили в апстрим, после чего нас послали использовать последнюю версию – даже "спасибо" не сказали. Остался только скрин, а ориги- нального issue в трекере уже нет. Проблема баг-ревью для проектов Open Source Отсутствие доступа к баг-трекерам различного свободного ПО случается довольно часто. Это сказывается на оперативности передачи информации о выявленных уязвимостях и проблемах, и в свою очередь может привести к задержкам в устранении ошибок ПО. Так, Apache Foundation, управляющая рядом известных продуктов, например сервером Apache HTTP, не открывает исследователям доступ к своему баг- трекеру. Такая позиция с точки зрения безопасности правильна, однако она вызывает серьезные затруднения для взаимодействия с апстримом. Не обошла стороной эта проблема и нашу команду. Обнаружив баги в ком- поненте ActiveMQ, мы столкнулись с тем, что не смогли оперативно передать информацию разработчику. Для решения данной проблемы нам потребовался целый календарный месяц. Как оказалось позднее, проблема не ограничивается отсутствием доступа к баг-трекерам, так как внесенные в него заявки и отчеты часто остаются без внимания в течение долгого времени. В случае с Apache некоторые из отправ- ленных нами отчетов о проблемах оста- вались необработанными неделями, а то и месяцами. Здесь необходимо пояснить, что сего- дня, в связи со сложившей геополити- ческой ситуацией в мире, ресурс по заведению ошибок Apache перестал быть доступен для граждан Российской Федерации. Поэтому уже сейчас необхо- димо задуматься о самостоятельной поддержке и контроле безопасности раз- личных проектов Open Source, исполь- зуемых при разработке ПО. Зубодробительные задачки Сложный момент был, когда мы ана- лизировали perl. За две недели я смог осилить только шесть разметок из своего норматива "двадцать в неделю", это был очень нестандартный для меня код. Насколько я помню, там было очень много незнакомых операций и инструк- ций, по большей степени для супер- углубленной работы с памятью. Тут, конечно, недостаток моего опыта сказался. Плюс к этому, довольно часто, когда анализируешь код, можно понять, что примерно делает та или иная функ- ция по ее названию, – это сильно упро- щает понимание того, что вообще про- исходит в исследуемом участке. Здесь же названия функций были заданы так, будто кто-то проехался лицом по кла- виатуре XD: просто наборы согласных. Это тоже очень сильно усложняло пони- мание кода. Актуальные технологии – залог экономии ресурсов Найти много действительных ошибок в исходном коде – всегда желанный результат для исследователей Open Source. Наша команда упорно трудилась над разметкой срабатываний анализа- тора для компонента snmpd, результатом чего стало выявление множества ошибок низкого уровня критичности. Мы гото- l Вердикт: False positive Строкой выше анализируемой строки if (buf[len - 1] == '\n') переменной len присваивается значение, равное длине строки buf, с использованием оператора strlen (то есть игнорируя нулевой символ). Получается, что в любом случае не получится обратиться к несуществующему элементу. Несколькими строками выше есть также явная проверка на существования строки buffer и 5отличие ее от нуля. l Не согласен. Вердикт: Confirmed Fixed by: upstream. Author: Bart Van Assche bvanassche@acm.org. Хотя с рассуждениями в комментарии о том, что underflow не будет, так как есть проверка выше. Но все же эта проблема поправлена в апстриме. Вот строка, аналогичная исследуемой: if (len && buf[len - 1] == '\n') она явно отличается от текущей: if (buf[len - 1] == '\n') Раз в апстрим добавлена проверка, то, в соответствии с регламентом, ставится "Fixed by: upstream" с номером коммита, автором и вердикт Confirmed. Все же, по моему мнению, ошибки тут нет, и дополнительные проверки излишни (проверку проводил в отдельном файле), поэтому считаю, что Svace не должен был помечать этот блок кода как ошибку, и завести issue на Svace будет не лишним. В соответствии с регламентом, изменю вердикт на Confirmed. 4 clck.ru/3EnZsM 5 clck.ru/3EnaKD