LINUX.ORG.RU

Уязвимость в реализации NFS-сервера FreeBSD и OpenBSD

 , , ,


0

3

В коде NFS-сервера проектов FreeBSD и OpenBSD обнаружена уязвимость CVE-2024-29937, приводящая к удаленному выполнению кода от произвольного пользователя. Проблема существует с самого первого выпуска и затрагивает актуальные релизы OpenBSD 7.4 и FreeBSD 14.0. Детали будут представлены позже в рамках доклада на конференции по безопасности t2, проходящей в Хельсинки 18-19 апреля.

>>> Демо



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

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

Ну, значит не туда заглядывали.

Последнее они исправляли что-то в клиенте, а тут вылезло в сервере.

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

всё что имеет доступ в интернет имеет кастыли и уязвимости

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

мы живём в крайне интересное время, когда хомячок даже и не задумывается о предустановленных python 3.11/perl в linux дистрибутивах

Причём здесь Python и Perl?

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

Я и не утверждал что SMB лучше NFS, я утверждаю что оно другое (подход, реализация). И проблемы у Samba совсем в другом обычно. ☺

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

В идеале NFS используется с amd, который кеширует и синхронизирует файлы + завязана на какую-нибудь распределённую систему авторизации. Имеет сильно меньше оверхеда, чем SMB, сравнимо с ftp. В любом случае, настраивать её нужно долго, аккуратно и только если она нужна (а не файлики шарить), ну и сильно внутри локальной сети.

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

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

В большинстве случаев это решается файловой шарой. Потому что работает.

cumvillain
() автор топика
Ответ на: комментарий от firkax

Даже без этой дырки, NFS не безопасна, она быстра и хорошо совместима на unix системах, защита лежит сугубо на тебе, это твоя задача vpn пробрасывать и шифровать, авторизация кербос есть, но это не про защиту.

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

NFS не безопасна

Так в NFS вродь как давно уже завезли шифрование и авторизацию через Kerberos 5. Судя по всему, у тебя познания о NFS 10-ти летней давности.

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

Да, для меня тоже было внезапно: настроил amd в 12.2, заглянул в ман, а там “deprecated, use automountd(8) instead”, пришлось изучать и перенастраивать. В любом случае amd было глючным, так что не могу сказать что произошло что-то плохое.

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

У amd шары могли отваливаться и больше не приваливаться, потому что маунтпоинт уже занят. А у autofs проблема в заморозке процессов, которые пытаются достучаться до отвалившейся шары. Последнее, вполне вероятно, случается потому что оно требует некоторого тюнинга, но с приходом NFSv4 нужда в этих демонах отпала полность, я считаю. Как только NFSv4 переподнимается (даже если это был ребут сервера, а клиенты предварительно не были отмонтированы), клиенты сразу подхватывают. Достаточно прописать в fstab и забыть. С NFSv3 это, разумеется, не прокатит, и без autofs уже не обойтись.

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

загуглил, про кербос я знаю настраивал, про шифрование читаю:

Unfortunately, NFS wasn’t designed for security. Fact is, the protocol doesn’t have any. If you give an NFS file server a valid handle for a file, the server lets you play with it to your heart’s content. Go ahead, scribble away: the server doesn’t even have the ability to log the network address of the workstation that does the damage.

перевод

К сожалению, NFS не был разработан для обеспечения безопасности. Дело в том, что в протоколе ее нет.

Кербос позволяет сказать что на этом ip сидит вот этот редиска-пользователь и не более, шифрованием он не занимается. Шифрование не добавили видимо потому, что это UDP протокол не потоковый. Все инструкции по использованию говорят, либо доверенная сеть, либо используй vpn. Может я ошибаюсь (хочу ошибиться) но в свежем 2016г. RFC 7862 шифрования не нашёл 😥.

s-warus ★★★
()
Ответ на: комментарий от iron

ты прав, я не прав есть опция для шифрования трафика

krb5p Use Kerberos for authentication, integrity checking and encrypt all traffic between the client and server. This is the most secure, but also incurs the most load.

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

что это UDP протокол

Начиная с NFSv4 работает по TCP. Смотри RFC 7530.

но в свежем 2016г. RFC 7862 шифрования не нашёл

Пункт 4.9.1.2:

Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS with privacy, thus ensuring that the cnr_stateid in the COPY_NOTIFY reply is encrypted.
iron ★★★★★
()
Ответ на: комментарий от WatchCat

Не так. Если мы сравниваем высокоуровневые(+/-) языки.

Т.е. в твоей вселенной C, C++, Go, Prolog и Lisp читаются одинаково легко вне зависимости от того, что на них написано / равноценны во всех отношениях?

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

Давно нашлась. При прочих равных, если не заставлять пользователя ЯП городить boilerplate и закатывать Солнце руками, возможности сделать логическую ошибку сокращаются. Факт.

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

