Сегодня в выпуске: история нашумевшей уязвимости в смартфонах на базе процессоров MediaTek, подводные камни портирования Android на iPhone, история о том, почему функция скрытия root с помощью Magisk вскоре станет бесполезной. А также: инлайновые классы и принцип композиции в Kotlin, новый способ запуска активностей и запроса полномочий, несколько новых инструментов пентеста и библиотек для программистов.
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%.
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.
A first look at AndroidX Activity Result APIs — небольшая заметка о решении одной из самых раздражающих задач, возникающих при разработке приложений для Android.
Речь идет о функции startActivityForResult(), которая позволяет запустить активность другого приложения, чтобы переложить на нее решение определенной задачи: получение снимка с помощью камеры, выбор файла и так далее. Данный механизм серьезно облегчает жизнь разработчика, но реализован самым неудобным из возможных способов. Разработчику необходимо запустить активность, передав ей специальный код, а затем ждать результат в колбэке, реализованном с помощью переопределения метода onActivityResult() в активности или фрагменте. И все бы ничего, но точно таким же способом реализован запрос полномочий, так что код приложения в итоге расползается по множеству внешне никак не связанных между собой функций.
Существует масса способов решения этой проблемы с помощью сторонних библиотек, но эта статья рассказывает об официальном решении от Google. В альфа-версии библиотеки AndroidX Activity наконец появился удобный в использовании API, позволяющий работать с активностями других приложений, не размазывая код по активности своего приложения.
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее
1 год4990 р. |
1 месяц720 р. |
Я уже участник «Xakep.ru»
Читайте также
Последние новости
2009-2024 © Все права защищены.
This website - is fan-site, not an official Huawei website. The Huawei logo is a trademark of Huawei Technologies. Other trademarks are the property of their respective owners.
|