Команда безопасности Android отвечает за устранение уязвимостей, обнаруженных в платформе Android и многих основных приложениях Android, поставляемых с устройствами Android.
Команда специалистов по безопасности Android выявляет уязвимости посредством внутренних исследований, а также реагирует на сообщения об ошибках от третьих лиц. Источники внешних ошибок включают проблемы, о которых сообщается через форму сообщения об уязвимостях , опубликованные и предварительно опубликованные научные исследования, сопровождающих проектов с открытым исходным кодом, уведомления от наших партнеров-производителей устройств, а также публично раскрытые проблемы, размещенные в блогах или социальных сетях.
Сообщайте о проблемах безопасности
Любой разработчик, пользователь Android или исследователь безопасности может уведомить команду безопасности Android о потенциальных проблемах безопасности через форму сообщения об уязвимостях .
Ошибки, помеченные как проблемы безопасности, не видны извне, но со временем они могут стать видимыми после оценки или устранения проблемы. Если вы планируете отправить патч или тест из набора тестов совместимости (CTS) для устранения проблемы безопасности, пожалуйста, прикрепите его к отчету об ошибке и дождитесь ответа, прежде чем загружать код в AOSP.
Сортировка ошибок
Первоочередная задача при устранении уязвимости безопасности — определить серьезность ошибки и затронутый компонент Android. Серьезность определяет приоритетность проблемы, а компонент определяет, кто будет исправлять ошибку, кто будет уведомлен и как исправление будет развернуто для пользователей.
Типы контекста
В этой таблице приведены определения контекстов безопасности аппаратного и программного обеспечения. Контекст может определяться степенью конфиденциальности обрабатываемых данных или областью, в которой работает система. Не все контексты безопасности применимы ко всем системам. Таблица упорядочена от наименее привилегированного к наиболее привилегированному уровню.
| Тип контекста | Определение типа |
|---|---|
| Ограниченный контекст | Ограниченная среда выполнения, в которой предоставляются лишь минимальные права доступа. Например, доверенные приложения, обрабатывающие недоверенные данные в изолированной среде. |
| Непривилегированный контекст | Типичная среда выполнения, ожидаемая для кода без привилегий. Например, приложение для Android, работающее в домене SELinux с атрибутом untrusted_app_all . |
| Привилегированный контекст | Привилегированная среда выполнения, которая может иметь доступ к расширенным правам, обрабатывает персональные данные нескольких пользователей и/или поддерживает целостность системы. Например, приложение для Android с возможностями, которые были бы запрещены доменом SELinux untrusted_app , или с доступом к privileged|signature . |
| ядро ОС | Функциональность, которая:
|
| База доверенного оборудования (THB) | Дискретные аппаратные компоненты, как правило, расположенные на SoC, обеспечивают функциональность, критически важную для основных сценариев использования устройства (например, базовые полосы сотовой связи, цифровые сигнальные процессоры, графические процессоры и процессоры машинного обучения). |
| Цепочка загрузчиков | Компонент, который настраивает устройство при загрузке, а затем передает управление операционной системе Android. |
| Доверенная среда выполнения (TEE) | Компонент, предназначенный для защиты даже от враждебного ядра ОС (например, TrustZone и гипервизоры, такие как pKVM, которые защищают виртуальные машины от ядра ОС). |
| Защищенный анклав / Защищенный элемент (SE) | Дополнительный аппаратный компонент, предназначенный для защиты от всех других компонентов устройства и от физических атак, как определено в разделе «Введение в защищенные элементы» . Это включает в себя чип Titan-M, присутствующий в некоторых устройствах Android. |
Степень тяжести
Серьезность ошибки, как правило, отражает потенциальный вред, который может быть причинен в случае успешной эксплуатации этой ошибки. Используйте следующие критерии для определения серьезности.
| Рейтинг | Последствия успешной эксплуатации |
|---|---|
| Критический |
|
| Высокий |
|
| Умеренный |
|
| Низкий |
|
| Незначительное влияние на безопасность (NSI) |
|
Модификаторы тяжести
Хотя серьезность уязвимостей в системе безопасности часто легко определить, рейтинги могут меняться в зависимости от обстоятельств.
| Причина | Эффект |
|---|---|
| Для выполнения атаки требуется запуск в привилегированном контексте (не применимо к TEE, SE и гипервизорам, таким как pKVM). | -1 Степень тяжести |
| Детали, специфичные для данной уязвимости, ограничивают влияние проблемы. | -1 Степень тяжести |
| Обход биометрической аутентификации, требующий предоставления биометрической информации непосредственно от владельца устройства. | -1 Степень тяжести |
| Настройки компилятора или платформы позволяют устранить уязвимость в исходном коде. | Умеренная степень серьезности, если базовая уязвимость имеет умеренный или более высокий уровень. |
| Требуется физический доступ к внутренним компонентам устройства, и это возможно, даже если устройство выключено или не было разблокировано после включения. | -1 Степень тяжести |
| Требуется физический доступ к внутренним компонентам устройства при его включенном состоянии и предварительной разблокировке. | -2 Степень тяжести |
| Локальная атака, требующая разблокировки цепочки загрузчика. | Не выше низкого уровня |
| Локальная атака, требующая включения режима разработчика или любых постоянных настроек режима разработчика на устройстве (и не являющаяся ошибкой в самом режиме разработчика). | Не выше низкого уровня |
| Если ни один домен SELinux не может выполнить операцию в соответствии с политикой SEPolicy, предоставленной Google. | Незначительное влияние на безопасность |
Локальный, ближний или дальний
Вектор удаленной атаки указывает на то, что уязвимость может быть использована без установки приложения или без физического доступа к устройству. Это включает в себя уязвимости, которые могут быть вызваны просмотром веб-страницы, чтением электронного письма, получением SMS-сообщения или подключением к враждебной сети.
Проксимальные векторы атак считаются удаленными. К ним относятся ошибки, которые могут быть использованы только злоумышленником, физически находящимся рядом с целевым устройством, например, ошибка, требующая отправки некорректных пакетов Wi-Fi или Bluetooth. Мы рассматриваем атаки на основе сверхширокополосной связи (UWB) и NFC как проксимальные и, следовательно, удаленные.
Для локальных атак злоумышленнику необходим предварительный доступ к жертве. В гипотетическом примере с использованием только программного обеспечения это может быть вредоносное приложение, установленное жертвой, или приложение Instant App, на запуск которого она дала согласие.
Успешно сопряженные устройства (например, устройства-компаньоны Bluetooth) считаются локальными. Мы различаем сопряженное устройство и устройство, участвующее в процессе сопряжения.
- Ошибки, ухудшающие способность пользователя идентифицировать другое устройство, с которым выполняется сопряжение (т.е. аутентификация), считаются непосредственными, а следовательно, и удалёнными.
- Ошибки, возникающие в процессе сопряжения, но до получения согласия пользователя (т.е. авторизации), считаются непосредственными, а следовательно, и отдаленными.
- Ошибки, возникающие после получения согласия пользователя, считаются локальными, даже если сопряжение в конечном итоге не удается.
Физические векторы атаки считаются локальными. К ним относятся ошибки, которые могут быть использованы только злоумышленником, имеющим физический доступ к устройству, например, ошибка в экране блокировки или ошибка, требующая подключения USB-кабеля. Поскольку устройства часто разблокируются при подключении к USB, атаки, требующие USB-соединения, имеют одинаковую степень серьезности независимо от того, требуется ли разблокировка устройства или нет.
Сетевая безопасность
Android исходит из предположения, что все сети враждебны и могут внедрять атаки или шпионить за трафиком. Хотя безопасность на канальном уровне (например, шифрование Wi-Fi) защищает связь между устройством и точкой доступа, к которой оно подключено, она никак не защищает остальные звенья цепочки между устройством и серверами, с которыми оно взаимодействует.
В отличие от этого, HTTPS обычно защищает весь процесс передачи данных от начала до конца, шифруя данные на источнике, а затем расшифровывая и проверяя их только после достижения конечного пункта назначения. Из-за этого уязвимости, ставящие под угрозу безопасность сети на канальном уровне, оцениваются как менее серьезные, чем уязвимости в HTTPS/TLS: одного шифрования Wi-Fi недостаточно для большинства видов обмена данными в интернете.
Биометрическая аутентификация
Биометрическая аутентификация — сложная область, и даже лучшие системы могут быть обмануты почти идентичными данными (см. блог разработчиков Android: улучшения экрана блокировки и аутентификации в Android 11 ). Эти рейтинги серьезности различают два класса атак и призваны отражать реальный риск для конечного пользователя.
Первый класс атак позволяет обойти биометрическую аутентификацию универсальным способом, без высококачественных биометрических данных владельца. Например, если злоумышленник может приложить кусочек жевательной резинки к датчику отпечатков пальцев, и это предоставит доступ к устройству на основе остатков, оставшихся на датчике, это простая атака, которую можно выполнить на любом уязвимом устройстве. Для этого не требуется знать владельца устройства. Учитывая универсальность атаки и потенциальную угрозу для большего числа пользователей, она получает максимальную оценку серьезности (например, высокую для обхода блокировки экрана).
Другой класс атак, как правило, включает в себя использование инструмента подмены биометрических данных (спуфинга) на основе данных владельца устройства. Иногда получить эту биометрическую информацию относительно легко (например, если фотографии профиля в социальных сетях достаточно, чтобы обмануть биометрическую аутентификацию, то обход биометрической аутентификации получит максимальную степень опасности). Но если злоумышленнику потребуется получить биометрические данные непосредственно от владельца устройства (например, инфракрасное сканирование его лица), это достаточно серьезное препятствие, которое ограничивает количество людей, затронутых атакой, поэтому применяется модификатор -1.
SYSTEM_ALERT_WINDOW и перехват трафика
Информацию о нашей политике в отношении уязвимости SYSTEM_ALERT_WINDOW и перехвата вызовов можно найти в разделе « Перехват вызовов/наложение уязвимости SYSTEM_ALERT_WINDOW на некритичный для безопасности экран » на странице BugHunter University, посвященной ошибкам, не влияющим на безопасность .
Многопользовательская безопасность в Android Automotive OS
Операционная система Android Automotive использует многопользовательскую модель безопасности, отличающуюся от других форм-факторов. Каждый пользователь Android предназначен для использования отдельным физическим лицом. Например, временный гостевой пользователь может быть назначен другу, который берет автомобиль у владельца. Для обеспечения таких сценариев использования пользователи по умолчанию имеют доступ к необходимым компонентам для использования автомобиля, таким как настройки Wi-Fi и сотовой сети.
Затронутый компонент
Команда разработчиков, ответственная за исправление ошибки, зависит от того, в каком компоненте она находится. Это может быть основной компонент платформы Android, драйвер ядра, предоставленный производителем оригинального оборудования (OEM), или одно из предустановленных приложений на устройствах Pixel.
Ошибки в коде AOSP исправляются командой разработчиков Android в наших внутренних репозиториях.
Компонент также влияет на то, как пользователи получают обновления. Ошибка в фреймворке или ядре требует обновления прошивки по беспроводной сети (OTA), которое должен распространить каждый производитель оборудования. Ошибка в приложении или библиотеке, опубликованной в Google Play (например, Gmail, Google Play Services или WebView), может быть отправлена пользователям Android в виде обновления из Google Play.
Уведомить партнеров
Когда уязвимость безопасности в AOSP исправляется в бюллетене безопасности Android, мы уведомляем партнеров Android о подробностях проблемы и предоставляем исправления. Список поддерживаемых версий меняется с каждым новым релизом Android. Обратитесь к производителю вашего устройства за списком поддерживаемых устройств.
Выпустить код в AOSP
Если уязвимость безопасности находится в компоненте AOSP, исправление распространяется в AOSP после того, как OTA-обновление станет доступно пользователям.
Получайте обновления для Android
Обновления системы Android обычно доставляются на устройства через пакеты OTA-обновлений. Эти обновления могут поступать от производителя устройства или от оператора связи, предоставляющего услуги для данного устройства. Обновления для устройств Google Pixel поступают от команды Google Pixel после прохождения процедуры технического приемочного тестирования у оператора связи. Google также публикует заводские образы Pixel , которые можно установить на устройства без предварительной установки (sideloading).
Обновите службы Google.
Помимо исправления уязвимостей безопасности, команда безопасности Android проверяет обнаруженные уязвимости, чтобы определить, существуют ли другие способы защиты пользователей. Например, Google Play сканирует все приложения и удаляет любые приложения, пытающиеся использовать уязвимости безопасности. Для приложений, установленных вне Google Play, устройства с Google Play Services также могут использовать функцию проверки приложений , чтобы предупредить пользователей о приложениях, которые могут быть потенциально опасными.
Другие ресурсы
Информация для разработчиков приложений Android: https://developer.android.com
Информация о безопасности доступна на сайтах Android Open Source и сайтах для разработчиков. Хорошие отправные точки:
Отчеты
Иногда команда специалистов по безопасности Android публикует отчеты или аналитические статьи. Подробнее см. в разделе «Отчеты по безопасности» .