Shadow Stack препятствует работе не только вирусов, но и патчей безопасности


Shadow Stack препятствует работе не только вирусов, но и патчей безопасности

Сегодня в «Компьютерном обозрении» появилась статья с анализом ини­ци­а­тив Intel, направленных на повышение защищенности программного кода информационных систем и пользовательской информации. Эти ини­ци­а­ти­вы разрабатываются в компании уже не один год и сводятся к ряду ап­па­рат­ных трюков для защиты межпрограммных связей от не­санк­ци­о­ни­ро­ван­но­го влияния. Одно из нововведений касается стека, в котором хранятся адреса возврата, сформированные при вызове подпрограмм. Для того, чтобы ви­рус не перехватил управление, программный data stack дублируется в теневую копию (shadow stack), аппаратно за­щи­щен­ную специальным статусом. Теперь процессор сможет проконтролировать вызов любой подпрограммы , срав­ни­вая ад­реса возврата, хранящиеся в обоих стеках. Если они не совпадают — можно объявлять тревогу.

Выяснилось, что shadow stack препятствует работе не только вирусов, но и заплаток, обеспечивающих без­опас­ность. Нельзя сказать, что это стало неожиданностью. На сей счет есть вполне очевидный прогноз в статье «Двой­ная осевая против уязвимости»:

Все бы хорошо, но полицейские меры коснутся и законопослушных программистов, которые для перехода по за­дан­но­му адресу, помещают этот адрес в стек, а затем осуществляют передачу управления по инструкции возврата RET.

Сложилось так, что эти меры коснулись даже тех законопослушных программистов, которые являются авторами патчей для устранения уязвимости. Следуя в фарватере интеловских инициатив они планировали заменить опе­ра­то­ры косвенного перехода JMP <address> на пары инструкций PUSH-RET, используя методику известную под наз­ва­ни­ем ROP — return-oriented programming, как опе­ративный выбор меньшего из двух зол.

Концепция аппаратного стека (shadow stack), предложенная компанией Intel, перекрывает возможность такого ком­промисса.

Концепция аппаратного стека (shadow stack), предложенная компанией Intel, перекрывает возможность  ROP — return-oriented programming

The problem I see with this concept is ROP mitigations like Intel’s control flow enforcement don’t seem compatible with in­ten­tionally using tweaked addresses with ret. The address they inject won’t match the shadow stack and the program will be ter­minated.

Резюме

В рассматриваемой ситуации shadow stack стал препятствием для сомнительного компромисса. Есть основания считать, что за­ме­на косвенного перехода на последовательность PUSH-RET, решит вопрос только частично — список про­цес­со­ров, подверженных уязвимостям, основанным на спекулятивном выполнении, сократится, но не обязательно до нуля. В качестве примера можно привести замену инструкции пе­ре­хо­да по адресу, на­хо­дя­ще­му­ся в регистре jmp rax, на последовательность инструкций

push rax
ret

Это связано с тем, что инструкция RET, передающая управление по адресу, прочитанному из стека, также является косвенной формой передачи управления. Распространенный тезис о том, что такая операция возврата из про­це­ду­ры гарантирует барьер для опережающего выполнения, в действительности носит implementation-specific ха­рак­тер. В итоге, проблема ROP-решения — в отсутствии строгой доказанности, а не только в конфликте с shadow stack.

Теги: