Pull to refresh

Comments 24

Если ссылка на структуру памяти не передвигается, то это лишь маркетинговая фича.
Какая ссылка? Какая структура? Поясните, пожалуйста, что вы имеете ввиду?
рандомизацию виртуальных адресов памяти различных структур данных
На структуры памяти ссылается код. Передвинули структуру, но код по-прежнему ссылается на структуру иначе программа перестанет работать.
На таблице перемещаемых элементов когда-то сделал русификатор «вшитых строк» в код программы — OgreGUI, он подобным образом работал.
Для этого и нужна релокация, чтобы в случае «передвигания» программа работала нормально. Есть секция релоков — есть процесс релокации. Есть процесс релокации — есть ASLR. Есть ASLR — замучаетесь угадывать, что где лежит, при удаленной атаке.
Есть релокация или нет — не важно. На данные есть ссылка в коде.
Если раньше достаточно было обратиться по адресу структуры, то что мне мешает посмотреть ссылку на адрес структуры в каком-нибудь push?
Ничто, но это сложнее сделать при удаленных атаках. В этом суть ASLR. Вам нужна ДОПОЛНИТЕЛЬНАЯ уязвимость или дополнительное действие.
Я хоть и не занимался вопросом ASLR, но могу предположить, что можно легко линковать код, где вообще не будет абсолютных аддрессов. База + смещение вполне рабочая схема. Тем более для кода есть инструкции, которые используют также относительные аддресса (call, jmp, j*)
Верно, особенно это актуально для x64.
Одним из полезных улучшений в х64 стала адресация относительно RIP.
Умные компиляторы давно научились генерировать позиционно-независимый код. Short-jump переходит по относительному адресу, а данные в стеке хранятся. Это и для x32 верно.

Нужно только адреса библиотечных функций высчитать, для этого таблица импорта существует. Делов то. Очередной велосипед изобрели.
А про константные данные и jump tables вы забыли?
Придётся либо каждый раз доставать текущий адрес путём call/ret, либо тратить на него регистр (при групповом обращении), коих в х86 явный дефицит.
Ну компиляторы, наверное, так и делают. Производительность правда ни к чёрту выходит, зато безопасно.
Плюс ASLR, конечно, в возможности рандомизировать адреса в приложениях, изначально на это не расчитаных. Но вам не кажется, что какая то односторонняя безопасность получается? Что бы избавиться от всякой бяки нужен в первую очередь ответственный подход к разработки приложений. А сейчас мы имеем лишь всякие дырявые флеш-плееры.
Локальные переменные, в большинстве языков/коде, генерируемом большинством компиляторов хранятся в стеке, и аддрессуются относительно, обычно с помощью регистра ebp. Ничего не мешает аддрессовать переносимые секции подобным образом даже в x32 коде. Производительность также от этого страдать в целом не должна.
Текущая реализация ASLR в Windows 8 позволяет рандомизировать базовый адрес приложений, не поддерживающих рандомизацию.

По таблице ниже я этого не понял… не наглядно, либо я что-то пропустил или не так понял.
Про новый улучшенный генератор случайных чисел, не более… Для его описания потребовалось целых 5 абзацев.
Так, конечно, понятнее, спасибо.
UFO just landed and posted this here
Простите пожалуйста, но я никак не могу найти первый указанный Вами источник.
Речь идёт о каком-то докладе?
Гугл находит только интервью этих авторов, опубликованное в PC Magazine, но это не совсем то…
Первая ссылка в гугле на запрос «Windows 8 Heap Internals» — pdfка — доклад с BlackHat
Sign up to leave a comment.