Завязывайте с Си++, он того

[vak]

Разработчиков ПО призывают прекратить использование C/C++ к 2026 году

(Меган Крауз, 4 ноября 2024г)

Агентство по кибербезопасности и защите инфраструктуры США (CISA) и Федеральное бюро расследований (FBI) утверждают, что C, C++ и другие языки программирования с небезопасной работой с памятью способствуют возникновению потенциальных уязвимостей.

Федеральное правительство призывает производителей программного обеспечения отказаться от C/C++ и предпринять другие шаги, которые могут "снизить риски для клиентов", говорится в отчёте "Product Security Best Practices". В частности, CISA и ФБР установили срок до 1 января 2026 года для соблюдения рекомендаций по безопасности памяти.

В отчёте изложены именно рекомендации и руководящие принципы, а не обязательные требования, в первую очередь для производителей программного обеспечения, работающих с критически важной инфраструктурой или национально значимыми функциями. Агентства отдельно выделили локальное программное обеспечение, облачные сервисы и программное обеспечение как услугу (SaaS).

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

"Следуя рекомендациям данного руководства, производители подают клиентам сигнал о том, что они берут на себя ответственность за результаты в области безопасности, что является ключевым принципом подхода Secure by Design", — говорится в отчёте.

Языки программирования с небезопасной работой с памятью создают потенциальные уязвимости

В отчёте языки с небезопасной работой с памятью описываются как "опасные и существенно повышающие риски для национальной безопасности". Разработка на таких языках упоминается первой в списке нежелательных практик.

Вопрос безопасности памяти обсуждается как минимум с 2019 года. Языки вроде C и C++ "предоставляют большую свободу и гибкость в управлении памятью, при этом в значительной степени полагаясь на программиста в выполнении необходимых проверок обращений к памяти", отмечалось в отчёте Агентства национальной безопасности США (NSA) за 2023 год, посвящённом безопасности памяти. Однако в нём также подчёркивалось, что этим языкам не хватает встроенных механизмов защиты памяти, которые могли бы предотвращать ошибки управления памятью. Злоумышленники могут эксплуатировать такие проблемы, возникающие в этих языках.

Что производители программного обеспечения должны сделать к январю 2026 года

К 1 января 2026 года производители должны иметь:

• "Дорожную карту по безопасности памяти" для существующих продуктов, написанных на языках с небезопасной работой с памятью. Она "должна описывать приоритетный подход производителя к устранению уязвимостей безопасности памяти в ключевых компонентах кода".
• Демонстрацию того, как эта дорожная карта позволит сократить количество уязвимостей, связанных с безопасностью памяти.
• Подтверждение “разумных усилий” по следованию данной дорожной карте.
• Либо, в качестве альтернативы, использование языка с безопасной моделью работы с памятью.

К языкам с безопасной работой с памятью, одобренным NSA, относятся:

• Python
• Java
• C#
• Go
• Delphi / Object Pascal
• Swift
• Ruby
• Rust
• Ada

Другие плохие практики: от слабых паролей до отсутствия раскрытия уязвимостей

К другим практикам, которые CISA и ФБР обозначили как "исключительно рискованные", относятся:

• Прямое использование пользовательского ввода в необработанном содержимом строки SQL-запроса.
• Прямое использование пользовательского ввода в необработанном содержимом строки команды операционной системы.
• Использование паролей по умолчанию. Вместо этого производители должны обеспечивать:
  • случайные, уникальные для каждого экземпляра начальные пароли;
  • обязательное создание новых паролей пользователем в начале процесса установки;
  • необходимость физического доступа для первичной настройки;
  • отказ от паролей по умолчанию в уже развернутых системах.
• Выпуск продукта, содержащего уязвимость из каталога CISA Known Exploited Vulnerabilities (KEV).
• Использование программного обеспечения с открытым исходным кодом, в котором известны эксплуатируемые уязвимости.
• Отсутствие многофакторной аутентификации.
• Отсутствие возможности собирать доказательства вторжения в случае атаки.
• Несвоевременная публикация CVE, включая указание Common Weakness Enumeration (CWE) — типа уязвимости, лежащей в основе CVE.
• Отсутствие политики раскрытия уязвимостей.

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