Google заявляет: переход на Rust резко уменьшил количество ошибок памяти в Android — местами в тысячи раз. Разбираемся, что стоит за цифрами, насколько это делает платформу безопаснее и какие риски остаются.
TL;DR
- Исторически большинство критических уязвимостей Android были связаны с безопасностью памяти в C/C++.
- Google сообщает: внедрение Rust в системные компоненты сократило дефектность кода по безопасности памяти до статистически близкой к нулю и местами — в тысячи раз относительно C/C++.
- Android не стал «неуязвимым»: остаются логические ошибки, уязвимости на границах FFI, большой пласт унаследованного C/C++ и драйверов ядра.
- Тренд устойчивый: доля memory-safety багов в Android снижается несколько лет подряд, а доля нового системного кода на Rust растёт.
- Следующий рубеж — расширение Rust в ядре Linux/драйверах для Android и дисциплина при стыковке языков.
Откуда взялась цифра «в тысячи раз»
Исторически до трех четвертей уязвимостей платформы Android приходилось на проблемы с безопасностью памяти: use-after-free, переполнения буферов, ошибки работы с указателями и гонки данных. Это последствия ручного управления памятью в C/C++. Начиная с 2021 года Google целенаправленно внедряет Rust в Android Open Source Project (AOSP) для высокорискованных модулей — тех, что обрабатывают непроверенные входные данные или работают с высокими привилегиями.
По данным команды безопасности Android, дефектность кода на Rust по классу memory-safety оказалась на порядки ниже, чем в сопоставимом C/C++: в ряде компонентов фактически не выявляется уязвимостей данного типа, а совокупная «плотность уязвимостей» на строку кода — на несколько порядков меньше. Именно отсюда формулировка про «снижение в тысячи раз» — это не абсолютное зануление уязвимостей, а оценка относительной частоты обнаружения ошибок памяти в Rust-коде против C/C++ при сравнимом масштабе.
Тренд прослеживается и в агрегированных метриках: доля уязвимостей Android, связанных с памятью, последовательно снижается в годовых отчётах. Переход на Rust — не единственный фактор (влияют также улучшения санитайзеров, CFI, MTE и ужесточение процессов ревью), но это наиболее заметный структурный сдвиг.
Где в Android уже работает Rust
В AOSP Rust используется прежде всего там, где важна жёсткая память-безопасность без потери производительности: системные сервисы с повышенными привилегиями, парсеры и обработчики непроверенных данных, элементы виртуализации и криптографические подсистемы. Ключевые примеры — новые или переработанные системные службы, компоненты Android Virtualization Framework, а также части стека, где традиционно накапливались memory-safety ошибки.
Практический эффект складывается из двух факторов:
- Безопасный по умолчанию язык: модель владения и заимствования, отсутствие «диких» указателей и безопасная конкурентность исключают целые классы уязвимостей на уровне компиляции.
- Контролируемые «стыки» с C/C++: область повышенного риска — FFI-интерфейсы. Но Google стремится делать их тонкими, тщательно ревьюировать и покрывать fuzz-тестами, уменьшая площадь атаки.
Стала ли платформа «неуязвимой»
Короткий ответ — нет. Существенное снижение уязвимостей памяти не отменяет существование других классов проблем и «старых» рисков:
- Логические ошибки и нарушения политик доступа: авторизация, ошибка в проверках разрешений, непредусмотренные сценарии взаимодействия между компонентами.
- Большой пласт унаследованного C/C++: ядро Linux, многие драйверы и часть пользовательского нативного стека всё ещё на C/C++. Здесь по‑прежнему возможны классические memory-safety баги.
- Границы языков (FFI): ошибки на стыке Rust и C/C++ могут нивелировать выгодy Rust, если интерфейсы широкие, с небезопасными контрактами, или недостаточно тестируются.
- Сторонние и вендорские компоненты: производственные конфигурации Android зависят от кода поставщиков чипсетов и OEM. Ритм обновлений и качество кода вне AOSP различаются.
При этом важно: снижение доли уязвимостей, связанных с памятью, — это снижение наиболее опасной категории дефектов, которые чаще ведут к RCE и sandbox escape. То есть риск тяжёлых эксплуатаций уменьшается непропорционально сильнее.
Почему Rust даёт такой выигрыш
- Память-безопасность по умолчанию: в «безопасном» подмножестве Rust невозможны use-after-free, двойные освобождения, выход за границы буфера, гонки данных — всё это ловится компилятором.
- Нулевые затраты на рантайм: нет сборщика мусора; контроль жизненного цикла объектов статически формализован, что облегчает предсказуемость производительности в системном коде.
- Совместимость: Rust встроен в сборочный конвейер AOSP, поддерживает межъязыковое взаимодействие, позволяет поэтапно «зашивать» критичные места без полной переписки.
- Тестопригодность: развитая экосистема fuzzing и property-based тестирования делает атакуемые парсеры и протоколы более устойчивыми.
Ограничения подхода и точки внимания
- FFI-дисциплина: держать «швы» узкими, документировать инварианты, использовать проверенные шины взаимодействия и генераторы биндингов, агрессивно фуззить интерфейсы.
- Покрытие: чем больше критичного кода написано на Rust, тем меньше вероятность memory-safety классов проблем. Но полная миграция невозможна в краткие сроки.
- Ядро и драйверы: Rust в ядре Linux уже поддерживается, и это стратегическое направление для Android. Масштабное применение там способно ещё сильнее снизить риски.
- Комплексные меры: Rust не заменяет MTE, CFI, sanitizers, sandboxing и формальные процессы код-ревью — эти слои должны работать совместно.
Что это означает для команд разработки и бизнеса
- Выбор языка по угрозам: новый системный код, работающий с непроверенными данными, целесообразно по умолчанию писать на Rust. Высокоуровневые компоненты — на Kotlin/Java, нативный C/C++ — только при веских причинах и с сильными митигациями.
- Метрики качества: отслеживайте долю кода на Rust в критичных модулях, плотность дефектов по классам, покрытие fuzzing и время реакции на отчёты.
- План миграции: идентифицируйте «горячие точки» в C/C++ (парсеры, обработчики протоколов, привилегированные сервисы) и планируйте их локальную замену на Rust с минимальными FFI-швами.
- Тестирование и баг-баунти: фокусируйтесь на логических ошибках и границах взаимодействия — там остаётся основная «новая» площадь атаки.
Вывод
Заявление Google о «тысячекратном» снижении ошибок — не маркетинговый трюк, а отражение реального сдвига: перенос критичных системных частей Android на Rust ощутимо «перекрывает кислород» целому классу самых опасных уязвимостей. Это не делает платформу неуязвимой, но заметно повышает её базовый уровень безопасности и усложняет жизнь атакующим. Следующий шаг — расширение Rust в ядре и драйверах, дисциплина на границах языков и продолжение многослойной обороны. Тренд понятен и, судя по метрикам, устойчив.
