Агентство по охране кибербезопасности и инфраструктуры США (CISA) и ФБР (Федеральное бюро расследований) развернули в среду безопасность по дизайну тревога«Устранение уязвимости переполнения буфера», как часть их кооперативной серии «Secure By Design»,-постоянная серия, направленная на развитие лучших практик в отрасли для устранения целых классов уязвимостей на этапах проектирования и разработки жизненного цикла продукта. Агентства признают уязвимости переполнения буфера как распространенный тип разработки программного обеспечения для безопасности памяти, который регулярно приводит к компромиссу системы. Они призывают производителей принять немедленные действия, чтобы предотвратить внедрение этих уязвимостей в продукты.
В предупреждении описываются проверенные методы предотвращения или смягчения уязвимостей переполнения буфера посредством безопасных принципов и лучших практик. Эти уязвимости переполнения буфера являются распространенным типом дефекта в разработке программного обеспечения, безопасного для памяти, который может привести к компромиссу систем. Эти уязвимости представляют серьезные риски безопасности, поскольку они могут привести к повреждению данных, конфиденциальному воздействию данных, сбоям программ и несанкционированному выполнению кода. Актеры угроз часто используют эти уязвимости, чтобы получить первоначальный доступ к сети организации, а затем перемещаются сбоку в более широкую сеть.
Агентства определили, что уязвимости буфера переполнены, когда актеры угроз получают доступ или записывают информацию в неверной части памяти компьютера (то есть вне буфера памяти). Эти уязвимости могут возникнуть в двух основных областях памяти, в которых управляются буферы: переполнения на основе стека (выделенные на стеке памяти) и переполнения на основе кучи (выделенные на кучу памяти).
CISA и FBI отметили, что производители могут предотвратить уязвимости переполнения буфера, используя безопасные практики программного обеспечения. дефект Кроме того, агентства рекомендуют, чтобы клиенты программного обеспечения гарантировали производители демонстрировать приверженность безопасной практике разработки программного обеспечения, содержащейся в предупреждении, запрашивая, чтобы производители предоставили счет материалов (SBOM) и безопасную аттестацию разработки программного обеспечения.
Чтобы предотвратить уязвимости переполнения буфера, некоторые технические лидеры компонентов должны реализовать, где возможно использование языков, безопасных для памяти при разработке программного обеспечения для сдвига бремени управления памятью с разработчика на встроенные функции безопасности языка программирования. Они признают, что можно отключить или отменить гарантии безопасности памяти некоторых безопасных для памяти языков; Разработчики должны избегать этого, чтобы предотвратить уязвимости переполнения буфера. Кроме того, использование безопасного для памяти языка для одной части программного пакета не исправляет код UNSAFE памяти в других библиотеках.
Авторические агентства признают, что необходимы значительные усилия для переписывания кодовых баз на языках, безопасных для памяти. Поэтому они рекомендуют производителям разработать и реализовать поэтапный план перехода для увеличения использования языка, безопасного для памяти. В идеале этот план должен включать использование языков, безопасных для памяти, для разработки нового кода и, с течением времени и при выполнении, переход самого привилегированного/раскрытого кода их программного обеспечения на языки, безопасные для памяти. Кроме того, при переходе на защитные языки для памяти производители должны рассмотреть возможность использования технологий для ограничения уязвимостей безопасности памяти в существующих кодовых базах, включить флаги компилятора, которые реализуют время компиляции и защиту времени выполнения от переполнений буфера, и реализуют канавки, которые предупреждают, если происходит переполнение.
Кроме того, технические лидеры должны проводить модульные тесты с инструментальным набором инструментов, такого как адресанитизатор Address и Memorysanitizer, который осуществляет исходный код с проверкой времени выполнения для переполнений буфера и других вопросов безопасности памяти. В кодовой базе со значительным покрытием модульных тестов такие инструменты могут обнаружить многие (но не все) связанные с безопасностью памяти проблемы, прежде чем они станут уязвимостью.
Они также должны провести агрессивное тестирование продукта, включая статический анализ, нечеткую и ручную обзоры (по мере необходимости), чтобы обеспечить качество и безопасность кода на протяжении всего жизненного цикла разработки; и опубликовать дорожную карту безопасности памяти с описанием того, как производитель планирует разработать новые продукты с безопасными для памяти языков и переносить код на безопасные языки памяти приоритетным образом.
Предупреждение также предписывало проводящий анализ первопричин прошлых уязвимостей, включая переполнения буфера, для определения тенденций и моделей. Там, где это возможно, предпринимайте действия по устранению целых классов уязвимостей между продуктами, а не поверхностными причинами.
Оповещение CISA и FBI заявило, что продукты, которые защищены дизайном, разумно защищают от вредоносных кибер -актеров, использующих наиболее распространенные и опасные классы дефекта продукта. Включение безопасности в начале жизненного цикла разработки программного обеспечения (начиная с этапа проектирования и продолжение разработки, выпуска и обновлений) снижает бремя для клиентов и риски для общественности. Несмотря на этот вывод, уязвимости переполнения буфера остаются распространенным классом дефектов.
Кроме того, если это возможно, производители должны работать над устранением уязвимостей буфера переполнения путем разработки нового программного обеспечения с использованием защиты памяти языков и лучших практик, описанных в этом предупреждении. Устранение уязвимостей переполнения буфера может помочь уменьшить распространенность других проблем безопасности памяти, таких как строка формата, вне одного и уязвимости без использования.
Производителям рекомендуется принять три принципа Secure By Design, разработанные 17 глобальными агентствами кибербезопасности для повышения безопасности программного обеспечения. Они должны взять на себя ответственность за результаты безопасности клиентов, устраняя уязвимости, такие как переполнение буфера, во время жизненного цикла разработки программного обеспечения. Это включает в себя использование безопасных строительных блоков, автоматических гарантий, инструментов статического анализа и строгих обзоров кода для предотвращения недостатков перед развертыванием, а не полагаться на исправления после релиза.
Производители также должны прозрачно раскрывать уязвимости с помощью таких программ, как общие уязвимости и воздействия (CVE), и использовать общее упоминание о слабости (CWE) для отслеживания классов дефектов. Они должны создать надежные программы раскрытия уязвимости (VDP) и группы реагирования на инциденты с инцидентами с продукцией (PSIRTS) для решения вопросов корневых причин и устранения проблем безопасности памяти.
Наконец, они должны создать организационную структуру и лидерство для достижения этих целей. Руководители должны рассматривать безопасность программного обеспечения как стратегические инвестиции, признавая его долгосрочную экономию затрат и более широкое влияние на клиентов, экономику и национальную безопасность. Примеры включают в себя принятие безопасных для памяти языков программирования (например, команда Android от Google) и устойчивое устранение классов уязвимости. Лидеры должны выделять ресурсы, контролировать прогресс и внедрять безопасность в качестве основного приоритета бизнеса.
Агентства рекомендовали производителям программного обеспечения рассмотреть вопрос о том, чтобы взять на себя обязательство по проектированию, чтобы продемонстрировать их приверженность созданию своих продуктов, чтобы быть безопасными по проектированию. Залог излагает семь ключевых целей, которые подписаны, чтобы продемонстрировать измеримый прогресс в обеспечении защиты своих продуктов по дизайну, включая снижение системных классов уязвимости, таких как переполнение буфера.
Клиенты должны требовать, чтобы программное обеспечение было безопасно по проектированию. Организации, стремящиеся приобрести программное обеспечение, которое безопасно по проектированию, должны относиться к безопасному руководству по требованию агентств и включить соображения безопасности продукта в их жизненный цикл закупок. Перед закупкой они должны задавать вопросы, чтобы понять, как каждый производитель программного обеспечения обеспечивает безопасность продукта; Во время закупок интегрируйте требования к безопасности организации в язык контракта; и после закупок они должны постоянно оценивать результаты безопасности продукта и результатов безопасности.
