Исправить её невозможно (в этом и состоит сама цель BootRom — быть принципиально неизменяемым, чтобы атакующий не сумел нарушить secure chain на старте).
Атака локальная, требует физический доступ.
Повторяю: т.к. уязвимость в процессоре — атаке подвержены все существующие iOS, включая любые будущие. Патч невозможен.
Единственный способ фикса — покупка нового телефона. Либо с A12 либо исправленными версиями предыдущих процессоров (если/когда они появятся).
Последствия:
— Jailbreak будет только со-шнурка (и до перезагрузки).
— Загружать можно любую версию ОС (исследователи ликуют!). Да, включая кастомизированный Андроид, который обязательно перенесут энтузиасты.
— Отвязать украденный девайс от iCloud, скорее всего, скоро сможет каждый подвал.
— Нужно ожидать мощного потока уязвимостей, которые исследователи "придерживали", чтобы не лишаться возможности ковырять новые девайсы/версии ОС. Теперь они станут не нужны.
Здравствуйте, vsb, Вы писали:
vsb>Ну и славно.
>> — Отвязать украденный девайс от iCloud, скорее всего, скоро сможет каждый подвал.
vsb>Пруф?
во-первых, это не точно "скорее всего"
во-вторых, "скоро" а не "уже отвязывает"
во-третьих, имея возможность загрузить что угодно до начала даже бутлоадера (т.е. доступно всё железо включая Trust Zone) — не вижу сложностей стереть любые данные с flash. Да, расшифровать ФС и вытащить данные предыдущего владельца скорее всего не получится. Но и фиг с ними, воров интересует железо.
Здравствуйте, IID, Вы писали:
>>> — Отвязать украденный девайс от iCloud, скорее всего, скоро сможет каждый подвал.
vsb>>Пруф?
IID>во-первых, это не точно "скорее всего" IID>во-вторых, "скоро" а не "уже отвязывает" IID>во-третьих, имея возможность загрузить что угодно до начала даже бутлоадера (т.е. доступно всё железо включая Trust Zone) — не вижу сложностей стереть любые данные с flash. Да, расшифровать ФС и вытащить данные предыдущего владельца скорее всего не получится. Но и фиг с ними, воров интересует железо.
Безопасный анклав они не взломали. Информация о привязке к айклауду скорей всего лежит там.
IID>Каких пруфов ты требуешь ?
How to, например. Вот есть у меня кирпич, куда тыкать по пунктам, чтобы получить на нём рабочую iOS, которая будет работать со всеми сервисами Apple.
Здравствуйте, vsb, Вы писали:
vsb>Безопасный анклав они не взломали. Информация о привязке к айклауду скорей всего лежит там.
Я не специалист в iOS.
Насколько я в курсе, Secure Enclave это аналог ARM TrustZone.
С той лишь разницей, что:
1) исполняется он на своём собственном ядре, а не на имеющихся (попытка заблокировать side channel attacks?).
2) но память использует всё равно общую с AP (application processor), только помеченную как secure (полный аналог с TZ).
3) имеет собственный BootRom, вместо загрузки через ABoot.
Первое и второе не имеет значения.
А вот третье это (возможно) даже плюс — из-за ограничений на размер (собственной RAM у SEP всего 4кб) там врядли реализовано что-то более стоящее, кроме механизмов проверки подписи.
Основная фирмварь грузится позже, когда подготовлены области памяти в TrustZone для работы SEPOS.
Стало быть врядли имеются запреты на downgrade. Можно подсунуть старую подписанную версию, и через неё выскочить в SEP.
IID>>Каких пруфов ты требуешь ?
vsb>How to, например. Вот есть у меня кирпич, куда тыкать по пунктам, чтобы получить на нём рабочую iOS, которая будет работать со всеми сервисами Apple.
Следи за развитием событий Пока что релизнули только сам эксплоит.
Для исследователей это уже сенсация.
Для юзеров энтузиасты прикрутят прикладные полезности, типа jailbreak/загрузки любой версии ОС.
Без стартовой уязвимости смысла в таком кабеле нет.
{а это значит что}
Уязвимоть была найдена давно, скорее всего разными людьми. И кабель делали далеко не один день — там и SDQ, и SWD, и всё это в FPGA засунуто.
Наверняка уязвимость была известна спецслужбам. И активно эксплуатировалась.
Как минимум в комментах к первоначальному посту отметился человек, сообщивший что нашёл эту уязвимость в марте.
В качестве доказательства выложил свой майский пост, с хешом. От текста, в котором объясняется суть уязвимости. Желание прославится жестоко боролось с жаждой наживы))))))
Эту "известность в узких кругах" нарушил @axi0mX своим эпическим постом. Движуха пошла. Запасайтесь попкроном!
Здравствуйте, IID, Вы писали:
vsb>>Безопасный анклав они не взломали. Информация о привязке к айклауду скорей всего лежит там.
IID>Я не специалист в iOS.
Хороший обзорный документ: https://www.apple.com/business/docs/site/iOS_Security_Guide.pdf
IID>Насколько я в курсе, Secure Enclave это аналог ARM TrustZone.
IID>С той лишь разницей, что: IID>1) исполняется он на своём собственном ядре, а не на имеющихся (попытка заблокировать side channel attacks?). IID>2) но память использует всё равно общую с AP (application processor), только помеченную как secure (полный аналог с TZ).
Не помеченную, а зашифрованную.
IID>3) имеет собственный BootRom, вместо загрузки через ABoot.
IID>Первое и второе не имеет значения. IID>А вот третье это (возможно) даже плюс — из-за ограничений на размер (собственной RAM у SEP всего 4кб) там врядли реализовано что-то более стоящее, кроме механизмов проверки подписи.
Он там иммутабельный. Так же, как и обычный boot rom.
IID>Основная фирмварь грузится позже, когда подготовлены области памяти в TrustZone для работы SEPOS.
IID>Стало быть врядли имеются запреты на downgrade. Можно подсунуть старую подписанную версию, и через неё выскочить в SEP.
> The Secure Enclave runs a Secure Enclave OS based on an Apple-customized version of the L4 microkernel. This Secure Enclave OS is signed by Apple, verified by the Secure Enclave Boot ROM, and updated through a personalized software update process.
Я это читаю как то, что подсунуть так просто не получится. Это как со старыми версиями iOS. Если ты в своё время сохранил специальный тикет, то да, можно его попытаться подсунуть. А так, просто взять любой девайс и сделать на нём downgrade не получится, т.к. Apple подписывает конкретную прошивку для конкретного устройства (и подписывает только последнюю версию, очевидно, а не какую ты захочешь).
IID>Для юзеров энтузиасты прикрутят прикладные полезности, типа jailbreak/загрузки любой версии ОС.
Вот это будет здорово. Бесит меня их свинство с запретом даунгрейда. Не обновился до последней версии iOS 12 несколько дней назад, а теперь вынужден сидеть на уязвимой, т.к. до 13 я обновляться не хочу, а до последней 12 не дают.
В обсуждаемом контексте это не важно, главное что собственной памяти у SEP по-сути нету.
IID>>А вот третье это (возможно) даже плюс — из-за ограничений на размер (собственной RAM у SEP всего 4кб) там врядли реализовано что-то более стоящее, кроме механизмов проверки подписи.
vsb>Он там иммутабельный. Так же, как и обычный boot rom.
Именно поэтому пропатчить его не смогут. А из-за аппаратных ограничений (размер самого ROM, размер RAM) врядли там есть downgrade lock.
>> The Secure Enclave runs a Secure Enclave OS based on an Apple-customized version of the L4 microkernel. This Secure Enclave OS is signed by Apple, verified by the Secure Enclave Boot ROM, and updated through a personalized software update process.
Всё верно.
И подсовывается этот образ в SEP извне.
vsb>Я это читаю как то, что подсунуть так просто не получится. Это как со старыми версиями iOS. Если ты в своё время сохранил специальный тикет, то да, можно его попытаться подсунуть.
Сомневаюсь что подобные проверки есть в SEP BootRom
vsb>А так, просто взять любой девайс и сделать на нём downgrade не получится, т.к. Apple подписывает конкретную прошивку для конкретного устройства (и подписывает только последнюю версию, очевидно, а не какую ты захочешь).
Это свинство полнейшее.
Пользователь должен иметь возможность апгрейда на любое число шагов из имеющихся.
Впрочем насильный переход на x64 был у Эпла ещё большим свинством. И ничего, проглотили.
IID>Найдена уязвимость в BootRom процессоров A5-A11. IID>Эти процессоры покрывают всю линейку, от iPhone5 до iPhone X.
подробности
(обратите внимание на дату, баг был известен уже давно)
This bug was also called moonshine in the beginning
Basically the following bug is present in all bootroms I have looked at:
1. When usb is started to get an image over dfu, dfu registers an interface to handle all the commands and allocates a buffer for input and output
2. if you send data to dfu the setup packet is handled by the main code which then calls out to the interface code
3. the interface code verifies that wLength is shorter than the input output buffer length and if that's the case it updates a pointer passed as an argument with a pointer to the input output buffer
4. it then returns wLength which is the length it wants to recieve into the buffer
5. the usb main code then updates a global var with the length and gets ready to recieve the data packages
6. if a data package is recieved it gets written to the input output buffer via the pointer which was passed as an argument and another global variable is used to keep track of how many bytes were recieved already
7. if all the data was recieved the dfu specific code is called again and that then goes on to copy the contents of the input output buffer to the memory location from where the image is later booted
8. after that the usb code resets all variables and goes on to handel new packages
9. if dfu exits the input output buffer is freed and if parsing of the image fails bootrom reenters dfu
Exiting dfu can either be done by sending a dfu abort package or by triggering parsing with a usb reset
The problem:
At step 5 the global variables are updated and the bootrom gets ready to recieve the data, but with a cheap controller you can violate the usb spec and don't send any (arduino host controller or sth like that).
Then you can trigger a usb reset to trigger image parsing. If that parsing fails bootrom will enter dfu once again, BUT step 8 wasn't executed so the global variables still contain all the values.
However step 9 was executed so the input output buffer is freed while the pointer which was passed as an argument in step 3 still points to it.
Because of that you can easily trigger a write to an already freed buffer by sending data to the device.
Exploitation on A8:
1. Send 0x40 of random data to dfu, this has to be sent otherwise you can't exit dfu using usb reset ctrlReq(bmRequestType = 0x21,bRequest = 1,wLength = 0x40)
2. get dfu in the state where it's waiting for a usb reset by sending ctrlReq(0x21,1,0) ctrlReq(0xa1,3,1) ctrlReq(0xa1,3,1) ctrlReq(0xa1,3,1) (see ipwndfu dfu.py)
3. only sent a setup packet with bmRequestType 0x21 and bRequest 1 and a wLength of your payload size (this one will update the global variables)
4. send a status packet to mark the end of the controll transfer (we skipped the data phase even tho we set wLength to a value)
5. trigger bus reset
6. wait for the device to reenter dfu (now the input output buffer will be freed and the usb task will be allocated under the freed buffer)
7. send a set configuration request ctrlReq(bmREQ_SET,USB_REQUEST_SET_CONFIGURATION,wLength=Payloadsize) but send the payload with it as data phase (set configuration handler in bootrom ignores wLength)
The payload will overwrite the usb task struct and the next allocation after it will be the usb stack. By targeting the linked list in the usb task struct you can insert a fake task.
And you can use the usb task stack as scratch space as it seems like it will never end up writing to it that high.
That one will be spawned when dfu exits and the usb task gets stopped. So you can send a dfu abort packet after step 7 and with that get code exec with all higher registers controlled because your fake task gets added to the list and runs at some point later on.
~ 31.05.19 lailo
kalsarikännit
Re[2]: Вот уже и DebugCable выбросили в продажу...
Здравствуйте, mike_rs, Вы писали:
_>выводы доводим до логического конца: "а значит это не уязвимость, а бекдор для спецслужб,
Не исключено. С несколькими оговорками:
А) Этот "бекдор" не даёт доступа к данным пользователя.
Единственный рабочий вариант: evilmaid завладевает устройством и делает dualboot. Далее пользователь, не замечая помены, авторизуется.
Т.е. необходимо соблюдение двух условий: 1) физический доступ к устройству 2) последующая авторизация пользователем
B) У Apple есть возможность сделать более удобные бекдоры
C) Баг был исправлен в 2018 году
_>данные о котором просто утекли"
Тут самое смешное. Данные никуда не утекали.
А баг был "вычислен" как раз по его фиксу. Точнее по фиксу совсем в другом месте, но с общей кодовой базой.
От фикса до первого известного обнаружения прошел почти год.
От фикса до публичного раскрытия больше года.
During iOS 12 betas in summer 2018, Apple patched a critical use-after-free vulnerability in iBoot USB code. This vulnerability can only be triggered over USB and requires physical access. It cannot be exploited remotely. I am sure many researchers have seen that patch.
