LINUX.ORG.RU

Очередной «Взлом» линукс,... ?

 


0

2

Александр Попов представил методику эксплуатации критической уязвимости CVE-2024-50264 в ядре Linux. Его работа принесла ему победу в премии Pwnie Awards 2025 в категории «Лучшее повышение привилегий».

А.Попов сумел обойти случайное распределение SLAB-кэшей и другие препятствия, разработав цепочку атак. «Ранее считалось, что эксплуатация проблемы крайне затруднена из-за защитных механизмов ядра, таких как случайное распределение SLAB-кэшей и особенности работы SLAB-бакетов, мешающих прямолинейным методам вроде heap spraying. Однако Попов сумел разработать цепочку приёмов, которая снимает эти ограничения»

https://a13xp0p0v.github.io/2025/09/02/kernel-hack-drill-and-CVE-2024-50264.html?utm_source=Securitylab.ru

По ссылке очень много букв (и вообще !Ъ), а из поста толком непонятно, можете разжевать по-простому, что именно может сделать злоумышленник, воспользовавшийся этой уязвимостью? Можно ли её использовать совсем удалённо, или нужно делать от залогиненного в систему юзера? Может ли он повысить полномочия, или только что-то уронить?

CrX ★★★★★
()
Ответ на: комментарий от CrX

это UAF в ядре, дающий LPE, на CVSS вектор можно посмотреть в обычном месте: https://nvd.nist.gov/vuln/detail/CVE-2024-50264 там же написано, когда её исправили.

демку можно посмотреть на https://www.youtube.com/watch?v=qC95zkYnwb0

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

крутой чел.

anonymous
()
Ответ на: комментарий от cobold

Ну не скажи. Баги везде есть. А вот такие хитрые технологии, которые надо обходить, чтобы превратить баг в уязвимость - не везде.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Так если бы я пользовался маком, меня наверное бы и интересовали баги макоси. А так то что они там есть как-то фиолетово

cobold ★★★★★
()
Ответ на: комментарий от vbr

Анон так сказал. Ну и в целом если смотреть на статью по ссылке, то арм презентовал первую версию реализации ещё в 2019 и только сейчас эпл дотащил софтверную реализацию до юзерленда ios(возникает вопрос почему только иос? ведь есть ещё macos и тоже на apple silicon). Т.е. 6 лет и это при условии что эпл плотно контролирует всю экосистему(железо, стек разработки, ос)

cobold ★★★★★
()
Ответ на: комментарий от vbr

потому, что довольно сложно это сделать с их легаси и с возможной необходимостью менять ABI. ARM не надо за собой тащить всякое, а apple на своём кремнии может реализовывать ещё меньше, только то, что им явно нужно.

например, в статье написано, что они нашли байпас к ARM’овому MTE, поэтому сделали свой, а ещё отказались от асинхронного репортинга.

все такие изменения требуют контроля над железом и софтом одновременно, иначе тяжело и долго. apple смог вон дважды архитектуру поменять, с power на x86, потом на arm. они пропустили 32bit arm целиком, по-моему, у них даже не было 32 битного кода, может, сейчас даже совместимость отломали. дважды сделали эмуляцию, которая работала, ну не офигеть ли?

anonymous
()

Однако Попов сумел разработать цепочку приёмов, которая снимает эти ограничения»

фигасе…

ведь может собственных платонов 
и быстрых разумом невтонов, 
российская земля рождать! 

он между прочим еще и радио изобрел.

alysnix ★★★
()
Ответ на: комментарий от anonymous

потому, что довольно сложно это сделать с их легаси и с возможной необходимостью менять ABI.

Ну ARM же сделали.

ARM не надо за собой тащить всякое

Чегой-то не надо? ARM уже достаточно старая архитектура и обросла точно такими же костылями.

а apple на своём кремнии может реализовывать ещё меньше, только то, что им явно нужно.

Может быть и может, но по факту реализует ARM с некоторыми дополнительными инструкциями.

все такие изменения требуют контроля над железом и софтом одновременно, иначе тяжело и долго

Это не проблема для Intel. В линукс они коммитят. Как с микрософтом они сотрудничают - я не знаю, но вообще не удивлюсь, если они в виндовое ядро коммитят. Даже если не коммитят, то плотно сотрудничают - это 100%, в этом заинтересованы обе компании.

apple смог вон дважды архитектуру поменять, с power на x86, потом на arm

А линукс поддерживает десяток архитектур, и что? Тоже мне, достижение.

они пропустили 32bit arm целиком, по-моему, у них даже не было 32 битного кода, может, сейчас даже совместимость отломали.

На мобильных платформах был. Ядро там плюс-минус общее, так что не пропустили.

дважды сделали эмуляцию, которая работала, ну не офигеть ли?

