Команда по безопасности 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, которые обеспечивают функциональность, критически важную для основных вариантов использования устройства (например, сотовые модули, цифровые сигнальные процессоры, графические процессоры и процессоры машинного обучения). |
| Цепочка загрузчика | Компонент, который настраивает устройство при загрузке, а затем передает управление ОС 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 ). Эти оценки серьезности различают два класса атак и призваны отражать реальный риск для конечного пользователя.
Первый класс атак позволяет обойти биометрическую аутентификацию обобщенным способом, без высококачественных биометрических данных владельца. Если, например, злоумышленник может поместить кусочек жвачки на датчик отпечатков пальцев, и это предоставит доступ к устройству на основе остатка, оставшегося на датчике, это простая атака, которая может быть выполнена на любом уязвимом устройстве. Она не требует никаких знаний о владельце устройства. Учитывая, что она обобщена и потенциально затрагивает большее количество пользователей, эта атака получает полную оценку серьезности (например, High для обхода экрана блокировки).
Другой класс атак обычно включает в себя инструмент атаки представления (подделка) на основе владельца устройства. Иногда эту биометрическую информацию относительно легко получить (например, если чьего-то фото профиля в социальных сетях достаточно, чтобы обмануть биометрическую аутентификацию, то биометрический обход получит полную оценку серьезности). Но если злоумышленнику потребуется получить биометрические данные непосредственно от владельца устройства (например, инфракрасное сканирование его лица), это достаточно существенный барьер, который ограничивает количество людей, затронутых атакой, поэтому есть модификатор -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 в наших внутренних репозиториях.
Компонент также является фактором, определяющим, как пользователи получают обновления. Ошибка в фреймворке или ядре требует обновления прошивки по воздуху (OTA), которое должен распространить каждый OEM-производитель. Ошибка в приложении или библиотеке, опубликованной в Google Play (например, Gmail, Google Play Services или WebView), может быть отправлена пользователям Android в виде обновления из Google Play.
Уведомить партнеров
Когда уязвимость безопасности в AOSP будет исправлена в бюллетене по безопасности Android, мы уведомим партнеров Android о деталях проблемы и предоставим исправления. Список поддерживаемых backport-версий меняется с каждым новым выпуском Android. Обратитесь к производителю вашего устройства, чтобы получить список поддерживаемых устройств.
Выпуск кода в AOSP
Если ошибка безопасности обнаружена в компоненте AOSP, исправление отправляется в AOSP после того, как OTA становится доступным для пользователей.
Получайте обновления Android
Обновления системы Android обычно поставляются на устройства через пакеты обновлений OTA. Эти обновления могут поступать от OEM-производителя, который выпустил устройство, или оператора, который предоставляет обслуживание устройству. Обновления устройств Google Pixel поступают от команды Google Pixel после прохождения процедуры технического приемочного тестирования (TA) оператора. Google также публикует заводские образы Pixel , которые можно загрузить на устройства.
Обновление служб Google
Помимо предоставления исправлений для ошибок безопасности, команда безопасности Android проверяет ошибки безопасности, чтобы определить, есть ли другие способы защиты пользователей. Например, Google Play сканирует все приложения и удаляет любое приложение, которое пытается использовать ошибку безопасности. Для приложений, установленных не из Google Play, устройства с Google Play Services также могут использовать функцию проверки приложений , чтобы предупреждать пользователей о приложениях, которые могут быть потенциально опасными.
Другие ресурсы
Информация для разработчиков приложений Android: https://developer.android.com
Информация о безопасности доступна на сайтах Android Open Source и Developer. Хорошие места для начала:
Отчеты
Иногда команда Android Security публикует отчеты или технические документы. Подробнее см. в разделе Security Reports .