Уязвимость в ядре Linux с возможностью локальной эксплуатации через nftables

По всяким контейнерным хостингам ещё не проэксплуатировали?

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

Если у юзеров рассыпается от обновления ядра (которое вне контейнера), то с ещё большей вероятностью найдутся юзеры у которых контейнер не совместим с древним ядром и они попросят поновее.

А давно у контейнеров ядро появилось? :)

Ну вот опять каких-то анскильных лалок вместо Настоящих Разработчиков в ядро пустили.

Совсем не давно, до этого контейнер прям без ОС на голом железе работал

Условия эксплуатации выглядят экзотически.

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

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

Я хз как там у Докера сейчас а у Подмана контейнеры давно от юзера пускаются.

Что значит «от юзера пускаются», и зачем ты их с больших букв пишешь? Ну и докероподманы это только один из вариантов контейнеров. Есть контейнеры с полноценной ОС внутри, как легковесная виртуалка, например LXC.

Привилегированный контейнер, конечно, да. Непривилегированный с cap_net_admin? Ни разу не видел, может где-то используется, расскажите зачем.

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

В теме написано что нужен CAP_NET_ADMIN внутри неймспейса. Его по-моему можно организовать и не имея особых прав. Хотя я не проверял.

Его можно организовать, если админ за пределами контейнера его тебе выдал ) С целью поуправлять пакетным фильтром изнутри контейнера, надо понимать.

Ни разу не видел, поэтому и спрашиваю, вдруг знает кто.

внесено в текущие стабильные ветки 5.10.204, 5.15.143, 6.1.68 и 6.6.7.

В генте стабильно ядро
6.1.67

Всё пропало.

Есть контейнеры с полноценной ОС внутри,

Пример в студию. Валяй мне контейнер запущеный в linux с windows.

Стоп. Т.е. докер может теперь работать без демона докер ?

https://docs.docker.com/engine/security/rootless/

Ок, ну после выхода podman для меня докер потерял актуальность. помелочи и так пашет а так сразу в кибер пихаю …

Так при чем тут контейнеры если уязвимость в ядре? :)

при том, что контейнеры используют хостовое ядро

Корень проблемы кроется в использовании освобожденной памяти (use-after-free)

Нестареющая сишная классика

Даладно... У всех есть предел понимания сложности. И сложность ядра уже где-то на грани человеческого понимания происходящего.

Причём тут винда? Речь про линуксы в виде нескольких независимых ОС с одним общим ядром.

Демон тут ни при чём вообще. Уязвимость не в демоне а в ядре, и какие права у демона - на ситуацию не влияет.

Что докер что подман одинаково ненужное. Нормальные контейнеры это LXC и подобное.

Что значит «локальной эксплуатации»? То есть. Есть местный компутерный магаз «РЕТ». Там бубунта на терминалах и подключаются к виндовому серваку через домен. Чтобы воспользоваться уязвимостью, я должен незаметно для 40 камер подойти к терминалу и начать там пробовать? Учитывая что продавцы в магазине всегда.
Так ли страшны эти псевдоуязвимости или такое может вирус сделать, если закинуть его на комп, взломав сеть?

Ну так все что есть использует его. Почему контейнеры какие-то особенные? В этом мой вопрос )

Я просто регулярно слышу как люди говорят: «вы просто писать на си не умеете, раз у вас проблемы с управлением памятью».

Так что это такой традиционный сарказм.

Как ни пиши, но когда у тебя выделенная память под указателем через полядра тащится и освобождается в неочевидном месте, то double free будут всегда. Поэтому kfree(NULL) is safe :) Ну не работает в ядре весь этот ВАш хваленый RAII :)

Ну не работает в ядре весь этот ВАш хваленый RAII :)

Это проблемы ядра, а не RAII. Точнее, одна проблема: некто не любит плюсы.

Да вон, Макось, по слухам, на них писана местами. Как-то работает... :) А что толку-то? У тебя оверхеда в плюсах с автоуничтожением объектов будет больше. А если объекты передавать куда-то по указателю, то проблемы будут ровно такие же. В плюсах никто не знает, чего стоит объект создать и сколько деструкторов отработают при его уничтожении. Плюсы за другое не любят, но это отдельный разговор.

Ну наконец-то хоть кто-то написал, а то я уже заждался. :)

Не по указателю, а по ссылке. А если тащится туда, где её собираются освобождать, то move(unique_ptr). Семантика владения в плюсах вполне себе обложена достаточно простыми и интуитивными рекомендованными практиками. Что в свою очередь означает, что семантика эта по крайней мере осознаётся.

