Эксперты АНБ проанализировали безопасность ОС Google Fuchsia

Эксперты АНБ проанализировали безопасность ОС Google Fuchsia

Эксперты АНБ проанализировали безопасность ОС Google Fuchsia

Агентство национальной безопасности (АНБ) США проанализировала новую операционную систему Fuchsia, разрабатываемую Google. Своими выводами представители спецслужбы поделились на саммите North American Linux Security Summit, прошедшем в Ванкувере.

С докладом выступили Джеймс Картер и Стивен Смолли, сотрудники АНБ. Эксперты раскрыти некоторые секреты Fuchsia, а также ее ядра Zircon. Упор в исследованиях делался на безопасность этих компонентов.

Изначально Zircon представлял собой форк Little Kernel — загрузчика операционной системы Android. Он был тщательно переработан и модифицирован, что превратило его в микроядро операционной системы.

На данный момент Zircon включает небольшой набор сервисов, драйверов и библиотек. Они используются для загрузки системы, взаимодействия с аппаратной начинкой и загрузки процессов.

Поскольку Fuchsia является операционной системой с модульной структурой, пользователь может запускать ее на минимально производительных устройствах. Также эта ОС может использоваться и на мощных машинах, все будет зависеть лишь от количества модулей, подключенных для расширения функционала.

Картеру и Смолли поставили задачу — исследовать операционную систему на предмет возможного использования в интересах национальной безопасности. Если проще, то эксперты должны были протестировать, насколько легко взломать Fuchsia.

Первым делом исследователи обнаружили, что Zircon является единственной частью ОС, которая работает в режиме супервизора. Все остальное — драйвера, файловые системы, сеть — работает в режиме пользователя.

Это значит, что подход к программам в Fuchsia будет носить совершенно другой оттенок, нежели в других операционных системах. Присмотревшись к системе подробнее, специалисты нашли некоторое количество проблем безопасности.

«Например, утечка хэндла root job. Это очень критично для безопасности», — говорит Картер.

Следовательно, разработчикам Google еще есть над чем работать, особенно уделяя внимание проблемам безопасности новой операционной системы.

С выводами экспертов можно ознакомиться на видео ниже:

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

Проще говоря, чем активнее подсистема используется и исследуется, тем быстрее там находят ошибки.

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

RSS: Новости на портале Anti-Malware.ru