Отчет CISA показывает, что большинство проектов с открытым исходным кодом содержат небезопасный для памяти код

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

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

Из общего числа строк кода этих проектов 55% были написаны на языке, небезопасном для памяти, а в более крупных проектах их было больше. Строки с небезопасной памятью составляют более четверти всех из 10 крупнейших проектов в наборе данных, при этом медианная доля среди них составляет 62,5%. Четыре из них более чем на 94% состоят из небезопасного для памяти кода.

Что такое небезопасные для памяти языки?

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

С другой стороны, языки, безопасные для памяти, такие как Python, Java, C# и Rust, автоматически выполняют управление памятью с помощью встроенных функций и перекладывают ответственность на интерпретатор или компилятор.

СМОТРИТЕ: 10 лучших курсов Python, которые стоит пройти в 2024 году

Авторы отчета написали: «Уязвимости безопасности памяти являются одними из наиболее распространенных классов уязвимостей программного обеспечения и влекут за собой значительные затраты как для производителей программного обеспечения, так и для потребителей, связанные с исправлениями, реагированием на инциденты и другими усилиями».

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

«Таким образом, мы определяем, что наиболее важные проанализированные проекты с открытым исходным кодом, даже те, которые написаны на языках, безопасных для памяти, потенциально содержат уязвимости безопасности памяти», — пишут авторы.

Крис Хьюз, главный советник по безопасности компании Endor Labs, занимающейся безопасностью с открытым исходным кодом, и специалист по киберинновациям в CISA, рассказал TechRepublic: «Результаты, безусловно, представляют риск как для коммерческих организаций, так и для государственных учреждений из-за широко распространенного использования этого класса уязвимостей, когда мы Посмотрите на ежегодную эксплуатацию различных классов уязвимостей. Они часто входят в число наиболее часто используемых классов уязвимостей из года в год».

Почему код, небезопасный для памяти, так распространен?

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

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

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

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

«Где-то под каждым стеком языка программирования и графом зависимостей пишется и выполняется небезопасный для памяти код», — пишут авторы.

СМОТРЕТЬ: Исследование Aqua Security выявило увеличение количества атак на память на 1400%

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

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

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

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

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

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

Усилия чиновников по снижению распространенности кода, небезопасного для памяти

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

В отчете Consumer Reports за октябрь 2022 года отмечается, что «примерно 60–70 процентов уязвимостей браузеров и ядра, а также ошибок безопасности, обнаруженных в базах кода C/C++, связаны с небезопасностью памяти». Затем Агентство национальной безопасности опубликовало руководство о том, как разработчики программного обеспечения могут защититься от проблем с безопасностью памяти.

В 2023 году директор CISA Джен Истерли призвала университеты обучать студентов методам безопасного использования памяти и безопасного кодирования. Затем были опубликованы Национальная стратегия кибербезопасности на 2023 год и план ее реализации, в которых обсуждались инвестиции в безопасные для памяти языки и сотрудничество с сообществом открытого исходного кода для их дальнейшей поддержки. В декабре того же года CISA опубликовало «Дорожные карты безопасности памяти» и отчет Технического консультативного совета по безопасности памяти.

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

Усилия правительства США поддерживаются рядом сторонних групп, которые разделяют их цель — снизить распространенность небезопасного для памяти кода. В рабочей группе по передовому опыту OpenSSF есть специальная подгруппа по безопасности памяти, а проект Prossimo Исследовательской группы по интернет-безопасности хочет «переместить чувствительную к безопасности программную инфраструктуру Интернета на код, безопасный для памяти». Google разработала службу OSS-Fuzz, которая постоянно тестирует программное обеспечение с открытым исходным кодом на наличие уязвимостей безопасности памяти и других ошибок с использованием методов автоматического фаззинга.