dxdt.ru: занимательный интернет-журнал

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

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

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

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

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

Вообще, трудность в понимании записи произвольного, заранее не известного, алгоритма настолько фундаментальная, что, похоже, именно она и является причиной формулирования знаменитой проблемы P≟NP. Из этого, впрочем, следует вывод, что и в обратную сторону, – то есть, для превентивного выявления закладок/уязвимостей, – публикация исходников работает не так эффективно, как принято думать: дефекты не просто всегда есть, но они и могут долго оставаться незамеченными, к сожалению. Однако открытые исходники – там, где их возможно открыть – конечно, лучше, и публикация исходников, сама по себе, не делает программу или программную систему, которая распространяется по конечным пользователям, “более уязвимой”.

Адрес записки: https://dxdt.ru/2023/02/02/9495/