Отмычки: уязвимости в Android позволяют приложениям обходить проверку системы

Бизнес

Во второй половине июля среди пользователей Android возник небольшой переполох, связанный с двумя весьма серьёзными и неприятными уязвимостями. Исследователи, раскрывшие информацию о них, объявили, что речь идёт о т.н. Master Key, то есть некоем универсальном средстве доступа к любому устройству под управлением ОС Android, позволяющем потенциальным злоумышленникам вскрывать защиту и получать Root-полномочия, а следовательно, запускать произвольный код даже без ведома владельца устройства.

picklocks

У словосочетания Master Key, впрочем, есть два перевода — «ключ от всех дверей» и «отмычка». Судя по техническим описаниям, второе значение куда ближе к истине, чем первое. Две новые уязвимости позволяют модифицировать компоненты приложения в обход его криптографической сигнатуры, так что с точки зрения ОС Android такие программы будут вполне легитимными, даже если в них внедрены вредоносные модули.

Уязвимости похожи друг на друга по существу. В процессе анализа выяснилось, что возможности эксплуатации второй бреши ограничены определёнными условиями, которым должно отвечать приложение-мишень.

Первую уязвимость ещё в феврале обнаружила компания Bluebox Security. Первым делом о ней уведомили компанию Google, после чего последовал длительный период радиомолчания — разработчикам операционной системы необходимо было дать временную фору.

Уязвимость, как утверждает Bluebox, присутствует во всех версиях Android, начиная с 1.6, и потенциально затрагивает практически любое устройство, выпущенное в течение последних четырёх лет. Это примерно 900 млн. устройств. Масштаб катастрофический, однако на практике угроза может быть куда меньшей.

Прежде чем говорить о технической составляющей, необходимо дать несколько пояснений относительно того, что из себя представляет приложение для ОС Android.

Сами по себе приложения — это одиночные файлы с расширением APK (Android Package). По существу, это обычные ZIP-архивы, в которые запакованы все ресурсы в виде специально поименованных файлов (в частности, код самого приложения обычно хранится в файлах classes.dex).

По идее, любая попытка что-то поменять в содержимом APK-файла встретит отпор на этапе проверки, которую Android OS осуществляет при установке приложения. Увы, это только по идее: сам формат ZIP не исключает дублирующихся имён файлов, и Android в случае «дублирующихся» ресурсов, как выясняется, может успешно проверить один файл, а запустить другой.

Специалист по сетевой безопасности Джей Фриман (Saurik) приводит глубокий технический анализ имеющейся уязвимости и описывает возможности её эксплуатации и исправления; его статья доступна здесь. По его словам, главная проблема заключается в том, что система Android осуществляет парсинг и проверку APK-файлов: для проверки используется реализация ZipFile, написанная на Java, а для загрузки данных — другая реализация, написанная уже на C. Различия между ними и позволяют обходить процесс верификации: если поместить в общем стеке два файла с одинаковыми именами, то проверке подвергнется тот из них, что идёт в списке последним, а виртуальная машина Android DalvikVM запустит тот, что идёт первым.

Уязвимость #9695860

Информацию о второй уязвимости обнародовали китайские специалисты. Проблема здесь также заключается в одновременном использовании двух методов чтения (и разархивирования) APK-файлов и разной интерпретации кода Java и С.

Как и первая уязвимость, эта позволяет размещать в файлах APK исполняемые компоненты с идентичными именами, но разным содержимым. Если говорить конкретнее, то речь о «дублировании» файлов classes.dex, в которых содержится код самого приложения, с помощью эксплуатации одного из полей для метаданных в заголовке APK-файла.

Подробное техническое описание уязвимости доступно в статье Джея Фримана. Стоит отметить, что обязательным условием успешности атаки является длина оригинального файла classes.dex – он должен быть не длиннее 64 килобайт, а это условие для значительной части приложений под Android не выполняется.

В следующей части — о попытках злоумышленников воспользоваться описанными уязвимостями и о принятых контрмерах.

Продолжение следует.