Секреты недокументированных возможностей — CVE-2020-10831 — подробности критической уязвимости в ядре

Вдохновение

Прочитав отличную статью Project Zero об эксплуатации уязвимости в прошивке Wifi-модуля для получения RCE, я решил, что мне стоит попробовать самостоятельно стоит сделать что-нибудь подобное.

Обзор от SoC

В наши дни смартфоны работающие под управлением Android имеют более 1 ядра, что делает их крайне сложными системами.

Более того, внутри большинства Android-смартфонов работают 10 до 30 различных «компьютеров», каждый со своим процессором, памятью и хранилищем.

Все эти устройства обмениваются данными по различным аппаратным протоколам связи, таким как IPC, I2C и так далее.

Основными процессорами в Android являются:

AP / Application processor - это главный CPU, о котором вы узнаете, когда читаете характеристики смартфона, он обменивается данными и управляет всеми другими процессорами.

BP / Baseband Processor / Radio / Modem - BP отвечает за преобразование всех сотовых сигналов, полученных из радиоволн, в информацию, используемую в программном обеспечении, путем реализации LTE стека.

GPU - графический процессор, отвечающий за обработку всех задач, связанных с графикой.

На деле, существует гораздо больше ядер цифровой обработки сигналов, таких как Wi-Fi, Crypto, Camera, Audio и т. д.

Все эти компоненты вместе называются «Система на кристалле» - SoC.

Поиск уязвимой цели

Эксплуатация уязвимостей в Android сложнее, поскольку у нас очень мало знаний об архитектуре прошивки и о том, как с ней взаимодействует ОС.

При поиске потенциальных зацепок, я обнаружил, что на нескольких форумах упоминали проблему сенсорного дисплея Samsung и некоторые способы ее решения. А решалась она относительно просто:

«Сначала перейдите к скрытым системным настройкам, набрав *#2663# в приложении телефона, а затем нажмите «Обновить прошивку».

Как дисплей связан с прошивкой

Запустив strace в Android-приложении, которое отвечает за обновление прошивки, вы увидите, что после нажатия кнопки обновления, приложение подгружает данные в следующую директорию:

“/sys/class/sec/tsp/cmd”

Этот путь является частью механизма ядра sysfs.

sysfs - это псевдофайловая система ядра Linux, экспортирующая информацию о присутствующих в системе устройствах и драйверах.

На скриншоте ниже вы можете увидеть, как общаться с ядром из cmd файла:

Ввод имени функции, например, «fw_update», а затем параметра «1» приведет к обновлению прошивки сенсорного экрана, в точности как в приложении заводских настроек. Но чтобы полностью понять механизм обновления прошивки, нам нужно загрузить ядро и посмотреть код драйвера устройства. После изучения исходного кода, обрабатывающего указанную выше команду, вот этот комментарий раскрыл очень интересные функции:

Похоже, что при написании:

“echo -n "firmware_update:0" > /sys/class/sec/tsp/cmd”

Параметр 0 сообщает ядру, из какого места обновлять прошивку. Как видно из комментария к коду ядра, передача 2 заставит ядро обновить прошивку из UMS (SDCARD). Дальнейший поиск в исходном коде покажет путь, по которому он ищет прошивку:

Эксплуатация

Чтобы проверить, можем ли мы прошить неподписанную / вредоносную прошивку, все, что нам нужно, это попробовать прошить такую прошивку и посмотреть, что же произойдет.

Команда:

Выдает следующий результат в логах ядра (kmsg):

На этом этапе я не был на 100 процентов уверен, что это сработает, но после попытки тапнуть на экран устройства и увидев массу ошибок ввода-вывода в kmsg (вместо того, чтобы просто увидеть результат нажатия), я понял, что просто успешно прошил поврежденную прошивку сенсорного экрана. Вуала!

Прочитать оригинал этого материала на английском можно здесь.

Cybred - канал об информационной безопасности и конкурентной разведке, вдохновленный идеями олдскульных андеграундных интернет-сообществ о свободе распространения информации в сети и всеобщей взаимопомощи.