LINUX.ORG.RU
Новости — Безопасность

Уязвимости Dirty Frag, изменяющие страничный кэш для получения root в любых дистрибутивах Linux

 dirtyfrag, , pagecache, ,


1

2

В ядре Linux выявлены две уязвимости, по своей сути аналогичные несколько дней назад раскрытой уязвимости Copy Fail, но проявляющиеся в других подсистемах - xfrm-ESP и RxRPC. Серии уязвимостей присвоено кодовое имя Dirty Frag (также встречается упоминание Copy Fail 2). Уязвимости позволяют непривилегированному пользователю получить права root, перезаписав данные процесса в страничном кэше. Доступен эксплоит, работающий во всех актуальных дистрибутивах Linux. Информация об уязвимости раскрыта до публикации исправлений, но есть обходной метод блокирования проблемы.

Dirty Frag охватывает две разные уязвимости: первая в модуле xfrm-ESP, используемом для ускорения операций шифрования в IPsec с использованием протокола ESP (Encapsulating Security Payload), а вторая в драйвере RxRPC, реализующем семейство сокетов AF_RXRPC и одноимённый RPC-протокол, работающий поверх UDP. Каждая из уязвимостей по-отдельности позволяет добиться получения прав root. Уязвимость в xfrm-ESP проявляется в ядре Linux с января 2017 года, а уязвимость в RxRPC - с июня 2023 года. Обе проблемы вызваны оптимизациями, допускающими прямую запись в страничный кэш.

Для эксплуатации уязвимости в xfrm-ESP у пользователя должны быть права на создание пространств имён, а для эксплуатации уязвимости в RxRPC должна быть возможность загрузки модуля ядра rxrpc.ko. Например, в Ubuntu в правилах AppArmor непривилегированному пользователю запрещено создание пространств имён, но по умолчанию загружается модуль rxrpc.ko. В каких-то дистрибутивах отсутствует модуль rxrpc.ko, а но не блокируется создание пространств имён. Выявивший проблему исследователь подготовил комбинированный эксплоит, способный атаковать систему через обе уязвимости, что позволяет эксплуатировать проблему во всех крупных дистрибутивах. Работа эксплоита подтверждена в Ubuntu 24.04.4 с ядром 6.17.0-23, RHEL 10.1 с ядром 6.12.0-124.49.1, openSUSE Tumbleweed с ядром 7.0.2-1, CentOS Stream 10 c ядром 6.12.0-224, AlmaLinux 10 с ядром 6.12.0-124.52.3 и Fedora 44 с ядром 6.19.14-300.

Как и в случае с уязвимостью Copy Fail, проблемы в xfrm-ESP и RxRPC вызваны выполнением расшифровки данных по месту c использованием функции splice(), передающей данные между файловыми дескрипторами и каналами (pipe) без копирования, путём передачи ссылок на элементы в страничном кэше. Смещения для операции записи рассчитывались без должных проверок, учитывающих использование прямой ссылки на элементы в страничном кэше, что позволяло через отправку специально оформленных запросов перезаписать 4 байта по выбранному смещению и изменить находящееся страничном кэше содержимое любого файла.

Все операции чтения из файлов в первую очередь отдают содержимое из страничного кэша. В случае модификации данных в страничном кэше операции чтения из файла приведут к возвращению не реально хранимой на накопителе информации, а подменённых данных. Эксплуатация уязвимости сводится к изменению страничного кэша для исполняемого файла с флагом suid root. Например, для получения прав root можно прочитать исполняемый файл /usr/bin/su для его помещения в страничный кэш, после чего добиться подстановки своего кода в загруженное в страничный кэш содержимого этого файла. Последующий запуск утилиты «su» приведёт к тому, что в память будет загружен не оригинальный исполняемый файл с накопителя, а изменённая копия из страничного кэша.

Раскрытие информации об уязвимостях и скоординированный выпуск обновлений с устранением проблем было намечено на 12 мая, но из-за утечки информации сведения об уязвимости пришлось опубликовать до публикации исправлений. В конце апреля в публичном списке рассылки netdev были опубликованы патчи к rxrpc, ipsec и xfrm, без упоминания, что они связаны с устранением уязвимости. 5 мая мэйнтейнер подсистемы IPsec принял в git-репозиторий netdev изменение c предлагаемым исправлением в модуле xfrm-esp, описание к которому во многом повторяло описание проблемы, приведшей к уязвимости Copy Fail в модуле algif_aead. Один из исследователей безопасности заинтересовался этим исправлением, сумел создать рабочий эксплоит и опубликовал его, не зная о том, что на раскрытие сведений о проблеме до 12 мая введено эмбарго.

