Вернемся к проблемам С++.

Пост нудный, унылый, но дьявол как грится в мелочах.

“30-50% репозиториев Rust используют небезопасный код, в отличие от, например, 25% библиотек Java”.

Основные проблемы "безопасности языка C++”.

• Мы знаем, что существует 4 “проблемы” безопасности которые нуждаются в улучшении:  type, bounds, initialization, и lifetime safety. Это наиболее очевидные проблемы и это только четыре из, возможно, двух десятков видов "безопасности", включая такие, как безопасное целочисленное сложение. Большинство из них либо являются меньшим источником зол, либо важны главным образом потому, что они влияют на эти четыре основные категории.

• Большинство MSL (memory-safe languages, языков с безопасным управлением памятью) не обеспечивают безопасность по умолчанию, обычно из-за затрат на проверки. Однако все языки (включая C) обычно имеют библиотеки и инструменты для решения этих проблем, такие как библиотека SafeInt для C от Microsoft для обработки переполнений целых чисел. В C#, например, есть языковая функция проверяемого арифметического для обработки переполнений целых чисел (проверка и не проверка управляемые операторы — управление контекстом переполнения проверка - C# reference | Microsoft Learn). Встроенные целые числа Python безопасны по умолчанию, потому что они автоматически расширяются, однако популярные фиксированного размера целочисленные типы NumPy не проверяют переполнение по умолчанию и требуют использования проверенных функций, что также является необязательным.

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

• Однако, утверждение, что языки должны быть формально доказуемо безопасными, немного излишне. Например, ни один из широко используемых языков, кроме Rust, не заявляет о полной безопасности потоков!
• Такие языки как C#, Java, все ещё имеют проблемы с использованием объектов до их инициализации и после их удаления. Rust, Go и другие языки также поддерживают санитайзеры, включая ThreadSanitizer и undefined behavior sanitizers.

Это связано с тем, что выбор гарантий безопасности языка - это компромисс: например, в Rust безопасный код использует динамические деревья данных только для узлов. Это позволяет Rust предоставлять более сильные гарантии безопасности потоков, чем другие языки, поскольку он может лучше выводить и контролировать проксирование. Однако это же свойство также требует от программ Rust использовать небезопасный код чаще, чтобы представлять общие структуры данных, которые не требуют небезопасного кода для представления в других MSL, таких как C# или Java, и поэтому 30-50% репозиториев Rust используют небезопасный код, в отличие от, например, 25% библиотек Java.

Проблема "не" заключается в том, что уход всего мира от C и C++ в другие языки (MSL) устранит 70% уязвимостей безопасности.

• Цифра "70%" относится к подмножеству уязвимостей, которые могут быть решены с помощью безопасности языка программирования. Многие из крупнейших утечек данных и кибератак 2023 года не имели отношения к языкам программирования.
• Языки MSL тоже получают CVE (Common Vulnerabilities and Exposures), хотя и меньше. Например, в 2024 году было зафиксировано шесть уязвимостей в Rust.

В 2023 году хакеры снизили использование вредоносного ПО, поскольку программное обеспечение становится менее уязвимым + относительно эффективна защита конечных точек (CRN). Большинство проблем, указанных в NISTIR-8397, касаются всех языков одинаково, поскольку они выходят за рамки безопасности памяти (например, Log4j) или даже программных языков (например, автоматизированное тестирование, включение защит ОС, внедрение строк/SQL-инъекций, и т.д).

#новостизанеделю #айти #Новости #программирование #программист