Часть 1.

Совсем недавно Белый дом 😀, в своем бесконечном стремлении к инновациям, выпустил технический отчет, в котором посоветовал разработчикам бросить всё и немедленно начать использовать альтернативные языки вместо C/C, чтобы избежать уязвимостей, связанных с памятью. О да, Агентство национальной безопасности (NSA) рекомендует такие языки, как Rust и Python, как чудесные заменители C и C. Конечно, у этих языков тоже есть свои проблемы, но кто мы такие, чтобы спорить с NSA о безопасности памяти, правда?

Однако, буквально в 2017 году, произошла утечка, где черным по белому и косвенно Центральное разведывательное управление США советовало изучать клиент-серверное программирование на C. Эта утечка является частью коллекции Vault 8 и включает в себя инструмент Hive, который состоит из двух частей: серверная часть управляет клиентом, который скрытно работает на зараженном устройстве. Шпионское ПО предназначено для установки на устройства ARM, MIPS, PowerPC и x86 под управлением Linux, особенно на маршрутизаторы и интернет-камеры Mikrokit и AVTech.

Итак, давайте сосредоточимся на C++ и попробуем разобрать, в чем же заключается его проблема (их много 😀), и как мы можем их решить, основываясь на уже начатых решениях (потому что конечно, мы уже работаем над этим, верно?).

Также развеем некоторые распространенные заблуждения (в чем проблема C++ не заключается), включая практические соображения о MSL (потому что, очевидно, это важно).

И, конечно, оставим призыв к действию для программистов, использующих все языки (потому что кто не любит хороший призыв к действию?).

Давайте углубимся.

Немедленная проблема заключается в том, что “слишком легко по умолчанию” писать уязвимости в области безопасности и надежности в C, которые могли бы быть пойманы при строгом соблюдении известных правил безопасности типов, границ, инициализации и.т.д. В C нам нужно начать с улучшения этих четырех категорий. Это основные четыре источника улучшений, предоставляемые всеми MSL, которые NIST/NSA/CISA рекомендуют использовать вместо C, поэтому, по определению, устранение этих четырех решило бы текущие проблемы NIST/NSA/CISA с C.

И во все последние годы включая 2023, эти четыре категории составляют основную часть тех часто цитируемых 70% CVE (Общие уязвимости и воздействия), связанных с небезопасностью памяти в языке. (Однако эти «70% CVE небезопасности памяти» вводят в заблуждение, например, на рисунке большинство из самых опасных слабостей MITRE в 2023 году не касаются безопасности языка и поэтому не включены в этот знаменатель).

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

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

#новостизанеделю #программирование #программист #код #кибербезопасность #хакер #взлом #айти #информационнаябезопасность #сша #байден #безопасность