А что до стоимости уничтожения – то во-первых, если что-то надо уничтожить сложно, то его и на сях придётся сложно уничтожать, только ручками (что мы собственно в ОП и видим 🤣). А во-вторых, никто ж не заставляет использовать сразу весь квадриллион фичей плюсов, и не сразу тоже; продолжайте гонять туда-сюда обычные сишные структуры, где понятно – впиливайте деструктор и RAII, где непонятно – читайте книжку Фаулера «Рефакторинг».

А откуда ты взял оверхед от уничтожения – вообще непонятно.

Спасибо. Только как это применимо к ядру не есть понятно. Вот опять же, ВАш ООП, семантика ссылок и прочее Александреску головного мозга плохо применимы к реалиям событийно-управляемого кода ядра. Иначе, опять будем обсуждать или сферическое ядро в вакууме, или конфликт благих намерений с суровой реальностью. В общем, очередной С-плюс-плюсо-срач образуется.

Ну и к чему вы тут приплели событийно-управляемость? Может по-вашему, это такая магическая хрень, которую можно запилить только на голых сях? А то мне тут с ходу припомнились реализации на самых разных сильно более других языках, включая к слову и C++.

И вообще, мой пойнт очень простой: C++ это надмножество C. Соответственно, всё что можно сделать на сях, можно и на плюсях. Плюс на плюсях можно по щелчку сделать дофига всего, что эмулировать на сях – чистейший гимор. В том числе это самое RAII.

И к слову, в расте, который в ядро пропихнули, RAII тоже есть. Фсем бояццо! :)

Запилить можно что угодно на чем угодно. Но это надо пилить сразу и единообразно. Я начал с того, что нелокальное освобождение памяти в ядре — обычная практика. И все эти благопожелания типа «здесь взял — тут и отдай» в ядре не работают. В ядре же мы часто видим комментарии к функции типа «а вот это вызывается под локом таким-то» или «а вот это оставляет мутекс такой-то». Ну какие тут, блин, ссылки, локальное управление ресурсами, ООП?.. Хотите по-другому — пишите с нуля. Попытки писать ядра на С++ были. Но, чот как-то остались попытками.

С хорош тем, что он делает ровно то, что написано. С++ имеет скрытую исполняющую систему, даже если не пользоваться RTTI и исключениям.

В ядро пропихнули. И что? Диспетчер памяти там переписан весь как unsafe. Ну и какой профит? То же самое, только вид сбоку и без goto?

Ок, по ядру я лапки кверху. А про скрытую исполняющую систему - враньё. :) К слову, один из трёх озвученных Страуструпом фундаментальных принципов, лежащих в основе дизайна C++, – «не платим за то, что не используем».

Более того, один и тот же сишный код в режиме C++ может скомпилироваться эффективнее, чем в режиме C. Информация настолько древняя, что я уже и не помню, сам наткнулся или прочитал где. Причина, полагаю, в том, что C++ сильно злее в плане контроля типов, и поэтому у его оптимизатора больше информации.

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

Но тоже не панацея. Ну как минимум пока задачу останова решать не научится человечество.

С хорош тем, что он делает ровно то, что написано.

Расскажи это тем, кто переписывает код распихивая барьеры, например, под -O3, потому что ровно то, что написано, оказывается, выполняется совсем не так как написано и не в том порядке.

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

Ну я уже писал прт раст в ядре. Там весь диспетчер памяти переписан и аллокаторы объявлены как unsafe. Смотрел я на это краем глаза, но чот выйгрыша на этом поле не видно. Ну goto нет, и из-за этого те же автоматы переходов становятся лексически избыточными. Тупо не понятно, что написано. Поэтому, зачем тянут раст для меня не есть пока понятно. Может какой-нибудь си с классами типа objective c и был бы полезен для более очевиднооо наследования свойств и таблиц вызовов в той же иерархии файловых систем.... Но написано, что написано. Преоеписывать это ради только что бы было на расте вряд ли будут.

Ну рейсы и оптимизация да, это отдельная история. Да ие только это. Там много чудесатого и без -О3.

Пытаюсь скомпилить тестовый код

g++ -o test test.cpp

И вываливается с такой ошибкой

error: invalid conversion from ‘void*’ to ‘char*’ [-fpermissive]

гуру С++, как исправить то?

Прикол в том, что даже unsafe в расте – это не сишный ад и холокост. И он надежно изолируется от остального кода

Это не C++

gcc exploit.c -lnftnl -lmnl -o exploit

Ну будем посмотреть. Если кому-то поможет, то в добрый путь. Если с помощью раста хотят побороть только небезопасные указатели, то пустая затея, если какую-то объектную ориентированность навести, то она у раста какая-то весьма запутанная. Я так и не понял, есть у него наследование или нет? Что такое есть эта его implemetation inheritance я так и не понял пока. Какое-то это все умствование пустое.