Уязвимость в Netfilter

Эксплойт: https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555

У меня вместо iptables стоит FireWalld. На нем тоже работает?

Это всё утилиты для управления netfilter-ом. Сам netfilter - часть ядра.

Это всё фронтэнды. Баг в подсистеме ядра – netfilter.

Да, работает.

gnu/stubs-32.h
нет такого файла или каталога
gcc -m32
увы

Да поняла я уже. Это с ядром у них проблемы, как всегда.

Опять сишная ды…

Хорошо, что исправили. Плохо, что долго не замечали.

Я ничего не понял. В чём опасность этой уязвимости? Только то, что кто-то вылезет из контейнера? Если у меня в контейнере не запускается недоверенный софт, можно не спешить обновляться?

Если у меня в контейнере не запускается недоверенный софт, …

… то зачем тебе контейнер? Запускай на хосте.

Netfilter — подсистема ядра, более известная по пользовательской утилите iptables, предоставляющей для неё интерфейс командной строки, и используемой для управления правилами брандмауэра.

iptables использует xtables а не netfilter. iptables-nft как переходная утилита использует netfilter, но вообще для netfilter предполагается использовать nftables

Твой доверенный софт может оказаться дырявым, сначала поимеют его, а потом поимеют хост.

ко-ко-ко контейнеры-безопасность-изоляция, говорили они...

Уязвимость связана с записью за пределы буфера (write out-of-bounds) и использованием данных в памяти после её освобождения (use-after-free)

Никогда такого не было, и вот опять!

Никогда такого не было, и вот опять!

Вот перепишут не rust, уязвимости не будет. Будет паника, и хрен что сделает зловредный червь. Шах и мат!

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

user namespaces, появившаяся в 3.8 версии ядра, и которая может быть отключена в зависимости от дистрибутива.

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

Но вообще, я зашёл сюда не за этим, а чтобы задать вопрос, который непременно должен быть в таком треде: pf или ipfw?

то зачем тебе контейнер?

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

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

Напишешь инструкцию, как такое провернуть?

Сто лет уже как написано, но если спросят — это не я (и опять-таки, только для касперского).
https://dogberrt.livejournal.com/14863.html
Да, я не претендую на то, что это прям самый правильный способ, но другого гайда на тот момент я не видел, поэтому городил костыли по своему разумению.

Премного благодарен.

софт не рассчитан под мой дистрибутив

Это уже «недоверенный софт». Ты либо определись с «недовереностью». Либо используй небинарное определение уровней «доверия».

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

К примеру есть Cloudflare Warp. Этот софт не рассчитан для Fedora, поэтому я его пускаю в контейнере. Но с другой стороны у меня нет никаких оснований полагать, что такая крупная компания будет писать вредоносный софт, поэтому он вполне доверенный, просто не адаптированный.

Перепутали user namespaces и network namespaces.

Этот софт не рассчитан для Fedora

Поэтому может попортить хост, если не изолировать?

Контейнеры сами по себе не предназначены для обеспечения безопасности и контроля доступа. Доверенный/не доверенный софт – не имеет значения. Если ничего другого не сделано, можете счиитать, что у вас все работает на хосте. А какие-нибудь лишние capabilities могут даже ухудшить положение.

Лол, и правда, слепой совсем.
Ну, не удалять же теперь %)

Поэтому может попортить хост, если не изолировать?

Ну сдуру мало ли чего он там наделает. С изоляцией спокойней.

Контейнеры сами по себе не предназначены для обеспечения безопасности и контроля доступа.

Так вот же эта тема про то, что исправляют ошибки CVE. Значит предназначены. Иначе CVE не назначали бы.

Панику наверняка быстрее чем за 15 лет заметили бы и исправили.

Нет. Если я правильно прочитал PoC, проблема не в контейнерах и не в нарушениии «изоляции», а как раз в том, что при использовании контейнера

какие-нибудь лишние capabilities

делают возможной эксплуатацию бага в netfilter. Насколько я понял, CAP_NET_ADMIN позволит эксплуатировать баг вне всяких контейнеров.

Это ровно тот случай, когда использование контейнера создает новые условия для атаки (не на контейнер).

