Comments 15
AWS Graviton, получается, ненадежный...
Это требуется для защиты системы от атак с подменой указателей адресов памяти, которые контролируются значениями PAC.
Было бы интересно услышать подробности про этот механизм. Что за атаки с подменой адресов памяти, от которых он защищает, зачем аутентифицировать указатели. В отличии от страничной адресации это что-то новое.
Как я понял, это для защиты от переполнения стека и особенно выхода за границы буфера на стеке. То есть программно вполне фиксится по мере обнаружения соответствующих уязвимостей в конкретном ПО. Просто не будет универсального решения. У многих архитектур этого механизма вообще нет.
The attacks utilize existing and legitimate code fragments called gadgets. In a successful exploit the attacker gains control over the call stack, for example via stack smashing, and then the pointers stored on the stack are overwritten to point to selected gagadgets.В
Не каждый софт подвержен stack smashing. Только выделяющий буферы неограниченной длины на стеке, использующий рекурсивные алгоритмы без ограничения глубины рекурсии и т. д. Это всё в идеале не должно быть в надёжном софте и может быть исправлено по мере обнаружения. По такому определению скомпрометированный механизм выступает лишь в роли дополнительного слоя защиты, поскольку в программах иногда встречаются баги. Беда, но не катастрофа. Либо я что-то упускаю...
Многие баги, связанные с ручным управлением памяти, могут приводить к ROP атакам. Double free, например. Аутентификация указателей призвана быть барьером дополнительным. Баги есть и будут, их невозможно избежать в небезопасных языках, как мы это видим на практике. Кардинальное решение это сменить язык. Временное решение - огородить код вокруг, чтобы минимизировать ущерб. Stack cookies, guard pages, ASLR и прочее и прочее это ведь все тоже самое - дополнительные уровни защиты, чтобы баги в работе с памятью не приводили к реальному эксплоиту.
Такая атака производится при помощи комбинации аппаратных и программных средств, её можно провести удалённо.
Непонятно, для удалённой реализации «комбинация аппаратных и программных средств» нужна или нет? Насколько всё серьёзно-то?
Тоже удивило такое сочетание. Пока из версий, которые смог придумать, наиболее правдоподобной является такая, где для удалённой эксплуатации уязвимости при помощи программно-аппаратных средств к атакуемому компьютеру отправляется квадрокоптер с флешкой.
Здесь речь об атаке конкретно на PAC механизм. Похожим методом, что использовался в meltdown и spectre, удалось подобрать правильные PAC значения и обойти эту защиту. Но PAC это просто механизм защиты. Само себе это ничего не дает. Просто это упрощает написание эксплоита, когда у нас на руках есть реальная уязвимость, но PAC мешает ее эксплуатировать. А под комбинацией тут имеется ввиду, что сама атака на PAC осуществляется посредством уже имеющегося бага в работе с памятью, что позволяет уже эксплуатировать уязвимость в железе, в механизме спекулятивного исполнения. Собственно, если у тебя нет бага, то нет и надобности PAC обходить. Так что в итоге смысл уязвимости просто в том, что PAC удалось обойти.
Ну почему. Это примерно как если у нас есть механизм уровней привилегий на аппаратном уровне, а мы как-то смогли его обойти. Здесь примерно тоже самое. PAC это важный механизм аппаратной защиты и его получилось обойти. Пейпер очень важный по разным причинам. Сам факт обхода PAC - тут все очевидно. Далее, удалось зареверсить эпловские чипы, про которые мы ничего не знает. Организовать side-channel атаку. При чем говорят этот чип не дает доступа к высокоточным таймерам, но им все равно удалось провернуть атаку. Далее, атака работает даже в отношении указателей в ядре - вот это уже очень важно. Потому что одно дело в юзерспейсе атаку провернуть и ROP цепочки. Другое дело, когда у тебя есть указатель в ядре, а ты сам в юзерспейсе. Это как раз прямой путь к "получить доступ к ядру ОС и даёт полный контроль над атакованным устройством". Атаке не мешают разные уровни привилегий. Модель угроз ядра строится как раз на предположении, что злоумышленник получил контроль над указателем. PAC должен нас тут защитить, а теперь получается и он не может.
PAC это важный механизм аппаратной защиты и его получилось обойти.
А вот Линус предлагает не относится к этому механизму как к системе защиты,
а скорее как к удобной аппаратной проверке на ошибки.
Honestly, I think a lot of these things should not be considered «security features» so much as «catch mistakes earlier» features. They are great for debugging, and I think that is how you should see them: aids to make it possible to actually ship binaries in production with debug features enabled that would be much too expensive without hardware support.
… I think ARM made a mistake in calling it «authentication» as if the checks were somehow secure. Even without any side channels, there just aren't enough bits in there to really be any true security.
Спорное мнение. Впрочем, как обычно у него. Такими темпами кучу защит можно так обозвать. ASLR тот же - рандомизация там не сильно большая, слайд не прям, чтобы огромный. Но все равно, система защиты и нынче обязательная для любой системы адекватной. А называть ли это аутентификаций - по факту, это она и есть. То, что там бит не хватает, чтобы быть криптографический стойкой в современных реалиях - так никто за это и не боролся вроде.
В процессорах Apple M1 нашли аппаратную уязвимость