Если я правильно понимаю, при переполнении буфера слишком длинные данные затирают в стеке адреса возврата. Это позволяет подставить и выполнить свой код.
Но почему-бы не разделить стек? Сделать отдельный стек для данных и отдельный стек для адресов возврата.
Простейший способ — организовать где-то в памяти стек и использовать его для хранения локальных переменных и параметров процедур. А адрес возврата хранить в "обычном" стеке.
Это же вроде компилятор решает, где и как хранить данные? Есть такая настройка?
Здравствуйте, wildwind, Вы писали:
W>Это будет уже другая архитектура процессора.
Не, в процессор зашито использование стека только для адреса возврата. Я как раз и предлагаю оставить адрес возврата в обычном стеке (которой SS:SP).
А вот за то, что туда складываются локальные переменные и параметры процедур, отвечает компилятор. В самом процессоре это не регламентировано (x86).
Здравствуйте, Буравчик, Вы писали:
Б>Не, в процессор зашито использование стека только для адреса возврата. Я как раз и предлагаю оставить адрес возврата в обычном стеке (которой SS:SP). Б>А вот за то, что туда складываются локальные переменные и параметры процедур, отвечает компилятор. В самом процессоре это не регламентировано (x86).
Или вообще можно менять SP перед и после каждым CALL/RET. Тогда можно использовать обычные PUSH/POP для данных, а не работать с памятью и кэшем, которые медленные.
Я понимаю, что это все будет чуть медленнее, чем сейчас. Но ведь это позволит убрать наиболее частую и наиболее критичную уязвимость — переполнение буфера.
По крайней мере, для определенных программ это может быть полезно, даже в ущерб скорости. Да и потеря в скорости может быть совсем крошечной.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, wildwind, Вы писали:
W>>Это будет уже другая архитектура процессора.
Б>Не, в процессор зашито использование стека только для адреса возврата. Я как раз и предлагаю оставить адрес возврата в обычном стеке (которой SS:SP). Б>А вот за то, что туда складываются локальные переменные и параметры процедур, отвечает компилятор. В самом процессоре это не регламентировано (x86).
тогда где-то (в куче?) придется выделять память для локальных переменых, это все будет жутко тормозить. А так — ну бекэнд сделай свой к llvm какому-нить, и генерируй другой asm код.
Здравствуйте, mike_rs, Вы писали:
_>тогда где-то (в куче?) придется выделять память для локальных переменых, это все будет жутко тормозить. А так — ну бекэнд сделай свой к llvm какому-нить, и генерируй другой asm код.
Cтек тоже находится в той же обычной памяти, рядом с кучей. Тормозить будет только переключение стеков "инструкции/данные", но не сами стеки.
Меня интересует, почему так еще не сделали, какие есть проблемы. Скорее всего, я чего-то не знаю или не понимаю.
P.S. На asm писать я почти не умею, сделать что-то для llvm не смогу.
Здравствуйте, Буравчик, Вы писали:
Б>Простейший способ — организовать где-то в памяти стек и использовать его для хранения локальных переменных и параметров процедур. А адрес возврата хранить в "обычном" стеке. Б>Это же вроде компилятор решает, где и как хранить данные? Есть такая настройка?
Например, что-то типа такого должно быть:
Сейчас:
PUSH param1
PUSH param2
CALL func
...
func:
POP ax ;param2
POP bx ;param1
MOV ax, result
RET
С разделением стеков:
Каждый раз, когда программа работает с данными, она переключается на свой стек данных.
При выполнении инструкций CALL/RET переключаемся на стек инструкций.
MOV SP, data_stack
PUSH param1
PUSH param2
MOV data_stack, SPMOV SP, instruction_stack
CALL func
...
func:
MOV instruction_stack, SPMOV SP, data_stack
POP ax ;param2
POP bx ;param1
MOV ax, result
MOV data_stack, SPMOV SP, instruction_stack
RET
Оверхэд — из-за MOV SP, ... т.к. адреса стеков хранятся в памяти. Но:
1. Этот участок памяти с очень большой вероятностью будет в L1 кэше
2. Можно хранить указатели в регистрах, например SP и CX. Менять их CHG sp, cx (или как там в asm)
3. Можно менять значения SP, сохраняя предыдущее значение в стеке инструкций (главное, чтобы не в стеке данных, т.к. стек данных уязвим, а стек инструкций нет).
Дополнение:
Посмотрел, есть XCHG reg, mem
т.е. можно делать XCHG SP, ячейка_для_хранения_неиспользуемого_SP, достаточно одной ячейки памяти и одной команды для переключения стека.
Ну и в идеале вместо ячейка_для_хранения_неиспользуемого_SP использовать регистр. Чтоб совсем быстро.
Здравствуйте, Буравчик, Вы писали:
Б>Если я правильно понимаю, при переполнении буфера слишком длинные данные затирают в стеке адреса возврата. Это позволяет подставить и выполнить свой код.
Это самый простой вариант. Но затирание других данных тоже используется в эксплойтах.
А с приходом address space layout randomization (ASLR) ценность такого метода снизилась практически до нуля, разве что вышибешь процесс.
Б>Но почему-бы не разделить стек? Сделать отдельный стек для данных и отдельный стек для адресов возврата.
Есть архитектуры, где так сделано (IA64), есть программные реализации (такое требуется для Forth).
IA64 практически умер. Forth не используется кроме спецслучаев (загрузчики и т.п.) на процессорах с OoO и кэшированием.
Ссылок не найду, но практика показала, что получается только частичная защита от проблем.
Методы ограничения через явные проверки работают эффективнее, особенно если встроены в язык.
Здравствуйте, Буравчик, Вы писали:
Б>Дополнение: Б>Посмотрел, есть XCHG reg, mem Б>т.е. можно делать XCHG SP, ячейка_для_хранения_неиспользуемого_SP, достаточно одной ячейки памяти и одной команды для переключения стека. Б>Ну и в идеале вместо ячейка_для_хранения_неиспользуемого_SP использовать регистр. Чтоб совсем быстро.
XCHG плохо, потому что Intel давно его испортил:
If a memory operand is referenced, the processor’s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. (See the LOCK prefix description in this chapter for more information on the locking protocol.)
Но любой другой регистр (особенно в x86-64) вполне может справиться.
Здравствуйте, Буравчик, Вы писали:
Б>Если я правильно понимаю, при переполнении буфера слишком длинные данные затирают в стеке адреса возврата. Это позволяет подставить и выполнить свой код. Б>Но почему-бы не разделить стек? Сделать отдельный стек для данных и отдельный стек для адресов возврата.
Во-первых, это сразу же добавит геморроя по поддержке стеков. Не только уже озвученное переключение, но и то, что каждый стек должен быть непрерывен в виртуальном АП. Его нельзя расширять произвольно, добавлением любых свободных страниц — АП под каждый стек нужно резервировать заранее, и при его исчерпании наступает полный писец. Сейчас и так каждый поток имеет собственные стеки как режима пользователя, так и режима ядра, а пришлось бы все это удвоить.
Во-вторых, такое решение исключит лишь часть возможных атак, но не все. По-прежнему можно будет, организовав переполнение, так поменять данные потока, чтобы он сработал в угоду атакующему. Будет сложнее добиться нужного поведения, но это останется возможным.
Здравствуйте, Буравчик, Вы писали:
Б>Или вообще можно менять SP перед и после каждым CALL/RET. Тогда можно использовать обычные PUSH/POP для данных, а не работать с памятью и кэшем, которые медленные.
Почему медленные? Стек это ровно та же память. Не думаю, что PUSH будет существенно отличаться от "ручного" PUSH через любой другой регистр.
Здравствуйте, Буравчик, Вы писали:
Б>Меня интересует, почему так еще не сделали, какие есть проблемы. Скорее всего, я чего-то не знаю или не понимаю.
Это не решит проблему радикально. Если переполнив буфер, можно попасть в соседнюю область памяти, то совершенно не обязательно целиться именно в адрес возврата. В памяти есть много других мест, куда можно с успехом прицелиться.
Радикально решает проблему вставляемая компилятором явная проверка переполнения буфера при каждом обращении. Всякие там managed языки (Go, Java, C# и т.д.) делают это по умолчанию, некоторые (все?) компиляторы Си тоже так умеют. Но это снижает скорость раза в два.
что такое data_stack? если глобальная переменная, то эту функцию нельзя использовать многопоточно, что чревато. Если нет, то как предполагается разруливать многопоточность?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>каждый стек должен быть непрерывен в виртуальном АП. Его нельзя расширять произвольно, добавлением любых свободных страниц
Кому должен? Почему нельзя расширять? :)
Это не необходимое требование.
Например, в компиляторах clang или gcc уже лет десять доступна опция split-stack. С ней компилятор генерирует код, который не использует непрерывный стек. Сделано это как-раз для того, чтобы не выжирать всю виртуальную память, например если нужно на x86 в одном процессе запустить десяток тысяч потоков.
То есть, если интересно посмотреть как программы могут работать без непрерывного стека, то далеко ходить не надо — это уже давно реализовано. Востребованность этого, конечно, другой вопрос :)
Здравствуйте, netch80, Вы писали:
N>А с приходом address space layout randomization (ASLR) ценность такого метода снизилась практически до нуля, разве что вышибешь процесс.
Снизилась только потому, что теперь надо 2 эксплоита вместо 1.
Сначала ID, потом уже RCE.
Здравствуйте, watchmaker, Вы писали:
W>Например, в компиляторах clang или gcc уже лет десять доступна опция split-stack. С ней компилятор генерирует код, который не использует непрерывный стек.
А как при этом обеспечивается раскрутка стека средствами ОС в случае исключения? Или эта опция используется только в ОС, не поддерживающих раскрутку стека собственными средствами?
Здравствуйте, Буравчик, Вы писали:
Б>Если я правильно понимаю, при переполнении буфера слишком длинные данные затирают в стеке адреса возврата.
Против этого работают стековые канарейки/печеньки.
(Конечно, бывают исключительные случаи, типа тщательно подобранного зацикливания в рекурсии, чтобы перепрыгивать через них).
Б>Это позволяет подставить и выполнить свой код.
А твой код откуда возьмётся в атакуемом процессе ? Времена исполнения данных давно прошли, сейчас везде NX бит.
Для защиты от ROP/JOP придумали CFI (Control Flow Integrity).
Б>Но почему-бы не разделить стек? Сделать отдельный стек для данных и отдельный стек для адресов возврата.
Потому что tampered данные не менее опасны, чем адреса возврата.
Будет у тебя лежать в стеке структура с коллбеком. Или указатель на структуру с коллбеком. Ну ты понЕл...
Интел пару лет назад что-то рассказывал про двойной стек. Только в другом ключе — при возвратах проверяется теневой стек, что в него действительно заносился адрес и заносился с помощью команды CALL.
Вроде обещали сделать аппаратную реализацию.
Ещё можешь про технологию Pointer Authentication почитать. Она делает подобные атаки бесполезными.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Буравчик, Вы писали:
Б>>Или вообще можно менять SP перед и после каждым CALL/RET. Тогда можно использовать обычные PUSH/POP для данных, а не работать с памятью и кэшем, которые медленные.
vsb>Почему медленные? Стек это ровно та же память. Не думаю, что PUSH будет существенно отличаться от "ручного" PUSH через любой другой регистр.
Одна операция PUSH/POP это на самом деле две операции — запись в память и изменение регистра SP.
Нам придется явно выполнять две операции вместо одной. Плюс если SP является не регистром а ячейкой памяти, то еще добавится тормозов.
