Android: уязвимость в смартфонах на процессорах MediaTek и Android для iPhone - «Новости»

Почитать

История уязвимости устройств на процессорах MediaTek

Critical MediaTek rootkit affecting millions of Android devices has been out in the open for months — история обнаружения и попыток залатать критический баг в устройствах на базе китайских процессоров MediaTek.

Краткая предыстория: в начале марта по всем сколько-нибудь связанным с безопасностью и мобильными устройствами сайтам прокатилась новость о весьма опасной уязвимости, выявленной буквально во всех устройствах, использующих 64-битные процессоры MediaTek. Мало того что уязвимость позволяла получить права root и отключить SELinux (одну из базовых систем безопасности Android), она еще и была очень проста в эксплуатации (один незатейливый эксплоит, не требующий особых условий для успешного взлома).

Широкая общественность узнала об уязвимости благодаря мартовскому патчу безопасности Android, в котором она получила пометку критической. Однако история обнаружения уязвимости начинается вовсе не с патча, а с поста пользователя diplomatic на форуме XDA Developers. Пост был посвящен планшету Amazon Fire.

Еще год назад diplomatic обнаружил, что драйвер CMDQ в ядре Linux для процессоров MediaTek принимает ioctl-команды от кого угодно. С помощью этих команд можно получить доступ к DMA-буферу, модифицировать память ядра и отключить SELinux. Позже diplomatic и другие пользователи форума выяснили, что эксплоит работает почти на всех устройствах с 64-битным процессором MediaTek за исключением устройств Vivо, OPPO, Huawei и Samsung с Android 8 и выше, на которых есть защита от получения прав root с помощью эксплоитов.

Компания MediaTek пропатчила драйвер еще в мае 2019 года, но это не просто не решило проблемы. Дело в том, что MediaTek производит процессоры низкого ценового диапазона, и их устанавливают в бюджетники, поддержка которых нередко заканчивается в момент выпуска смартфона с конвейера. Это те самые Blackview, Elefone и прочий китайский ширпотреб. Теперь все это — переносной бэкдор, беззащитный перед простейшей малварью, установленной из варезников (а такая уже существует — обнаруженный Trend Micro троян использует уязвимость MediaTek наряду с уязвимостью CVE-2019-2215 для получения контроля над устройством).

Именно по этой причине патч для MediaTek в итоге попал в состав официального патча безопасности Android. Это дает шанс, что хотя бы крупные производители обновят свои устройства, чтобы не нарушать договор о двухгодичной поддержке устройств. С другой стороны, доля пропатченных устройств вряд ли поднимется выше 1%.

История портирования Android на iPhone

An adventure 13 years in the making — история проекта Sandcastle, в рамках которого разработчики из компании Corellium сумели портировать Android на iPhone.

Сама возможность портирования появилась благодаря эксплоиту checkm8, который использует уязвимость в загрузчике iPhone и позволяет не просто выполнить Jailbreak, а получить полный контроль над устройством, включая возможность установки и загрузки альтернативных операционных систем.

Но интересно даже не это, а то, с какими сложностями столкнулись разработчики. В первую очередь это кастомный процессор Apple, который вроде бы совместим со стандартным ARM, но имеет массу мелких отличий: «почти» совместимый с Samsung UART-контроллер, «почти» совместимый с Samsung SPI-контроллер, нестандартный контроллер прерываний, собственный способ включения дополнительных ядер процессора и так далее.

Еще более интересная история произошла с портированием платформы Android поверх уже портированного ядра Linux. Оказалось, что Android в принципе не поддерживает работу со страницами памяти с отличным от 4 Кбайт размером (Apple использует 16 Кбайт). Также Android оказался не совсем 64-разрядной системой: во многих местах ее до сих пор можно найти 32-битный код, который просто не будет работать на полностью 64-битном процессоре Apple.

Парадоксально, но порт Android для iPhone стал первой полностью 64-битной сборкой Android в истории.

Факт разлочки загрузчика больше не скрыть

Magisk may no longer be able to hide bootloader unlocking from apps — статья о том, как Google обыграла разработчика Magisk и сделала скрытие факта разлочки загрузчика невозможным.

Сегодня Magisk — это единственный надежный способ получить root на стоковой прошивке Android. Magisk стал популярен и выжил в войне против Google благодаря использованию метода рутинга, не требующего модификации системного раздела, и возможности скрыть наличие прав root от определенных приложений (например, банковских клиентов, платежных систем и онлайн-игр).

Чтобы скрыть root, Magisk использует несколько трюков, которые обманывают приложение и систему SafetyNet, предназначенную для проверки смартфона на безопасность. Долгое время SafetyNet использовала эвристические методы для определения root и разблокировки загрузчика (которая требуется для установки Magisk).

Однако пользователи начали замечать, что некоторые смартфоны больше не проходят проверку SafetyNet с установленным Magisk. Разработчик Magisk ответил, что иногда SafetyNet больше не полагается на простую проверку состояния загрузчика (которую умеет обманывать Magisk), а вместо этого использует приватный ключ шифрования из защищенного хранилища Keystore, чтобы подтвердить достоверность переданных данных.

Обойти эту защиту можно, лишь получив доступ к приватному ключу, который хранится в выделенном криптографическом сопроцессоре (TEE), а сделать очень проблематично (Google платит от 250 тысяч до 1 миллиона долларов за подобную уязвимость).

Все это означает, что совсем скоро все сертифицированные Google устройства на базе Android 8 и выше просто перестанут проходить проверку SafetyNet и Magisk будет бесполезен, если установлены банковские клиенты и другие приложения, использующие SafetyNet.

Разработчику

StartActivityForResult в 2020 году

A first look at AndroidX Activity Result APIs — небольшая заметка о решении одной из самых раздражающих задач, возникающих при разработке приложений для Android.

Речь идет о функции startActivityForResult(), которая позволяет запустить активность РґСЂСѓРіРѕРіРѕ приложения, чтобы переложить РЅР° нее решение определенной задачи: получение СЃРЅРёРјРєР° СЃ помощью камеры, выбор файла Рё так далее. Данный механизм серьезно облегчает жизнь разработчика, РЅРѕ реализован самым неудобным РёР· возможных СЃРїРѕСЃРѕР±РѕРІ. Разработчику необходимо запустить активность, передав ей специальный РєРѕРґ, Р° затем ждать результат РІ колбэке, реализованном СЃ помощью переопределения метода onActivityResult() в активности или фрагменте. И все бы ничего, но точно таким же способом реализован запрос полномочий, так что код приложения в итоге расползается по множеству внешне никак не связанных между собой функций.

Существует масса способов решения этой проблемы с помощью сторонних библиотек, но эта статья рассказывает об официальном решении от Google. В альфа-версии библиотеки AndroidX Activity наконец появился удобный в использовании API, позволяющий работать с активностями других приложений, не размазывая код по активности своего приложения.