Команда безопасности Android отвечает за управление уязвимостями безопасности, обнаруженными в платформе Android и многих основных приложениях Android, связанных с устройствами Android.
Команда безопасности Android находит уязвимости безопасности с помощью внутренних исследований, а также реагирует на ошибки, о которых сообщают третьи стороны. Источники внешних ошибок включают в себя проблемы, о которых сообщается через форму уязвимости , опубликованные и предварительно опубликованные академические исследования, вышестоящих разработчиков проектов с открытым исходным кодом, уведомления от наших партнеров-производителей устройств и публично раскрытые проблемы, опубликованные в блогах или социальных сетях.
Сообщение о проблемах безопасности
Любой разработчик, пользователь Android или исследователь безопасности может уведомить группу безопасности Android о потенциальных проблемах с безопасностью через форму уязвимости .
Ошибки, помеченные как проблемы безопасности, не видны извне, но в конечном итоге они могут стать видимыми после оценки или решения проблемы. Если вы планируете отправить исправление или тест Compatibility Test Suite (CTS) для решения проблемы безопасности, прикрепите его к отчету об ошибке и дождитесь ответа, прежде чем загружать код в AOSP.
Проверка ошибок
Первая задача при устранении уязвимости в системе безопасности — определить серьезность ошибки и определить, какой компонент Android затронут. Серьезность определяет, как проблема расставляется по приоритетам, а компонент определяет, кто исправляет ошибку, кто уведомляется и как исправление развертывается для пользователей.
Типы контекста
В этой таблице приведены определения контекстов безопасности аппаратного и программного обеспечения. Контекст может определяться конфиденциальностью данных, которые он обычно обрабатывает, или областью, в которой он работает. Не все контексты безопасности применимы ко всем системам. Эта таблица упорядочена от наименее к наиболее привилегированному.
| Тип контекста | Определение типа |
|---|---|
| Ограниченный контекст | Ограниченная среда выполнения, в которой предоставляются только самые минимальные разрешения. Например, доверенные приложения, обрабатывающие ненадежные данные в изолированной среде. |
| Непривилегированный контекст | Типичная среда выполнения, ожидаемая от непривилегированного кода. Например, приложение Android, работающее в домене SELinux с атрибутом untrusted_app_all . |
| Привилегированный контекст | Привилегированная среда выполнения, которая может иметь доступ к повышенным разрешениям, обрабатывать персональные данные нескольких пользователей и/или поддерживать целостность системы. Например, приложение Android с возможностями, которые были бы запрещены доменом SELinux untrusted_app или с доступом к privileged|signature . |
| Ядро ОС | Функциональность, которая:
|
| База доверенного оборудования (THB) | Дискретные аппаратные компоненты, как правило, на SoC, которые обеспечивают функциональность, критически важную для основных вариантов использования устройства (например, базовые полосы сотовой связи, DSP, графические процессоры и процессоры машинного обучения). |
| Цепочка загрузчика | Компонент, который настраивает устройство при загрузке, а затем передает управление ОС Android. |
| Надежная среда выполнения (TEE) | Компонент, предназначенный для защиты даже от враждебного ядра ОС (например, TrustZone и гипервизоров, таких как pKVM, которые защищают виртуальные машины от ядра ОС). |
| Безопасный анклав / безопасный элемент (SE) | Необязательный аппаратный компонент, предназначенный для защиты от всех других компонентов на устройстве и от физической атаки, как определено в разделе «Введение в элементы защиты» . Это включает в себя чип Titan-M, присутствующий в некоторых устройствах Android. |
Строгость
Серьезность ошибки обычно отражает потенциальный вред, который может быть нанесен, если ошибка будет успешно использована. Используйте следующие критерии для определения серьезности.
| Рейтинг | Результат успешной эксплуатации |
|---|---|
| Критический |
|
| Высокий |
|
| Умеренный |
|
| Низкий |
|
| Незначительное влияние на безопасность (NSI) |
|
Модификаторы рейтинга
Хотя серьезность уязвимостей безопасности часто легко определить, рейтинги могут меняться в зависимости от обстоятельств.
| Причина | Эффект |
|---|---|
| Для выполнения атаки требуется запуск в качестве привилегированного контекста (неприменимо к TEE, SE и гипервизорам, таким как pKVM) | -1 Серьезность |
| Подробная информация об уязвимости ограничивает влияние проблемы | -1 Серьезность |
| Обход биометрической аутентификации, требующий биометрической информации непосредственно от владельца устройства | -1 Серьезность |
| Конфигурации компилятора или платформы уменьшают уязвимость в исходном коде | Умеренная серьезность, если основная уязвимость имеет средний или более высокий уровень |
| Требуется физический доступ к внутренним компонентам устройства и все еще возможен, если устройство выключено или не было разблокировано с момента включения. | -1 Серьезность |
| Требуется физический доступ к внутренним компонентам устройства, когда оно включено и ранее было разблокировано. | -2 Серьезность |
| Локальная атака, требующая разблокировки цепочки загрузчика | Не выше, чем Низкий |
| Локальная атака, требующая, чтобы режим разработчика или какие-либо постоянные параметры режима разработчика были включены на устройстве в данный момент (и не является ошибкой в самом режиме разработчика). | Не выше, чем Низкий |
| Если ни один домен SELinux не может выполнять операцию в соответствии с предоставленной Google SEPolicy | Незначительное влияние на безопасность |
Локальный против проксимального против удаленного
Вектор удаленной атаки указывает на то, что баг можно использовать без установки приложения или без физического доступа к устройству. Сюда входят ошибки, которые могут быть вызваны просмотром веб-страницы, чтением электронной почты, получением SMS-сообщения или подключением к враждебной сети. Для оценки серьезности мы также считаем «ближайшие» векторы атак удаленными. К ним относятся ошибки, которые могут быть использованы только злоумышленником, который физически находится рядом с целевым устройством, например, ошибка, которая требует отправки искаженных пакетов Wi-Fi или Bluetooth. Мы рассматриваем сверхширокополосные (UWB) и атаки на основе NFC как ближайшие и, следовательно, удаленные.
Локальные атаки требуют, чтобы жертва запустила приложение, либо установив и запустив приложение, либо согласившись на запуск приложения с мгновенным запуском. Сопряженные устройства-компаньоны будут считаться локальными. В целях оценки серьезности группа безопасности Android также рассматривает векторы физических атак как локальные. К ним относятся ошибки, которые могут быть использованы только злоумышленником, имеющим физический доступ к устройству, например, ошибка на экране блокировки или ошибка, требующая подключения 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 OS использует многопользовательскую модель безопасности, отличную от других форм-факторов. Каждый пользователь Android предназначен для использования другим физическим лицом. Например, временный гостевой пользователь может быть назначен другу, который одалживает автомобиль у владельца автомобиля. Чтобы приспособиться к таким вариантам использования, пользователи по умолчанию имеют доступ к необходимым компонентам, необходимым для использования автомобиля, таким как настройки Wi-Fi и сотовой сети.
Затронутый компонент
Команда разработчиков, отвечающая за исправление ошибки, зависит от того, в каком компоненте обнаружена ошибка. Это может быть основной компонент платформы Android, драйвер ядра, предоставленный производителем оригинального оборудования (OEM), или одно из предварительно загруженных приложений на устройствах Pixel. .
Ошибки в коде AOSP исправляются командой разработчиков Android. Незначительные ошибки, ошибки в определенных компонентах или ошибки, которые уже широко известны, могут быть исправлены непосредственно в общедоступной основной ветке AOSP; в противном случае они сначала исправляются в наших внутренних репозиториях.
Компонент также влияет на то, как пользователи получают обновления. Ошибка в фреймворке или ядре требует беспроводного (OTA) обновления прошивки, которое должен отправить каждый OEM. Ошибка в приложении или библиотеке, опубликованной в Google Play (например, Gmail, Google Play Services или WebView), может быть отправлена пользователям Android в виде обновления из Google Play.
Уведомление партнеров
Когда уязвимость безопасности в AOSP будет устранена в бюллетене по безопасности Android, мы уведомим партнеров Android о подробностях проблемы и предоставим исправления. Список версий, поддерживаемых бэкпортом, меняется с каждым новым выпуском Android. Обратитесь к производителю устройства за списком поддерживаемых устройств.
Публикация кода в AOSP
Если ошибка безопасности находится в компоненте AOSP, исправление передается в AOSP после выпуска OTA для пользователей. Исправления для проблем с низким уровнем серьезности могут быть отправлены непосредственно в основную ветку AOSP до того, как исправление будет доступно для устройств через OTA.
Получение обновлений Android
Обновления системы Android обычно доставляются на устройства через пакеты обновлений OTA. Эти обновления могут поступать от OEM-производителя устройства или оператора связи, обслуживающего устройство. Обновления устройств Google Pixel поступают от команды Google Pixel после прохождения процедуры технического приемочного тестирования (TA). Google также публикует фабричные изображения Pixel , которые можно загружать на устройства.
Обновление сервисов Google
Помимо предоставления исправлений для ошибок безопасности, команда безопасности Android проверяет ошибки безопасности, чтобы определить, есть ли другие способы защитить пользователей. Например, Google Play сканирует все приложения и удаляет все приложения, которые пытаются использовать ошибку безопасности. Для приложений, установленных не из Google Play, устройства с сервисами Google Play также могут использовать функцию проверки приложений , чтобы предупредить пользователей о приложениях, которые могут быть потенциально опасными.
Другие источники
Информация для разработчиков приложений для Android: https://developer.android.com
Информация о безопасности доступна на сайтах Android с открытым исходным кодом и для разработчиков. Хорошие места для начала:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
отчеты
Иногда команда Android Security публикует отчеты или технические документы. Дополнительные сведения см. в разделе Отчеты о безопасности .