Именно поэтому все существовавшие до открытия checkm8 джейлбрейки старались всячески обойти этот механизм. Ведь их первоочередная задача — загрузить видоизмененный образ iOS, допускающий установку программ из сторонних источников, чего не должно происходить с использованием SecureROM, стоящего на страже безопасной загрузки. Именно полный контроль над процессом запуска операционной системы гарантирует невозможность проникновения на устройство всевозможных буткитов, руткитов и прочей подобной малвари, отсутствием которой всегда и славилась мобильная платформа от Apple.
Как уже упоминалось, режим восстановления яблочного девайса DFU используется, если невозможна штатная загрузка айфона или айпада, и допускает обмен данными между компьютером и устройством через интерфейс USB. Для организации этого обмена в Apple придумали специальный протокол DFU. С его помощью можно залить на «окирпиченный» айфон новую прошивку, восстановить телефон из резервной копии или обновить операционную систему. Протокол DFU загружает с компьютера на яблочный девайс блоки данных с образом прошивки по запросу 0×21, 1. Когда загрузка полностью завершается, запрашивается состояние устройства, после чего соединение по USB разрывается, устройство выходит из режима DFU, перезапускается и пытается загрузить полученный образ прошивки. Это если процесс протекает в штатном режиме. Однако исследователи заметили, что выйти из DFU можно и другими способами, например по запросу 0×21, 4 (DFU abort). В этом случае выполняется форсированное завершение режима восстановления устройства.
При передаче данных протокол DFU использует режим, который носит наименование USB Control Transfer. Соединение инициализируется с использованием установочного пакета (Setup Stage) длиной 8 байт, структура которого показана на иллюстрации 24.
Рис. 24. Структура установочного пакета USB Control Transfer
Назначение всех полей этого пакета нам сейчас не принципиально — кроме самого последнего. Если значение wLength ненулевое, сразу за установочным пакетом следует стадия данных (Data Stage), то есть данные пойдут с компьютера на устройство или обратно (направление определяется значением bmRequest Type). Эти данные передаются последовательно фрагментами размером от 8 до 64 байт в зависимости от скорости USB-соединения. Сессия передачи данных завершается стадией проверки статуса транзакции (Status Stage), на которой стороны обмениваются пакетами нулевой длины.
В USB-стеке iBoot временный буфер выделяется в момент инициализации USB и пакеты, передаваемые в фазе данных, загружаются в него непосредственно «на входе». Важный момент состоит в том, что USB-стек включается сразу, как только устройство переходит в режим DFU Выделенный буфер используется для временного хранения информации на стадии данных. После передачи управления указатель на этот буфер (и размер ожидаемых данных) копируется в глобальную переменную, которую USB-стек использует как место назначения для пакетов, поступающих на устройство в фазе данных. Как только устройство выходит из режима DFU, USB-стек снова выключается. Однако глобальная переменная при этом не обнуляется! Таким образом исследователи нащупали классическую уязвимость типа Use-afer-Free (UaF).
В этом и кроется ошибка, лежащая в основе checkm8. Если отправить на устройство запрос Setup Stage, инициировать передачу данных, но, не начав эту самую передачу, отправить девайсу запрос DFU abort (0×21, 4) на форсированный выход из DFU, то устройство попытается снова запуститься в режиме DFU и завершить прерванную сессию. При этом состояние памяти останется инициализированным и мы получаем возможность передать на устройство, загрузить в память и выполнить произвольный код по адресу буфера, выделенного до момента предыдущего выхода устройства из DFU Поскольку вся программа, обеспечивающая выделение буфера, работу с кучей (heap) и структурами задач, хранится в SecureROM и исполняется на аппаратном уровне, исправить эту ошибку попросту невозможно. Шах и мат!
Примечательно, что на девайсах с 32-разрядным ROM (A7, A10, A10X, A11 и A11X) указанный механизм не работает, поскольку буфер там аллоцируется всякий раз в одном и том же месте при каждой инициализации USB-стека. Тем не менее, обнаруживший данную уязвимость хакер axi0mX нашел способ обойти такую предопределенность с использованием правильно подобранного сценария эксплуатации Use-afer-Free. Для этого он использовал то обстоятельство, что система одновременно может инициализировать несколько USB-передач. Например, в ответ на некоторые запросы устройство не сможет отправить данные, если получатель занят, до тех пор, пока конечная точка (endpoint) не освободится или не будет сброшен USB, то есть не будут устранены условия блокировки. Отправленные в таком состоянии запросы попадают в очередь. После устранения блокировки выполняется обход очереди и все запросы поочередно завершаются. Информация о конечной точке (endpoint) обнуляется, а запросы нулевой длины остаются в куче. Управляя запросами и тайм-аутами, теоретически можно создать такие условия формирования кучи, которые в итоге повлияют на следующее выделение памяти при создании буфера.
Читать дальше
Конец ознакомительного отрывка
Купить книгу