CISA выпустило доклад о небезопасности кода критических систем. В чем проблема?
26 июня Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) выпустило доклад Exploring Memory Safety in Critical Open Source Projects — исследование безопасности кода на предмет работы с памятью в критически важных программных проектах с открытым исходным кодом.
Всего было исследовано 172 важнейших проекта, включая ядро операционной системы (ОС) Linux, ключевые подсистемы и базовые библиотеки Linux, системы управления базами данных (СУБД) MySQL, Redis, движки веб-браузеров Chromium и Gecko, виртуальную машину KVM и многое другое.
Выяснилось, что 52% критически важных проектов содержат код, написанный на потенциально небезопасных языках. 55% строк кода указанных проектов написано на небезопасных языках. Причем ядро ОС Linux на 95% состоит из кода на небезопасных языках.
В основном речь идет об использовании языков программирования C и C++, позволяющих прямую работу с памятью. Некорректно написанный код может привести к сбоям в работе приложений или формированию уязвимости. Наиболее частые ошибки — это выход за границы выделенной памяти и считывание ранее внесенных другим процессом в память значений.
Первый тип ошибок формирует потенциальную уязвимость исполнения произвольного кода злоумышленника, второй дает шанс считать данные, на получение которых у пользователя нет прав. Такие ошибки возникают в основном в силу невнимательности программиста и недостаточности тестирования программного обеспечения (ПО), но бывает, что их очень сложно обнаружить.
При этом ряд языков программирования обеспечивает более безопасную работу с памятью. В докладе обозначены C#, Go, Java, Python, Rust и Swift. Часть из них недостаточно производительна для системного программирования, часть — жестко связана с компаниями-разработчиками. Постепенно внедряется системный язык Rust, который не связан сильно с коммерческими компаниями и ключевой особенностью которого является реализация безопасной работы с памятью.
В CISA рекомендуют новые проекты писать на безопасных по работе с памятью языках, старое ПО переводить постепенно на безопасные языки, отказываться от зависимостей от библиотек с потенциально небезопасным кодом, регулярно и тщательно тестировать ПО на предмет ошибок работы с памятью.
В чем проблема доклада CISA?
Обозначенное критически важное открытое ПО создавалось годами и десятилетиями. В него вложены многие тысячи человеко-лет и написаны миллиарды строк кода. Код оптимизировался и отлаживался на различных уровнях. Взять и переписать всё на новых языках практически нереально. Но это не главная проблема, в конце концов в CISA рекомендуют писать новое ПО на безопасных языках и постепенно заменять старые компоненты новыми решениями.
Основная проблема — в производительности ПО, разработанного на разных языках и работающего на одном и том же аппаратном вычислительном средстве. Ядро ОС, СУБД, виртуальные машины, компилятор, веб-сервер и ряд других упомянутых программных продуктов должны работать максимально быстро. И их регулярно оптимизируют под быструю работу как на уровне архитектуры, так и кода.
Для создания подобных продуктов наилучшим образом из обозначенных языков подходит Rust. Во-первых, он в среднем компилируется, то есть преобразуется из текста на человеко-понятном языке в инструкции для компьютера или виртуальной машины в наиболее производительный код, во-вторых, не связан жестко с какой-либо крупной коммерческой компанией. В Rust код можно писать в безопасном в работе с памятью режиме и небезопасном. Безопасный режим включен по умолчанию, но накладывает дополнительные накладные расходы. Такой код компилируется в менее производительный код. В некоторых случаях разница может быть в два раза и более.
При этом решается только проблема безопасной работы с памятью. Требования языка и компилятор берут на себя задачу обеспечения безопасной работы с памятью. Автор языка C++ Бьорн Страуструп считает, что доклад фокусируется лишь на работе с памятью, тогда как есть множество других мест, в которых программист может породить ошибку. Он предложил тщательно проверить новые средства разработки на безопасность, прежде чем предлагать переписать всё на них. Страуструп десятилетиями работал над обеспечением безопасной разработки на C++.
С другой стороны, в мире доминирует аппаратное обеспечение, построенное на процессорах с набором команд x86-64. Это очень производительные процессоры с весьма широкими возможностями для программирования под них — практически всеядные. Слабой их стороной является недостаточное внимание к обеспечению безопасного режима работы с той же памятью на уровне аппаратуры. Например, в отечественных «Эльбрусах» такой безопасный режим есть.
Внесение изменений в архитектуру процессоров x86-64 и их микрокод с целью обеспечения безопасности работы с памятью и не только — это тяжелая задача, которая не будет решена быстро без значительной потери в производительности. Пример уже есть — каждое исправление, связанное с защитой от уязвимостей спекулятивного исполнения команд, приводило к значимому падению скорости процессоров. А безопасный режим — более тяжелая задача, особенно при учете сложности современных процессоров. Она потребует годы работы для достижения высокой надежности и эффективности.
Таким образом, формируется ситуация, когда производители аппаратуры гонятся за удобством и производительностью. Затем значительная часть этой производительности будет съедена на накладные ресурсы ради удобства и упрощения разработки с учетом требований безопасности.
На первый взгляд процессоры x86-64 (изделия компаний Intel и AMD — прим. ИА Красная Весна) очень быстрые и удобные. Их производительность постоянно растет. Ключевое ПО станет безопаснее. Всё замечательно с точки зрения маркетинга. При чуть более подробном изучении вопроса выходит, что для обеспечения той же скорости работы потребуется больше оборудования или более производительное оборудование.
В чем политико-экономическая составляющая?
США ведут торговую войну с Китаем. Китаю ставят барьеры на покупку оборудования для производства, тестирования и продвинутой упаковки микросхем, технологий, расходных материалов. Это возможно, поскольку за счет технологических лицензий, политических и иных возможностей США во многом контролируют мировую полупроводниковую отрасль.
При этом ключевые центры производства чипов — Тайвань и Южная Корея находятся территориально близ Китая. Китай считает Тайвань своей частью. В этой игре США делают ставку на формирование полноценной отрасли производства полупроводниковых приборов на своей территории. Отрасли нужен спрос для развития.
Доклад CISA в случае его принятия американской ИТ-индустрией, а следом и большей частью мировой индустрии, вольно или невольно смещает баланс в пользу дальнейшей компенсации недостатков производительности ПО за счет оборудования. При этом убиваются сразу два зайца: разрабатываемое ПО может стать безопаснее без внесения серьезных изменений в архитектуру — переноса части функций обеспечения безопасного взаимодействия процессов и работы с памятью на оборудование и обеспечивается дополнительный спрос на аппаратное обеспечение.
В США и странах-покупателях это сформирует спрос на оборудование в условиях тенденции к регионализации производства. Обеспечение рентабельности такого производства и снижение цены изделий возможно за счет массовости, что требует высокого уровня спроса на продукцию.
Почему этот вопрос может быть интересен в России?
Западные санкции после начала специальной военной операции отлучили наш рынок от прямых поставок западного оборудования и ПО. Казалось бы, доклад и дискуссию вокруг него имеет смысл рассматривать лишь в качестве чужого опыта. Но есть пара нюансов.
Во-первых, только-только формирующееся отдельное российское сообщество открытого ПО всё еще сильно привязано к западным лекалам и концепциям. Любое изменение вокруг западного открытого ПО тут же становится предметом обсуждения.
Во-вторых, дискуссия вокруг доклада — это возможность посмотреть на вычислительные средства немного шире, чем измерение производительности в неких попугаях. ФЛОПСах, например. В вычислительной электронике мы сильно отстаем от Запада. Но в «Эльбрусах» обеспечили безопасный режим работы на уровне процессора — является ли это преимуществом, которое нужно учитывать?
Вопрос безопасности вычислений выходит постепенно на более значимое место в ИТ. Хотя бы в силу необходимости обеспечения кибербезопасности в мире, где процессы активно автоматизируются и всё больше систем становится киберфизическими, а не только виртуальными.