qemu тоже работает, причём для куда более широкого круга архитектур. Не офигеть. Причём qemu поддерживает эмуляцию любого кода, а не только юзерспейса, как розетта.

vbr ★★★★★
()
Ответ на: комментарий от cobold

Т.е. 6 лет и это при условии что эпл плотно контролирует всю экосистему(железо, стек разработки, ос)

Ну эппл тормозы, значит. В арче поддержка появится через месяц после релиза процессора с соответствующими инструкциями. А может и за месяц.

vbr ★★★★★
()
Ответ на: комментарий от vbr

А может это не так тривиально. Например NX-бит появился в x86 где-то во время core2, а по сию пору некоторый прикладной софт требует executable stack

cobold ★★★★★
()
Ответ на: комментарий от anonymous

Так это проблема эппла, а не линукса. Интелбуки поддерживаются, потому, что интел прилагает усилия для их поддержки. Эппл не прилагает, макбуки поддерживаются силами добровольцев, тут чудес не будет.

vbr ★★★★★
()
Ответ на: комментарий от vbr

не, это проблема линукса. эппл не обещал линукс поддерживать, никогда этого не декларировал.

эппл обещал делать ядро и ключевые библиотеки операционной системы, поверх которой сделать 4 родственных системы со всякими полезными в плане безопасности фичами. можно спорить о выбранных методах, но нельзя сказать, что их выбор плохо работает: MTE, Blastdoor, pointer authentication, и прочее очень быстро проникают во все части платформы и в приложения, разрабатываемые третьими сторонами.

вот тебе яркий пример - shadow stack. хорошая, полезная фича для безопасности. интел запустила процессоры с ним лет пять назад, а спеки были ещё раньше. линкус как бы поддерживает эту фичу все пять лет (с подачи самого интела, конечно). я вот сейчас сделал

find /usr/bin -type f -perm -4000|xargs readelf --notes|grep -c SHSTK
0

ноль суидных бинарей его включили. последний Debian.

проверяем включенный PAC в макоси:

find /usr/bin -type f -perm -4000|sudo xargs otool -hv

все бинари с PAC.

это всё хорошо, что «линукс поддерживает» в принципе, но недостаточно. примерно как SELinux, который как бы есть, но каждый первый рукож$пый дивапс или админ его выключает

линукс - классное ядро, но огромная фрагментированность и большой багаж легаси мешают. я бы, например, рад был существованию серверного дистрибутива, заточненного на безопасность. но такой поискать ещё надо, разве что openwall.

в общем, слишком медленно и слишком тяжело.

anonymous
()
Ответ на: комментарий от anonymous

не, это проблема линукса

Это не может быть проблемой линукса, т.к. линукс на M1 это супер-экспериментально и этим почти никто не пользуется. Линукс нормально работает на Intel, более-менее нормально на AMD.

эппл не обещал линукс поддерживать, никогда этого не декларировал.

Ну а кто должен поддерживать? От энтузиастов что-ли требовать что-то? Грузится - уже слава богу.

ноль суидных бинарей его включили. последний Debian.

Проверил ubi10 образ (RHEL 10) - 9 бинарников, судя по всему всё так скомпилировано.

это всё хорошо, что «линукс поддерживает» в принципе, но недостаточно. примерно как SELinux, который как бы есть, но каждый первый рукож$пый дивапс или админ его выключает

И SELinux в RHEL включен. Ну а то, что отключают - так тут аргумент непонятен. Запрещать отключать что-ли? Хотят и отключают, что ты им сделаешь.

я бы, например, рад был существованию серверного дистрибутива, заточненного на безопасность. но такой поискать ещё надо, разве что openwall.

Ну RHEL можно таковым считать. Не то, чтобы он прям заточен, но безопасностью там не пренебрегают. Наверняка и в его клонах всё плюс-минус так же.

vbr ★★★★★
()
Ответ на: комментарий от vbr

т.к. линукс на M1 это супер-экспериментально и этим почти никто не пользуется

ну так и всё в линуксе так - суперэкспериментально, в одном дистрибутиве не работает, в другом - работает. «в принципе» поддерживает, посмотрите на RHEL, но на деле самый популярный дистрибутив - нет.

И SELinux в RHEL включен. Ну а то, что отключают - так тут аргумент непонятен.

аргумент очень простой абстрактное «фича есть» не является примером, если крупнейший дистрибутив её не использует. SELinux есть, но его отключают, pointer authentication или shadow stack есть, но по факту на куче серверов нет - в макоси из-за её монолитности и сильной интеграции с железом фичи катятся на всех пользователей быстро. все пользователи от этого получают пользу. интеграция с железом наносит ещё большую пользу.

в линуксе на x64 это не так, из-за фрагментации и из-за массивного легаси, которое сложно переодолеть, не ломая обратную совместимость, чего интел не может себе позволить. поэтому

anonymous
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.