Обновления с исправлениями для ядра Linux и пакетов с ядром в дистрибутивах пока не опубликованы, но доступны устраняющие проблемы патчи - xfrm-esp и rxrpc. CVE-идентификаторы не присвоены, что усложняет отслеживание обновления пакетов в дистрибутивах. В качестве обходного пути защиты можно заблокировать загрузку модулей ядра esp4, esp6 и rxrpc:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

>>> Источник: OpenNET

★★☆

Проверено: dataman ()
Последнее исправление: maxcom (всего исправлений: 3)
Ответ на: комментарий от mky

И, если в драйвере будет ошибка

А если у бабушки будет елдак… Ты изначальный посыл-то не забыл с которым споришь?

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

Изначальный посыл:

В микроядре это была бы изолированная проблема этих 2 конкретных драйверов

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

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

К стройной системе костылей и подпорок добавляется бита, вбивающая любую заданую подпорку!

Для большинства пользователей неудобство из-за прекращения работоспособности отдельных функций не сравнится с риском использования

Да у большинства пользователей sudo без пароля, зачем там какие-то эксплойты локального повышения. А, если IPSec сервер, то без ESP он нафиг не нужен.

эксплоит для которой был опубликован раньше, чем проблема была устранена в ядре.

ЕМНИП, в ядре дырку закрыли быстро, а пока патчи разойдутся по дистрибутивам, пока пользователи обновят. И, здесь всё будет аналогично, пока определят что прописывать в killswitch, пока этой войдёт в дистрибутивы, пока обновления будут установлены. А, ещё будет забавно, если в разных ветках одинаковая killswitch-запись будет ломать разный функционал...

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

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

ptah_alexs ★★★★★
()
Последнее исправление: ptah_alexs (всего исправлений: 1)
Ответ на: комментарий от zabbal

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

В GNU Hurd с правильной лицензией есть больше? Minix хоть в проде используют.

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

Ну да, но только прямо в мозг сисадмину не опубликовать. Пока он прочитает, подумает. Может он вообще в отпуске :)

И, ещё примечательно, что, вроде opensource, вроде компиляй не хочу, но в описаниях/обсуждениях, что Copy Fail, что Dirty Frag нет чётки инструкций/описаний, какие опции (CONFIG_FOO, CONFIG_BAR) отключить при сборке ядра и какие возможности при этом отключатся. И с killswitch может быть история, что админ что-то где-то прочитал, типа срочно пропишите туда строку, без объяснения последствий. Прописал, убил IPSec сервер, сломал телеметрию или удалённый доступ, получил «похвалу» от директора и больше ничего туда прописывать не будет :)

Современное ядро — монстр. Хочешь самосбор — прочитать все опции конфигурации, всё описание к ним, не то, чтобы подвиг, но что-то героическое. При этом после чтения больше вопросов, чем новых знаний. Типа опция X каким софтом используется, и будет ли этот софт работать без этой фичи ядра. Например, нет в ядре нужного шифрования, сам переключатся на libssl. ЕМНИП, у gentoo есть проверки при установке пакета на конфиг ядра, но там это на уровне install-скрипта, а не на уровне зависимостей пакета.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от dataman

Предложен killswitch для экстренного отключения уязвимой функциональности

скринлокер портирован в Linux ? :-)

«пришлите немного битков чтобы обратно включить XXX»

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

Minix хоть в проде используют.

Гондоны тоже использует. И даже коннотации на удивление похожи.

zabbal ★★★★☆
()

для получения root в любых дистрибутивах Linux

Ктсати да, проверил в альтлинукс — ядро старое, но эксплоит не работает.

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от zabbal

Тот, который реализует системный вызов splice(). В вашем микроядре для реализации zero-copy каждый из драверов должен уметь лазить в память другого, иначе какой это zero-copy.

А что такое «модуль xfrm-ESP»?

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

Ну нам же нравится та гибкость и те возможности, которые дает Linux? Не тот «православный» 2.6.*, а тот который свежий, с пылу с жару с поддержкой всего на свете. За это приходится платить кодовой базой и ее сложностью. Да - размер кодовой базы не обязательно прямо пропорционален сложности, но явно коррелирует. И ничего ты с этим не сделаешь. Хочешь ОС общего назначения для всего на свете - получай здоровенное сложное ядро. И *BSD тут не исключение. Что с этим делать? Да хрен его знает. Есть подозрение, что ответ тут простой - «работать». Иногда нет «умного и простого решения». Иногда действительно нужно одну за другой закрывать найденные дырки.

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

