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

Аналитики обнаружили, что 52% проектов с открытым исходным кодом написаны на небезопасных для памяти языках, таких как C и C ++.

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

joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c Скачать

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

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

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

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

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

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

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

“Следовательно, мы определяем, что большинство проанализированных критически важных проектов с открытым исходным кодом, даже написанных на языках, безопасных для памяти, потенциально содержат уязвимости в области безопасности памяти”, – пишут авторы.

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

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

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

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

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

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

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

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

“Было бы сложно перевести многие из этих проектов на языки, безопасные для памяти, потому что это потребовало бы ресурсов и усилий от сопровождающих для рефакторинга / перезаписи на языки, безопасные для памяти. Сопровождающие могут не обладать знаниями языка memory safe, и даже если они это сделают, у них может не быть стимула делать это, учитывая, что они в основном неоплачиваемые добровольцы, которым не выплачивают компенсацию за проекты, которые они создали и поддерживали. ”

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

Усилия официальных лиц по сокращению распространенности небезопасного для памяти кода

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

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

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

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

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