Предотвращают ли канавари по возврату-в-libc и атакам с обратным ориентированием?

Я пытаюсь понять, можно ли использовать/использовать return-in-libc и использовать функции, ориентированные на возврат, при использовании канарейки. Канарская сторона будет помещена в стек между возвращаемым значением и буфером, который должен быть переполнен, и его необходимо будет перезаписать, чтобы изменить возвращаемое значение на местоположение библиотечной функции или вычисления. Канарские острова существуют с 1997 года (StackGuard), а ROP - это техника, впервые представленная в 2007 году (Shacham).

Неужели канарейка делает эти типы атак невозможными?

Ответ 1

Неужели канарейка делает эти типы атак невозможными?

Нет, это не так. Это затрудняет выполнение return-to-libc или ROP, но это определенно не является серебряной пулей против таких атак.

Прежде всего, стекальные канавари только защищают от обратного адреса, разбивающего через переполнение буфера. Но есть и другие способы испортить память: косвенный указатель переписать или format str для обозначения двух.

Во-вторых, стекальные канарейки можно обойти, перезаписав их исходным значением. Я не говорю, что это легко для современных реализаций, но это, конечно, не невозможно.

В-третьих, хотя атаки называются return-to-libc и Return Oriented Programming, кто говорит, что нам нужны инструкции возврата для выполнения этих атак? Эти атаки могут быть инициированы путем разложения любого места памяти, из которого процессор будет загружать и адресовать для перехода. Наиболее распространенным примером является указатель на функцию. Но мы могли бы также перезаписать буферы GOT или longjmp. (В качестве примечания было показано, что ROP можно выполнить без использования каких-либо команд возврата)

Четвертая причина - это не слабость стековых канарейков, а одна из большинства реализаций. Стекальные канарейки обычно помещаются только в функции с буфером символов на основе стека размером не менее 8. Таким образом, реализация не обнаруживает переполнения в других буферах. Этот эксплойт использовал переполнение в массиве с целым числом, поэтому он не мог быть обнаружен каналами стека.

Ответ 2

Вот веб-сайт, который объясняет канарейки, созданные с помощью gcc. http://xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/. Так как канарейка проверяется перед выполнением команды ret, ваш эксплоит будет терпеть неудачу, если вы перезапишете канарейку (что в большинстве случаев вам нужно сделать, чтобы переписать обратный адрес в стеке). Поскольку ROP и Return to Lib c также перезаписывают обратный адрес, оба метода не будут работать.