Comments 11
Великолепно! Изложено крайне понятно и было интересно узнать как развивалась защита. Когда прочёл заголовок на ум сразу пришел упомянутый эксплоит iMessage
Редкий образец статьи, ясно и разборчиво объясняющей свой предмет. Благодарю автора.
Про ASLR - брехня (только если файл слинкован в поддержкой ASLR а это отнюдь не у всех) и не описано KASLR, DEP, SafeSEH, CFI, VBS, HVCI и еще кучу "защитных" примочек, которые чисто пиар и легко обходятся. Переполнение буфера - это уровень детского сада, давно уже в школе используют ROP-гаджеты, а в институте давно применяют BROP - DOP, а в академии...
Да все так, вы абсолютно правы, приложение должно быть даже не слинковано, а скомпилировано с -fPIE (у вас в Windows это /DYNAMICBASE у линкера), что бы его рантайм-линкер мог загрузить по любому адресу.
Статья задумывалась научно-популярной, пересказ же сотни аббревиатур кого угодно загонит в сон.
К тому же по многим из них, если углубляться в детали, можно по отдельной статье написать. Те же нюансы реализации ASLR: что библиотеки друг относительно друга не рандомизируются, а только общая база, что в Windows библиотеки рандомизируются один раз при загрузке lol, что fork() на корню убивает смысл ASLR (привет Android), а так же что рандомизировать можно не только библиотеки, но и объектники/функции, да и структуры. Ну и Kernel ASLR просто беспомощен для любого сайдченела.
Теперь к printf. У неё есть малоизвестный спецификатор
%n. Все остальные —%d,%sи прочие — читают данные из аргументов и выводят на экран.%nделает обратное: берёт адрес из аргумента и записывает туда число символов, которые printf уже вывела к этому моменту. Да, функция вывода текста умеет писать в произвольную память.
"Век живи, век учись, - подумал поручик и переложил серебрянный портсигар из кармана штанов в нагрудный карман." (с) ...
Мысль вслух. Интерпретатор всем известных TrueType шрифтов (TTF) является forth-подобной виртуальной машиной. Что если использовать её как "weird machine" ? Жертве остается только открыть PDF со вложенным "шрифтом".
На начальном этапе взлома на устройство жертвы через iMessage поступало сообщение с вредоносными данными, эксплуатирующими уязвимость CVE-2023-41990 в реализации Apple обработки шрифтов TrueType. Данная уязвимость позволяла удалённо выполнять код с минимальными привилегиями и переходить к следующему этапу, целью которого был доступ к ядру iOS.
Опять я опоздал с идеей. :-)
Умные товарищи уже ответили, спасибо им, я только добавлю пять копеек, что через TTF взламывают уже очень давно именно из-за его встроенного интерпретатора. Кажется в 2015 был баг, которым вначале взламывали браузер подгружаемым шрифтом, а потом из песочницы браузера, тем же самым багом выполняли код в ядре, ибо в то время win32k.sys обрабатывал графику и рендерил шрифты из ядра.
Это просто очень удобно для атакующих, им не нужно weird machine изобретать, у них сразу есть интерпретатор. JavaScript ломают бесконечно, по той же самой причине.
Ну а вместо 1000 слов про TTF, на нем запустили Doom:
https://github.com/4RH1T3CT0R7/ttf-doom
https://4rh1t3ct0r7.github.io/ttf-doom/
спасибо за статью. глоток свежего воздуха. прочитал с удовольствием.
Странные машины: как хакеры собирают процессор из данных