с поддержкой всего на свете

Одно дело поддержка, а другое дело производительность. Вот, один из обсуждаемых тут багов появился в 2017 году, до этого его не было. Тогда добавили около 100 строк кода, сейчас, для исправления ещё несколько строк добавили. И никаких новых фич, поддержки чего-то не добавилось, просто меньше операций процессора для IPSec. Вот, типа в 2017 году вдруг все осознали, что им не хватает производительности IPSec, ЦП дерградировали, а сетевые каналы расширились :)

И баги этой темы, и предшествующий CopyFail и древний DirtyPipe — всё об одном, в ядре добавили возможность поднять производительность за счёт меньшего копирования данных из одного буфера в другой. Но работать с этим крайне осторожно. Вот и вопрос, оно того стоит? Уровня кодеров не хватает понять, какие там хитровывертнутые варианты могут быть и сколько нужно проверок сделать, прежде чем что-то куда-то записать.

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

Вот и вопрос, оно того стоит?

Полагаю на круг вполне себе стоило. Тут ведь важно не забывать, что Linux это куча сетевых железяк и если ты можешь сэкономить что-то на CPU в Ipsec - на дистанции в 9 лет оно окупилось несколько (десятков?) раз. Так что да - сложность кода на фоне дефицитного железа (а давайте объективно - железо с 2017 года только дорожало) это хорошая цена за производительность.

offtop в сторону
В ту же копилку и Rust (хоть его и принято активно не любить) не просто так набирает популярность. Он позволяет писать производительный код. Новый дивный мир деглобализации, с удлинняющимися цепочками поставок, [тарифными] войнами будет навязывать нам новые правила. И если в условном 2015 году я еще помню фразы «время разработчика стоит так дорого, что проще закидать проблему железом», то чем дальше тем меньше слышно подобных сентенций.
offtop в сторону

t500s ★★★
()
Последнее исправление: t500s (всего исправлений: 1)
Ответ на: комментарий от t500s

При деглобе становится дешевле использовать fpga с конфой под проблемную область ибо за счёт деглобе относительный лоск на платформу становится менее невыгодным

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

А может вы прочитаете что-то, кроме ЛОР? Так, речь идёт о двух уявимостях и трёх модулей ядра. Но это про модули Линукс, а не про существующую в вашей голове микроядро с cgroups с раздельным файловым кешем для каждой cgroup.

mky ★★★★★
()

В качестве обходного пути защиты можно заблокировать загрузку модулей ядра esp4, esp6 и rxrpc:

Я их просто удалил. Slackware самосбор. По умолчанию вроде не нужны «для интернета» и не грузились.

Спасибо!

Andrew-R ★★★★★
()
Ответ на: комментарий от mky

А что такое «модуль xfrm-ESP»?

речь идёт о двух уявимостях и трёх модулей ядра

Падежи согласовывать пока не научился, но новость наконец-то прочитал судя по всему. И то хлеб.

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

По сути ответить нечего, начали прикапываться к опечаткам. Типично. Лучше бы дальше продолжали описывать ваше фантазийное микроядро, было бы интерестнее. Там, как я понял, есть модуль xfrm-ESP, который, видимо ESP и для ipv4, и для ipv6 реализует.

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

Там, как я понял, есть модуль xfrm-ESP

Почему из двух модулей, указанных в новости, ты подорвался только на один? Тебе дефис в названии смутил?

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

В новости три модуля esp4.ko, esp6.ko и rxrpc.ko. То, что esp4 и esp6 правились одним патчем/коммитом, не делает из них один модуль, ломались они разыми коммитами.

xfrm-ESP — вобще неведомое словосочетание, модуля с таким именем в Линукс нет, в документации тоже не встречается. Есть подсистема XFRM, преобразующая пакеты по своим политикам и в ней есть часть, реализующая ESP-протокол. Если всё подряд называть модулем или подсистемой, то можно и до xfrm-ESP-in-UDP дойти...

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

Что-то ваше мнение туда-сюда шатается. Прочитайте новость полностью, а не первые два абзаца. Потом посчитайте, сколько модулей советуют блеклистить. А если вы так уверены, что модуль xfrm-ESP существует, то дайте ссылку на его исходники, покажите, что про него выводит команда ″modinfo″.

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