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

РЕШЕТО!

По ссылкам не ходил. Хотелось бы подробностей. Какие версии NFS затрагивает уязвимость? Я не особо в курсе, но насколько понимаю, все реализации NFS не особо далеки от референса (там типа RPC и всё такое).

P.S. Да вижу, что в BSD, но всё-таки.

OpenBSD

Тео уже публично раскаялся и выпилил поддержку NFS из системы?

на конференции по безопасности t2, проходящей в Хельсинки 18-19 апреля.

How much 1337 € + VAT 24 %

ничего так хотят за регистрацию

#

Тео уже публично раскаялся и выпилил поддержку NFS из системы?

Не помню случаев его публичных каяний.

#

это в каком смысле, «сажать в тюрьму»?

Сейчас топик наводнят специалисты по безопасности, хакеры всех цветов и векторов, после чего он будет наполнен примерами аудита, кусками безопасного кода и патчами к референсным реализациям сраказмом. :)

бздуны ещё живы?) на Free BSD помнится мне в закат её эпохи (≈2010) было написано немерено вирусни

бздуны ещё живы?) на Free BSD помнится мне в закат её эпохи (≈2010) было написано немерено вирусни

Вести из параллельной вселенной. У вас там / на riserfs или refs ставят?

В коде NFS-сервера проектов FreeBSD и OpenBSD

Что-то уже 10 комментарием и ни одного про С/С++. Слабоватенько, уважаемые форумчане.

Какие версии NFS затрагивает уязвимость?

OpenBSD умеет только третью, так что точно она. Насчет четвертой, которую умеет FreeBSD — надо ждать апреля с раскрытием деталей.

Авторы говорят, что дыра в логике и речь не про очередной сишный буфер.

Авторы говорят, что дыра в логике и речь не про очередной сишный буфер.

Когда это кого-нибудь останавливало? :)

Видать давно туда никто не заглядывал... :)

Удалённое выполнение кода из-за дыры в логике? Это как, есть логика, запускающая код из сетевых буферов, но забыли добавить проверку на авторизацию?

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

btrfs

Дело не в деньгах, а в самом числе. Отсылка к культуре: в 90’ых и начале 00, было в хакерском сленге :) (1337, L33T, L33T speak (leet — elite))

Не верю! (с)

Не будем уподобляться Тсарю.

Надо смотреть код, это очередные грабли в виде выхода за пределы буфера, use after free или ещё что-то подобное. Или тупро пролюбили в логике что-то.

От логических ошибок ни один язык не спасёт.

Никогда не доверял никаким реализациям сетевых фс (ну кроме sshfs), что нфс что самба от обеих несёт костылями и дырами. Использовал только в доверенном окружении, где и клиент и сервер полностью подконтрольны (но уже давно не использую).

Видать давно туда никто не заглядывал… :)

В код NFS? Во FreeBSD в декабре прошлого года точно что-то исправляли, так что не так уж давно. Про OpenBSD ничего сказать не могу.

Во FreeBSD при использовании WebNFS, оно сервится исключительно в read-only. В остальных случаях нужно тонко настраивать права, и если админ дурак или просто ленивая жопа, он сам себе яйца отстрелит (даже если админ — девочка). Так что использовать в доверенном окружении это единственно верный путь.

С SMB ситуация чуть иная, там есть per user шары, и если хорошо настроить, оно относительно безопасно, но я бы тоже не стал вывешивать её наружу в read-write.

sshfs это тоже костыль по сути. SFTP чуть меньший костыль (благо, оно нынче по умолчанию), но парольная аутентификация всё испортит.

От логических ошибок ни один язык не спасёт.

В какой-нибудь высокоуровневой нотации вероятность сделать логическую ошибку – меньше, чем в руками написанном маш. коде. Не так ли?

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

В nfs RPC есть. Например, автор облажался в парсинге.

