Опубликован документ Safe C++ для продвижения внедрения безопасного кода на C++ вместо перевода проектов на Rust

«Специалисты по безопасности призывают проекты отказаться от C++ и перейти на безопасные для памяти языки, например Rust. Но масштаб проблемы устрашает. C++ поддерживает программное обеспечение, которое принесло триллионы долларов прибыли. Существует много опытных программистов на C++ и много кода на C++. Учитывая, насколько широко распространён C++, отрасль должна что-то реально сделать для улучшения качества программного обеспечения и снижения уязвимостей. В этом проекте предлагаются варианты внедрения нового безопасного для памяти кода в существующие проекты и улучшения новых проектов. Чужеродность Rust для профессиональных разработчиков C++ в сочетании с сложными инструментами взаимодействия затрудняет улучшение безопасности кода приложений C++ путём переписывания критических секций в Rust. Для противодействия этой проблеме нужно принять внутриязыковые решения для безопасности памяти и создать безопасный C++», — уточнил Бакстер.

Цель проекта Safe C++ — продвигать код на C++ с помощью использования безопасных инструментов. Начните новый проект или возьмите существующий и начните писать безопасный код на C++. В этом случае код в безопасном контексте демонстрирует те же строгие гарантии безопасности, что и код, написанный на Rust.

Бакстер предлагает использовать устоявшийся в ИБ метод кнута и пряника. Разработчикам Safe C++ запрещено писать код, который может привести к неопределённому поведению, включая обеспечивание безопасности типов и потоков. В качестве пряника предлагается набор новых возможностей, которые улучшают небезопасные возможности языка, запрещённые конечным пользователям.

«Руководители технических компаний подталкивают свои организации к переходу на Rust, включая Марка Руссиновича. Все это снижает ценность языка для новичков. Это проблема для компаний, которые полагаются на поток новых разработчиков C++ для продолжения своей деятельности. Вместо того, чтобы восприниматься как угроза, мы приветствуем модель безопасности, разработанную Rust, как возможность усилить C++. Сообщество Rust потратило десятилетие на формирование знаний о надёжности, которые представляют собой тактики и стратегии (внутренняя изменчивость, отправка/синхронизация, проверка заимствования и так далее) для достижения безопасности памяти без накладных расходов на сборку мусора. Их инвестиции в знания о надёжности определяют нашу разработку безопасного C++. Принятие той же модели безопасности владения и заимствования, на которую указывают специалисты по безопасности, является разумным и своевременным способом сохранить жизнеспособность C++ для следующего поколения. Вместо того чтобы сосредотачиваться на длинном хвосте сложных вариантов использования, мы призываем разработчиков думать об объёме кода, который поддаётся улучшениям безопасности, которые предлагаются в рамках инструментов проекта Safe C++», — подытожил Бакстер.

В начале августа Управление перспективных исследовательских проектов Министерства обороны США (DARPA) анонсировало проект TRACTOR (Translating All C to Rust) для разработки программного транслятора для автоматического преобразования проектов на языке C в представление на языке Rust. В рамках проекта TRACTOR планируется улучшить качество автоматического перевода кода с языка C на Rust, задействовав методы машинного обучения для достижения уровня результирующего кода на Rust, близкого по стилю и качеству к коду, написанному опытным программистом, и использующего, когда это возможно, безопасные методы для работы с памятью без включения блоков и функций, помеченных ключевым словом unsafe.

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

26 июня 2024 года специалисты агентства кибербезопасности и безопасности инфраструктуры США (CISA) опубликовали исследование с подробным анализом 172 ключевых Open Source проектов на предмет уязвимости исходного кода различных языков программирования к ошибкам памяти.

Согласно отчёту CISA:

• 52% критически популярных проектов с открытым исходным кодом содержат код, написанный на небезопасных для памяти языках;

• 55% от общего числа строк кода (LoC) в популярных и ключевых проектах написаны на небезопасных для памяти языках;

• крупнейшие проекты в непропорциональной мере написаны на небезопасных для памяти языках;

• из 10 крупнейших проектов по общему количеству строк кода каждый имеет долю небезопасного для памяти кода выше 26%;

• медианная доля небезопасного для памяти кода в крупных проектах составляет 62,5%, причём в 4 проектах показатель превышает 94%;

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

• среди исследованных проектов: ядро Linux (коэффициент небезопасного кода 95%), Tor (93%), Chromium (51%), MySQL Server (84%), glibc (85%), Redis (85%), SystemD (65%) и Electron (47%);

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

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

В выводах своего исследования CISA рекомендует разработчикам:

• использовать для создания нового кода безопасные для памяти языки, включая Rust, Java и Go;

• переводить существующие проекты, особенно их критически важные компоненты и сторонние элементы, на Rust, Java и Go;

• следовать мировым практикам безопасного кодирования;

• тщательнее управлять компонентной базой и проверять зависимости от других проектов и компонентов;

• проводить непрерывное тестирование кода, включая статический и динамический анализ;

• использовать фаззинг-тестирование для выявления и устранения проблем безопасности памяти в исходном коде проектов.

В ноябре 2022 года АНБ выпустило отчёт, в котором указало на то, что широко используемые языки программирования C и C++ дают хакерам больше возможностей для использования эксплойтов. В связи с этим АНБ рекомендует организациям переходить на безопасные языки программирования, такие как C#, Go, Java, Ruby, Rust и Swift. По мнению экспертов, это поможет предотвратить возникновение определённых типов уязвимостей, связанных с памятью.

В январе 2023 года изобретатель языка программирования C++ Бьёрн Страуструп ответил Агентству национальной безопасности (АНБ) США по поводу рекомендации ведомства отказаться от использования языков C и C++, перекладывающих управление памятью на разработчика, в пользу современных языков программирования (C#, Go, Java, Ruby, Rust и Swift), которые обеспечивают автоматическое управление памятью или выполняющие проверки безопасной работы с памятью во время компиляции кода. Страуструп призвал АНБ со своей стороны сначала серьёзно подумать о «безопасности» новых языков и только потом предлагать что-нибудь разумное по этому поводу. Учёный и разработчик считает, что упомянутые в отчёте АНБ «безопасные» языки программирования на самом деле не превосходят C++ в важных с его точки зрения применениях.

В конце февраля 2024 года Офис национального директора по кибербезопасности (ONCD) Белого дома США в рамках доклада о способах снижения количества уязвимостей в проектах и возможности в будущем улучшить надёжность ПО призвал разработчиков ПО в долгосрочной перспективе отказаться от небезопасных (в рамках работы с памятью) языках программирования С и С++ и перейти на более современные решения с высокой безопасностью памяти, например Rust, Python и Java.

Страуструп ответил на призыв Белого дома США переходить на языки с безопасностью памяти: «Я нахожу удивительным, что авторы этих государственных документов, похоже, не знают о сильных сторонах современного C++ и усилиях по обеспечению сильных гарантий безопасности. С другой стороны, они понимают, что язык программирования — это лишь одна часть набора инструментов, поэтому важно улучшать инструменты и процессы разработки». Страуструп напомнил, как он работал десятилетиями над тем, чтобы сделать язык безопаснее. Наконец, он поставил под сомнение само понимание безопасности: критики фокусируются на безопасности памяти, оставляя без внимания многие другие места, где можно проколоться.