Команда безопасности Android отвечает за устранение уязвимостей безопасности, обнаруженных на платформе Android и во многих основных приложениях Android, поставляемых в комплекте с устройствами Android.
Команда безопасности Android находит уязвимости безопасности посредством внутренних исследований, а также реагирует на ошибки, о которых сообщают третьи стороны. Источники внешних ошибок включают проблемы, о которых сообщалось через форму уязвимости , опубликованные и предварительно опубликованные научные исследования, сопровождающие проектов с открытым исходным кодом, уведомления от наших партнеров-производителей устройств, а также публично раскрытые проблемы, опубликованные в блогах или социальных сетях.
Сообщить о проблемах безопасности
Любой разработчик, пользователь Android или исследователь безопасности может уведомить команду безопасности Android о потенциальных проблемах безопасности через форму уязвимости .
Ошибки, помеченные как проблемы безопасности, не видны извне, но в конечном итоге они могут стать видимыми после того, как проблема будет оценена или решена. Если вы планируете отправить исправление или тест пакета тестов совместимости (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 как проксимальные и, следовательно, удаленные.
Локальные атаки требуют, чтобы злоумышленник имел предварительный доступ к жертве. В гипотетическом примере, использующем только программное обеспечение, это может произойти через вредоносное приложение, установленное жертвой, или мгновенное приложение, на запуск которого она согласилась.
Успешно сопряженные устройства (например, сопутствующие устройства 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.
Многопользовательская безопасность в Android Automotive OS
Android Automotive OS использует многопользовательскую модель безопасности, отличную от других форм-факторов. Каждый пользователь Android предназначен для использования разными физическими лицами. Например, временный гостевой пользователь может быть назначен другу, который одалживает автомобиль у владельца автомобиля. Чтобы учесть подобные варианты использования, пользователи по умолчанию имеют доступ к необходимым компонентам, необходимым для использования автомобиля, таким как настройки Wi-Fi и сотовой сети.
Затронутый компонент
Команда разработчиков, ответственная за исправление ошибки, зависит от того, в каком компоненте она находится. Это может быть основной компонент платформы Android, драйвер ядра, предоставленный производителем оригинального оборудования (OEM), или одно из предустановленных приложений на устройствах Pixel.
Ошибки в коде AOSP исправляются командой разработчиков Android в наших внутренних репозиториях.
Компонент также является фактором, определяющим, как пользователи получают обновления. Ошибка в платформе или ядре требует обновления встроенного ПО по беспроводной сети (OTA), которое должен распространить каждый OEM-производитель. Ошибка в приложении или библиотеке, опубликованной в Google Play (например, Gmail, Google Play Services или WebView), может быть отправлена пользователям Android в виде обновления из Google Play.
Уведомить партнеров
Когда уязвимость безопасности в AOSP будет исправлена в бюллетене по безопасности Android, мы уведомим партнеров Android о подробностях проблемы и предоставим исправления. Список поддерживаемых версий меняется с каждой новой версией Android. Свяжитесь с производителем вашего устройства для получения списка поддерживаемых устройств.
Выпуск кода для AOSP
Если ошибка безопасности находится в компоненте AOSP, исправление передается в 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 с открытым исходным кодом и сайтах разработчиков. Хорошие места для начала:
Отчеты
Иногда команда безопасности Android публикует отчеты или технические документы. Дополнительные сведения см. в отчетах о безопасности .