заметили бы и исправили.

Заметить - да. Исправить - не знаю. Знание проблемы не дает умений как исправить. Особенно на сильно огороженном чистотой типов языке. Либо придется паниковать, либо ломать ограду unsafe’ми, что не гарантирует, что уязвимость не вылезет в другом месте.

Я вообще ничего не понял. Если ты понял, объясни тогда подробней, кто кого эксплуатирует. root-а можно получить из локального пользователя или что?

iptables использует xtables а не netfilter

А xtables что использует? Магию чёрную?

Уязвимость связана с записью за пределы буфера (write out-of-bounds)

Эта проблема практически в каждой уязвимости встречается. Я никогда на C не писал, так что не в курсе, но может кто-нибудь в двух словах мне объяснит можно ли там как-то «глобально» это «исправить» или почему авторы кода на C до сих пор на это напарываются (мне кажется если знаешь что проблема с размером есть то при каждом обращении к буферу (чтение, запись) проверка размера должна выполняться уже просто инстинктивно)?

А я так и не поняла из новости, чем грозит это уязвимость обычным пользователям (не google)?

Переполнили память, а дальше что - сервис ip-адресации «упадёт», интернет отключится, или чего случится?

Уязвимость связана с записью за пределы буфера (write out-of-bounds)

Чёйта гнусно хихикаю.

можно ли там как-то «глобально» это «исправить»

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

Заметить - да. Исправить - не знаю.

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

может кто-нибудь в двух словах мне объяснит можно ли там как-то «глобально» это «исправить»

В си глобально это исправить невозможно, можно сильно уменьшить вероятность таких ошибок более жесткой типизацией и (полу)автоматизацией выделения памяти, этим путем пошли C++ и rust, если это делается правильно, то на производительность кода это не влияет. Другой путь полностью запретить пользователю выделять память и использовать указатели, этим путем пошли языки с GC, но это обычно сильно не бесплатно по используемым ресурсам (расход памяти и производительность).

А почему тогда правила, созданные через iptables не отображаются в nftables и наоборот?

Проблема всех подобных ошибок в том что их годами тупо не замечают.

Зайду с другой стороны. Ну вот написали там ОС на rust. Знают что, он течет как Ниагарский водопад. Исправили, ясно же видна проблема?

Не зря rust в ядро тащат

Написали прототип ОС в котором тупо совсем не освобождали память, но с этим похоже тролли будут носится уже вечно.

То есть проблема есть, решения нет.

Теперь вернемся обратно. Вот переписали все на rust и теперь линукс течет, ой, то есть, падает как Ниагарский водопад на каждый чих. Твое решение этой уже известной проблемы? (Линус уже сказал свое «фи!»)

Проблема ровна такая же как в с++, в си проблема тяжелее, raii не завезли нормального.

Как raii помогает в решении проблемы обращеня за границы массива, и использования памяти после освобождения?

И вопрос с другой стороны: как контролировать границы, которые не известны во время компиляции? Проверять при доступе и паниковать? Или проломит ограду unsafe? Это пробему даже зависимые типы не рашают.

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

правила, созданные через iptables не отображаются в nftables и наоборот?

Это разные вещи работающие принципиально иначе.

Xtables/iptables работает за счёт хуков в Netfilter, а nftables имеет что-то типа ВМ внутри Netfilter и обрабатывает пакеты согласно инструкциям, заданным правилами.

Проблема ровна такая же как в с++, в си проблема тяжелее, raii не завезли нормального

проблемы у дебилов и это не зависимо от ++

https://git.haiku-os.org/haiku/commit/?h=r1beta3&id=910dcb52987e78d4db8d29c38eebd2df17323f6a

я так и не поняла из новости, чем грозит это уязвимость обычным пользователям

теоретически

сервис ip-адресации «упадёт», интернет отключится

+100500 ещё всякого-разного компьютерного треша может произойти – всё чего атакующий пожелает

но практически, ты твой компьютер ничем не рискует – больно надо «сырёзным хаккерам» искать на бескрайних просторах сетей интернета одинокий ПКашник с линукс-шеретом на борту. чего с тебя взять: твои фоточки?!