Он не хитрый, он очень тупой, потому что в дефолтной инсталляции openbsd включен только ipv4 и ssh с ntpd.

Это больше до 16 осмысленно, а для взрослых - сумма в долларах.

Ну так об этом и речь.

сколько дырок не закрытых еще скажи, лоровец, пропой

Ну, значит не туда заглядывали. Бывает такое. Я, помнится, заглянул в код телнета потому как мне нужно было telnet-прокси написать для файерволла. Ну и нашел там переполнение буфера. А потом, через пару месяцев, по все новостям «пронеслася весть»: в телнете дырка! Ну вот так оно бывает.

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

В какой-нибудь высокоуровневой нотации вероятность сделать логическую ошибку – меньше, чем в руками написанном маш. коде. Не так ли?

Нашлась серебряная пуля! Надо просто переписать на питоне.

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

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

Никогда не задумывался. На то и хомячок.

Чем вам питон не угодил?

Так-то без perl и/или tcl и в середине 90-х нифига не работало.

Никогда не доверял никаким реализациям сетевых фс (ну кроме sshfs), что нфс что самба от обеих несёт костылями и дырами. Использовал только в доверенном окружении, где и клиент и сервер полностью подконтрольны (но уже давно не использую).

Отличный план, шеф! И каким образом ты предлагаешь шары организовывать?

Чем вам питон не угодил?

Почему не угодил?

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

Обычно это просто работает, только линукс со своей самбой не может.

Что именно? Я ж говорю, уточни задачу. Помойку устроить - дело нехитрое (и именно она получается в 99% случаев использования шар по независящим от ОС причинам), но если тебя устраивает помойка то и уязвимости не должны беспокоить.

Что именно? Я ж говорю, уточни задачу. Помойку устроить - дело нехитрое (и именно она получается в 99% случаев использования шар по независящим от ОС причинам), но если тебя устраивает помойка то и уязвимости не должны беспокоить.

Задача сделать так чтобы разные команды могли файлики хранить в разных местах.

Ты прикалываешься? Уточни нормально что нужно. Определение nfs я и без тебя знаю (впрочем ты даже его исковеркал).

Ты прикалываешься? Уточни нормально что нужно. Определение nfs я и без тебя знаю (впрочем ты даже его исковеркал).

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

люди хотят файлики складывать и делиться друг с другом

Вот такое без уточнений с 99% вероятностью ведёт к помойке. Если так и есть - забей на уязвимости, хуже уже не будет.

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

Мой единственный сценарий её использования был для организации синхронного состояния файлов кластера (нагрузка на диск маленькая, на проц большая). Со временем это было заменено на другие способы (код лучше синхронизировать и выкладывать через vcs, данные лучше хранить в специально отведённом месте, ну а что в эту систему не укладывается - можно и индивидуально что-то придумать).

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

Что ещё? Кто-то может придумать раздавать через шару какой-то статический контент. Опять мимо - для этих дел по-нормальному используются http-сервера.

Какой сценарий у тебя?

Вот такое без уточнений с 99% вероятностью ведёт к помойке. Если так и есть - забей на уязвимости, хуже уже не будет.

С чего бы? DFS и ролевые модели нормально решают задачу разграничения доступа.

Мой единственный сценарий её использования был для организации синхронного состояния файлов кластера (нагрузка на диск маленькая, на проц большая). Со временем это было заменено на другие способы (код лучше синхронизировать и выкладывать через vcs, данные лучше хранить в специально отведённом месте, ну а что в эту систему не укладывается - можно и индивидуально что-то придумать).

А вот это как раз лютая наркомания.

Какой сценарий у тебя?

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

про smb смешно было. same sh*t как и NFS. причём количества удобрения там и поболе будет (с учётом предыстории).

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

Какие именно люди, какие именно файлы и с какой целью? Это рабочие дела или домашние? Если первое - какая у них должность и какой рабочий процесс они этим реализуют?

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