LINUX.ORG.RU

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

 , , , ,


1

0

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

CVE-2021-22555 при определённых условиях позволяет повышение привилегий. Уязвимость впервые появилась в Linux 2.6.19-rc1, но для её эксплуатации непривилегированному пользователю необходима функциональность user namespaces, появившаяся в 3.8 версии ядра, и которая может быть отключена в зависимости от дистрибутива.

В Arch Linux, Debian и Fedora исправления уже подготовили, а в openSUSE и Ubuntu, где user namespaces по-умолчанию включены, ещё нет.

Уязвимость связана с записью за пределы буфера (write out-of-bounds) и использованием данных в памяти после её освобождения (use-after-free). Она была использована для обхода изоляции контейнеров в kCTF demo cluster, за что Google обещала награду от $5000 до $10 000. Исследователь в сфере безопасности Andy Nguyen, обнаруживший уязвимость, собирается потратить выигранные $10 000 на благотворительность, в этом случае Google удвоит пожертвование.

>>> Подробности

★★

Проверено: Shaman007 ()
Последнее исправление: xaizek (всего исправлений: 2)

Ответ на: комментарий от Djanik

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

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

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

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

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

Djanik
()

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

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

anonymous
()

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

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

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

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

anonymous
()

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

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

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

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

WitcherGeralt ★★
() автор топика

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

Harald ★★★★★
()

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

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

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

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

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

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

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

Harald ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Legioner ★★★★★
()

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

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

micronekodesu ★★★
()

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

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

Lina_Risa
()
Последнее исправление: Lina_Risa (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.