Группа безопасности 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 публикует отчеты или технические документы. Дополнительные сведения см. в разделе Отчеты о безопасности .
,Команда безопасности 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 ). Эти оценки серьезности различают два класса атак и предназначены для отражения фактического риска для конечного пользователя.
Первый класс атак позволяет обойти биометрическую аутентификацию обобщающим образом, без получения качественных биометрических данных от владельца. Если, например, злоумышленник может поместить кусочек жевательной резинки на датчик отпечатков пальцев, и он предоставит доступ к устройству на основе остатка, оставшегося на датчике, это простая атака, которую можно выполнить на любом уязвимом устройстве. Это не требует каких-либо знаний владельца устройства. Учитывая, что она универсальна и потенциально затрагивает большее количество пользователей, эта атака получает полный рейтинг серьезности (например, высокий для обхода экрана блокировки).
Другой класс атак обычно включает инструмент атаки представления (подделка), основанный на владельце устройства. Иногда эту биометрическую информацию относительно легко получить (например, если чьего-то изображения профиля в социальных сетях достаточно, чтобы обмануть биометрическую аутентификацию, тогда биометрический обход получит полный рейтинг серьезности). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.
SYSTEM_ALERT_WINDOW
and Tapjacking
For information about our policies regarding SYSTEM_ALERT_WINDOW
and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.
Multi-user security in Android Automotive OS
Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.
Affected component
The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.
Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.
The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.
Notifying partners
When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.
Releasing code to AOSP
If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.
Receiving Android updates
Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.
Updating Google services
In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.
Other resources
Information for Android app developers: https://developer.android.com
Security information exists throughout the Android Open Source and Developer sites. Good places to start:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Reports
Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.