Это всё хорошо, но я почти уверен, что, в отличие от ssh и даже дырявого openssl, nfs-шифрование почти никто всерьёз не тестировал. И дело даже не только в шифровании, а в том что там костыль на костыле, работающий по принципу «работает и ладно».

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

Если нужно шифрование, проще пустить NFS через wg.

cumvillain
() автор топика
Ответ на: комментарий от firkax

nfs-шифрование почти никто всерьёз не тестировал.

NFS шифрование это лишь слой на основе Ketberos, который стабильный и проверен временем. Используется, к примеру, в MS AD начиная с Windows 2000 Server и особых нареканий не вызывает. Какого еще тестирования тебе не хватает?

а в том что там костыль на костыле

Где ж там костыль, если авторизацию и шифрование сначала планомерно разработали в виде RFC и лишь потом реализовали в рамках нового протокола NFSv4? Если бы его прикрутили к NFSv3 – я бы согласился.

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

NFS шифрование это лишь слой на основе Ketberos, который стабильный и проверен временем. Используется, к примеру, в MS AD начиная с Windows 2000 Server и особых нареканий не вызывает. Какого еще тестирования тебе не хватает?

Тестирования кода этого слоя в линуксовом ядре не хватает.

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

Тоже мне проблема. Виновата сишка, авторы все умственные силы потратили на слежку за указателями да освобождением памяти, вот на логику их уже и не хватило. А писали бы на лиспе, всё бы хорошо было с самого начала.

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

Тестирования кода этого слоя в линуксовом ядре не хватает.

С чего такие выводы? Суровый энтерпрайз вродь как давно для себя протестировал и юзает в проде. Фича вродь не вчера появилась.

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

вродь

Вот именно. Я ни разу в жизни не видел чтобы кто-то это использовал. Обычно чуваки просто делают отдельные vlan’ы и фильтруют по IP.

cumvillain
() автор топика
Ответ на: комментарий от iron

Какого еще тестирования тебе не хватает?

Тестирования итогового продукта, а не спецификаций которыми его обложили. У меня такое впечатление, что ты из тех, кто проведённую работу оценивает по бюрократическим бумажкам, написанным в ходе её выполнения. Это плохой подход.

MS AD начиная с Windows 2000 Server и особых нареканий не вызывает

Нашёл на кого равняться. Я ни один виндузятный протокол без ssh-туннеля в инет не пущу.

сначала планомерно разработали в виде RFC

Опять бумажки. Вот tcp/ip разработали в виде rfc, это не мешает тому что в ядре уязвимости в его драйвере находили. Уязвимости, разумеется, в rfc специфицированы не были, это самодеятельная добавка от реализаторов.

Где ж там костыль,

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

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

Давно нашлась. При прочих равных, если не заставлять пользователя ЯП городить boilerplate и закатывать Солнце руками, возможности сделать логическую ошибку сокращаются. Факт.

Тогда надо не пайтон, а лисп.

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

Обычно чуваки просто делают отдельные vlan’ы и фильтруют по IP.

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

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

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

Дело не в некоторых, дело в том, что я NFS видел всего в двух видах: free for all и через фильтрацию по IP тем или иным способом. Шифрования я не видел ни разу.

cumvillain
() автор топика
Ответ на: комментарий от firkax

Я ни один виндузятный протокол без ssh-туннеля в инет не пущу.

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

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

Так причем здесь шифрование NFS? Тут проблема в архитектурном легаси NFS которое тащится десятилетиями. Если по религиозным убеждениям это тебя не устраивает – не юзай.

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

Шифрования я не видел ни разу.

Потому, что не сталкивался с ворклодом для которого NFS с шифрованием будет актуален.

П.С: годков 8-10 назад, в одной американском компании, с тысячами серваков под виндой и линуксом, заменили CIFS и iSCSI на шифрованный NFS и были счастливы, так как скорость доступа к стореджам существенно улучшилась и уменьшились задержки на чтениях мелких блоков. Юзался CIFS потому, что приходилось тащить кучу легаси.

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

заменили iscsi на nfs и уменьшились задержки

Прости, но не верю.

cumvillain
() автор топика
Ответ на: комментарий от iron

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

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

Так причем здесь шифрование NFS? Тут проблема в архитектурном легаси NFS которое тащится десятилетиями.

Я не знаю причём тут шифрование, это ты его зачем-то приплёл. Вот мой исходный коммент: Уязвимость в реализации NFS-сервера FreeBSD и OpenBSD (комментарий) там именно про общую костыльность. Впрочем шифрование, внедрённое в кучу костылей, доверия тоже не вызывает.

Если по религиозным убеждениям это тебя не устраивает – не юзай.

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

firkax ★★★★★
()

На моей памяти, NFS всегда был большой дырой — что в GNU/Linux, что в SUN Solaris. Не припомню, где бы были гарантированно безопасные реализации.

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