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)

WitcherGeralt, да, зачетную вещь нашли. и всего-то за $10000. ) обратил внимание, что исследователь даже не стал брать эти деньги?:) нищим мелочевку раздал.) и только на лоре уже две страницы школьники тупят: а зачем это?? а что будет?? а это что за утилита вообще??

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

Человек, ты перестарался. Там до юза не дошло, но ты даже не понял почему.

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

у меня ругается «gcc: command not found»

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

(мне кажется если знаешь что проблема с размером есть то при каждом обращении к буферу (чтение, запись) проверка размера должна выполняться уже просто инстинктивно)?

Проверка, там, проверка здесь и постепенно мы приходим к васику в котором все это уже из каробки. Надеюсь доступно?

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

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

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

использования памяти после освобождения?

А тут тот же вектор вполне полностью решает проблему.

И вопрос с другой стороны: как контролировать границы, которые не известны во время компиляции? Проверять при доступе и паниковать?

Лучше паниковать чем допустить уязвимость.

Это пробему даже зависимые типы не рашают.

Вроде вполне решают.

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

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

Конечно. Даже в коде ничего менять не нужно. Компилируешь с -fsanitizer=address и у тебя гарантированно не будет write out-of-bounds, а просто приложение упадёт, если где-то в коде такое есть. Правда скорость будет примерно раза в 2-3 медленнее…

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

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

anonymous
()

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

А понятно

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