URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 125064
[ Назад ]

Исходное сообщение
"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"

Отправлено opennews , 17-Авг-21 08:52 
В Glibc выявлена уязвимость (CVE-2021-38604), дающая возможность инициировать крах процессов в системе через отправку специально оформленного сообщения через POSIX message queues API. В дистрибутивах проблема не успела проявиться, так как присутствует только в выпуске 2.34, опубликованном две недели назад...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=55646


Содержание

Сообщения в этом обсуждении
"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 08:52 
Призываю в тред всех тех кто отписывался по поводу недавней уязвимости в стандартной библиотеке Go. Расскажите почему "это другое!"

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 08:53 
ты как с двача вышел то? а ну бырсь обратно в /s faggot

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:58 
Не раньше, чем вы расскажете стишок про безопасную сишку
*пододвигает табуретку

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 12:07 
А кто и когда топил за безопасность сишки?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:09 
Толко после поэмы про безопастный Rust.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:15 
Только после Элиады о победе языка Си, над Rust.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:26 
Историческая литература в соседнем отделе.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 08:58 
Никто не будет говорить, что "это другое". Во всех языках могут быть уязвимости, во всех процессорах могут быть уязвимости, во всех математических операциях могут быть уязвимости. Просто адепты "безопасных" языков с этим никак смириться не могут и рейдят новости о других "небезопасных" языках. Включите голову немного и исключите из цепочки человек-машина человека - тогда точно никаких узвимостей не будет, я гарантирую это! (ц)

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:24 
Ты что если перекрыть один из тысячи векторов ошибок язык мгновенно становится безопасными и весь его софт становится безопасным по определению. Кроме сторонних библиотек и стандартных библиотек на этом языке. Но это не язык виноват он же безопасный.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:54 
Ну, допустим, три четверти уязвимостей приходятся на этот один из тысячи векторов.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 10:04 
Допустим одна из тысячи уязвимостей приходится на это вектор.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 10:42 
Допустим, еще и 749 тоже. В сумме как раз 750 получается.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено another_one , 17-Авг-21 09:03 
Ага, а вы помнити seg fault?!

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:08 
Хаха, да ладно не будут)
Что же скажет Хан, Урри, Онаним, пох, нах?, стоп, последнего вроде не было...

... приводящей к разыменования указателя NULL ...
> Эпичное смузихлёбство в ретро-академической степени
> оне художнеги, оне так видют.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:49 
Им пофиг на glibc, у них systemd32.dll, в которой дыр нет.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Урри , 17-Авг-21 11:16 
Урри скажет, что рукожопы. У Урри его сишный код уже много лет не падал, хотя крутится миллионами копий в продакшене на серверах гугла.

А что?


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Онаним , 17-Авг-21 09:10 
Потому что сишечки не позиционируют себя как "безопасный езычог".

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:51 
Ну, всяко побезопаснее хруста, на котором даже за границы буфера фиг выйдешь.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 10:54 
>  Потому что сишечки не позиционируют себя как "безопасный езычог".

Так и хруст не позиционируется как супербезопасный. Он позиционируется как нормальный. Как Go, Java, Erlang и множество других, менее распространённых языков. Содержание уязвимостей не более 5% объёма.

А вот C и C++ позиционируются как ультрасупердырявые языки, состоящие из дыр на 95%, и любой нетривиальный код на них будет содержать как минимум одну дыру.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:17 
А, ну раз он позиционируется как нормальный, как и множество других, то нах он тогда нужен с его синтаксисом. Есть множество других с более вменяемым синтаксисом.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Онаним , 20-Авг-21 00:02 
Нормальный? С таким синтаксисом? Хера себе у вас нормальность.

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


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:22 
В про то что была уязвимость и твоём святом растике, ты не написал. Какой же ты смешной)

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:30 
А на раст мне пофиг - я на нем не пишу. У Го нет такого пункта в продвижении как "супербезопасный язык".
Но раз ты уже вспомнил раст, то да, на нем разыменовать NULL тоже бы не получилось.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 10:55 
> У Го нет такого пункта в продвижении как "супербезопасный язык".

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


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Dzen Python , 17-Авг-21 11:18 
Легко и просто.

Сишники, пишущие либси:
а) не орут на каждом углу, что борроу чекер и анальные ограничения вне блоков unsafe есть какая-то панацея "от всего".
б) понимают, что поломать можно даже полную ява-виртуалку без инвоков внешнего бинарного кода, была бы критическая кривизна рук.
в) просто правят баги, живущие в коде у КРУПНОГО ЫНТЫРПРАЙСА (привет, шиндошвс), на который молятся молодые хрустикофанатики, десятилетиями.

В отличие от них, молодое хрустопоколение смуззихрустиков:

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


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 11:49 
> г) ...в стандартном неткоде нашли факап, достойный первокура провинциальной россеянской ит-шараги

ну допустим...

а не проверять на NULL перед разыменованием это чей уровень?
чуваков которые пишут либу для миллиардов устройств?
или студня которого отчислили после первой сессий?
или чувака из пту который прочитал книгу "C for dummies", правда бухой и не до конца?

Это ошибка уровня перепутать педали в авто.


PS
а) это орут только упоротые сишники не знающие матчасть, поэтому в каждой теме приходится давать ссылки от чего конкретно защищает borrow checker
б) пфф, это все знаю. просто где-то это можно делать незаметно для себя и окружающих, а где-то придется постараться и написать что-то вроде mem::forget
в) вы хотя бы в теме разобрались - его не за ансейф "травили" (хаха, травили, неженка какой нашелся, может пойти поплакаться своему психиатру), а за то что он по сути насpал в коде, а сверху прикрыл ковриком чтобы видно не было.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 14:48 
>> уязвимости в стандартной библиотеке Go.
>> Go
> а) не орут на каждом углу, что борроу чекер и анальные ограничения вне блоков unsafe
> молодые хрустикофанатики, десятилетиями.
> В отличие от них, молодое хрустопоколение смуззихрустиков:

В принципе, достаточно, чтобы составить мнение о "квалификации" очередного "оналитега" (о том, что очередной Эксперд ни на сишке, ни растишке ничего не пишет, можно догадаться из контекста).

ЗЫ:
Еще пару раз напиши, кто именно истерику устраивает и в какие новости набегает, чтобы точно-точно никто не перепутал :)



"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 18:49 
> Легко и просто.
> Сишники, пишущие либси:

...

Это шикарно!!! Снимаю шляпу. Молодец, красиво и верно. Я даже себе запишу.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено freecoder , 17-Авг-21 22:55 
> в) Травит создателей своих же библиотек за "неоправданное" (по мнению ребёнка с подкатанными штанишками, естессно) использование ансейфа в критичных по времени операциях

Ну вы же ничего не знаете о той ситуации и делаете прямо противоположные реальности выводы. А я вам расскажу, что случилось: Николай написал unsafe-код в недрах библиотеки actix-web так, что появилась возможность триггерить UB из пользовательского safe-кода! И что должно было сообщество сделать, когда в самом популярном веб-фреймворке есть такое? Стали обсуждать и предлагать патчи. А Николай взял, и удалил обсуждения. Дескать, это его сервер для рекордов, он должен быть супер-быстрым и ему плевать, что пользовательский safe-код будет время от времени приводить к UB. Ну, кто-то ему в комментариях написал, что с таким отношением к unsafe и UB Rust не для него. Николай тут же взял и удалил репозиторий с проектом, а потом написал, что уходит из Open Source.

Вообще, вся эта ситуация крайне странная. Николай вел себя очень истерично, хотя дискуссия в целом была довольно мирная (есть отзеркаленные треды обсуждений, которые Николай потер). Кроме того, не надо забывать, что Николай работает в security-подразделении MS. Может быть он так и планировал - оставить бэкдор в библиотеке, которая станет стандартом де-факто в экосистеме Раста. А тут спалился. Поднял истерику, чтобы отвлечь внимание от настоящей проблемы - и это сработало. Вот вы, например, повелись на этот шум.

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


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:21 
Мне как пользователи софта вообще накласть, что дам думают сишники и иже с ними. Я вижу сегфолты, уязвимости и падения прикладнух. Если это сишники победить не могут, а я теряю данные -- я не хочу, чтобы мой софт писали на си, я не хочу, чтобы каждый божий день постили новости об очередном CVE.

От того, что кто-то передо мной кто-то непрерывно годами повторяет "халва" -- от этого у меня халва не появится.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 11:36 
Кстати, там и в самом деле другое, причем как раз еще больше _не_ в пользу сишечки и повышает в рейтинге нужности раст с го. В расте/го какие-то ленивые балбесы поленились правильно, "с точностью до буквы", стандарт закодить (или логическая ошибка бизнес-логики),а в данном случае - разыменование NULL-указателя, чего в расте в Safe-mode не сделаешь. Еще один жирный плюс в копилку раста/го. Т.е в раст-программе, при условии Safe-mode, присутствуют логические ошибки бизнес-логики, а в сишечке - и логические ошибки бизнес-логики и ошибки программирования типа этой и ей подобных, коих по статистике 70%.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 14:47 
> > Уязвимось в Glibc, позволяющая вызвать крах чужого процесса
> Расскажите почему "это другое!"

Потому что есть такое понятие как дискретный контроль доступа (DAC) и в некоторых GNU/Linux дистрибутивах, использующих технологии YAMA или CONFIG_GRKERNSEC_PROC технологии DAC распространяются на процессы в памяти и процесс не имеет доступа к процессам других пользователей, а при жестких настройках YAMA нет доступа даже к процессам того же пользователя.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:27 
Вы новость прочитали? ПРОЦЕССЫ ПАДАЮТ!!
И меня как пользователя совершенно не устраивает ситуация: я два часа набирал бесценную хайку, а тут внезапно текстовый редактор сложился без объяснений, потому что зачесалась левая пятка правой ноги.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 18-Авг-21 01:32 
Го это си для вебмакак. Они одинаковы.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 08:52 
Лол, хорошо что успеши обнаружить

арчегосподин с 2.33 версия гну библеотек


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:05 
> успеши

так торопился упомянуть любимый рачик, что и на подсветку орфографии не обратил внимание? лол

з.ы. вижу корень "арч" — сразу минусую


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:09 
Не спал долго просто, а што? чем тебе рач не нравиться?

ниасилил, да?


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено макпыф , 17-Авг-21 09:16 
возможно не осилить pacman -S base ?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:21 
Исходя из того количетсво пользователей что сидят на бомжару, думаю что да

мимоАрче+и3вмГосподин


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Michael Shigorin , 17-Авг-21 14:08 
> чем тебе рач не нравиться?

Мне вот -- невменяемостью рачешкольников любого возраста, пытающихся впарить ЭТО невзирая ни на что и тем напоминающих когда иеговистов, когда канадских мальчиков или MLM-щиков.

А вики у арча хорошая, молодцы (пока гентушники свою непроэтсамое, хорошая была у них). :-)


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 14:51 
>  (пока гентушники свою непроэтсамое, хорошая была у них). :-)

Гентушникам не только вики потеряли, а и сами цели дистра поменяли. Генто сегодня и 10 лет назад это две большие разницы.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 19:02 
Михаил, раб божий, Вы то, что этом треде потеряли. Лучше идите домой.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 21:42 
Даю руб за два, что михаэль один из срущих анонимов. Аргументация соответствующего впопеннетчикам уровня.
Сиди на своем уникальном альте и обмазывайся духоскрепными эльбрусами.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноньимъ , 17-Авг-21 23:52 
Я бы то же обмазывался бы будь они у меня.
Архитектура интересная, и духовная.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено муу , 20-Авг-21 19:12 
а вам мне напоминает некого свидетеля альта который тут во всех трэдах по поводу и без оный альт упоминает?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено анонн , 17-Авг-21 14:51 
> чем тебе рач не нравиться?

Первым пунктом из свода правил Арчеводов: "Сообщи всем, что у тебя Арч!"


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Какаянахренразница , 17-Авг-21 08:56 
Пытались пофиксить одну дыру и в процессе создали другую побольше. Это бывает. Сам так делал.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:29 
Ктулху фтанг!

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Stanislav , 17-Авг-21 08:58 
Мда...
"Поспешное исправление ошибки - лучший способ сделать новую."

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:33 
Ну да, not a bug, конечно, лучше.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено макпыф , 17-Авг-21 09:24 
интересно, будут ли они делать релиз с фиксом?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:30 
Читайте внимательней новость. Уже успели опубликовать, отозвать, в релизы не попадёт.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено макпыф , 18-Авг-21 19:02 
что отозвать?

> присутствует в выпуске 2.34

P.S. У меня кстати этот выпуск


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 23:37 
> что отозвать?
>> присутствует в выпуске 2.34
> P.S. У меня кстати этот выпуск

Значит не надо неофициальные репы в список автообновления добавлять.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено макпыф , 19-Авг-21 08:34 
Вы о чем? у меня на LFS ни каких репов нету. И тем более автообновления



"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 19-Авг-21 09:13 
> Вы о чем? у меня на LFS ни каких репов нету. И
> тем более автообновления

Тогда указанная версия к вам не могла попасть. Что-то вы путаете.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено макпыф , 19-Авг-21 11:24 
Это вы что то путаете.

Она попала также как и все пакеты. ./configure make make install


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 19-Авг-21 11:36 
> Это вы что то путаете.
> Она попала также как и все пакеты. ./configure make make install

#яснопонятно.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Какаянахренразница , 19-Авг-21 19:49 
> у меня на LFS

Резко зауважал.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Разбойник , 17-Авг-21 09:30 
Используйте musl дистрибутивы и будет вам щастье.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено hefenud , 17-Авг-21 09:46 
Ты сам пробовал их использовать? Они тормозят, как удолбанный джа-будда. Ради интереса пробовал Void и Alpine ставить в качестве десктопных в виртуалку. Вот Ubuntu/Debian в такой же виртуалке прекрасно работает, а муслевые тормозят, что капец. И это я молчу про то, что далеко не всякий софт у тебя вообще в них заведется

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:47 
Попробуй поставить jemalloc и добавить ее LD_PRELOAD.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено hefenud , 17-Авг-21 12:01 
«А вы на шкаф залезьте!» старый анекдот
Ну и смысл тогда юзать musl, если сверху надо обмазываться костылями?

Пусть себе живет в OpenWRT(если они с него не слезли, не помню уже), а на десктопе останусь на нормальных дистрах с glibc


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Разбойник , 17-Авг-21 10:04 
Брехун, нормально они работают.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено YetAnotherOnanym , 17-Авг-21 10:22 
Смотря что считать "нормальной работой". Лично когда-то наступил на баг, когда некий умник завязался на функцию из внутренностей glibc, вместо официально документированной. А в мусле её не было. Вина на авторе прикладухи, но не все готовы копаться в исходниках. Под муслом не работает - виноват мусл, вот и вся логика.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Разбойник , 17-Авг-21 10:45 
У меня под Alpine работает всё, что только можно: сервера, почтовики, базы данных, докеры. Да проще сказать, что там не работает. А не работает там только проприетарщина и говнософт по типу системГ. Вот, собственно, и всё.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 10:51 
ЛПП, системда отлично работает с musl, если отключить NSS-специфичные фишки.
И, кстати, что больше проприетарщина - системда под LGPL, или musl под MIT?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Разбойник , 17-Авг-21 10:56 
Не работает.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:39 
Ответ КО: Проприетарщина под EULA.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 11:59 
Извините за оффтоп. Раз у Вас так много на Alpine работает, значит знаете ее вдоль и поперек, со всеми прибабахами и возможно сталкивались с одной мелкой проблемой. Нужен совет. Не троллю, реально нужно, столкнулся. Проблема возникает при завершении работы системы. Для размонтирования SMB-шары там в скрипте netmount (/etc/init.d/netmount), засунутого в запуск в уровень default, в функции остановки системы выполняется команда:

umount -a -O _netdev

Ну, типа размонтировать все файловые системы, которые завязаны на сеть (_netdev).
Так вот, выбивает в этом месте ошибку, про неверный флаг -O. Гугление дало ответ, что вроде как busybox не поддерживает этот флаг (забавно, как это мэйнтейнеры такого не ловили, там же все сетевые ФС аффектятся). Временно, как залипуху, убрал из строчки этот флаг вместе с _netdev и заменил на что-то типа "... -t smb(или cifs),nfs,...", вроде отрабатывает без ошибок, но хотелось бы правильного решения. Сталкивались?


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Разбойник , 17-Авг-21 13:00 
Я очень давно не использовал самба, на алпайн вообще ни разу. Но вообще в твоей проблеме нет ничего удивительного, ведь линукс это тот ещё Франкенштейн, ослеплённый из говна и палок. В любом дистрибутиве что-то да не работает, не совместимо, забагованно и тд.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 14:40 
> Я очень давно не использовал самба, на алпайн вообще ни разу

А другие сетевые ФС? Вроде как этот случай относится ко всем "автомонтируемым" сетевым ФС, в том числе, предполагаю, и к NFS. Вы не использовали в алпайне монтируемые при запуске сетевые ФС?
Команда "umount -a ..." размонтирует все ФС, которые указаны в /etc/mtab (кроме корневой?), а опция "-O _netdev" уточняет что размонтировать надо не все, а только те ФС, которые в fstab имеют опцию "_netdev" (зависимость от сети), которая (опция) означает, что при запуске системы монтироваться эта ФС должна после поднятия сети (размонтируется, очевидно, в обратном порядке). Полагаю, что любая автомонтируемая в алпайне сетевая ФС, наверное и NFS, должна иметь эту опцию.

Ну, раз не использовали, тогда проехали.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Разбойник , 17-Авг-21 14:57 
С NFS подобных проблем не наблюдалось.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 16:44 
Спасибо

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено дохтурЛол , 17-Авг-21 13:21 
Узнайте от какого пакета у вас umount: https://pkgs.alpinelinux.org/contents?file=umount&path=&name... (это поиск для edge, у вас может стабильный релиз).

Раз вы почему-то пишете про busybox, то попробуйте вызвать команду не как `umount -a -O _netdev`, а как `\umount -a -O _netdev`.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 14:12 
У меня не edge, у меня стабильная пакетная база (3.14, но та же фигня была и в 3.13 кажись). Там только два пакета:
util-linux
util-linux-bash-completion

что относится, как я понимаю, к одной "логически связанной" группе пакетов (типа как в пакетах "aria2","aria2-bash-completion","aria2-daemon","aria2-doc"... всё связано с aria2).
Так что выходит один-единственный пакет - util-linux. Вероятно, стандартный для Alpine.

> Раз вы почему-то пишете про busybox

Это пишет тот, кто сталкивался с этой проблемой (и она, если я правильно понял, вроде как осталась незакрытой) и википедия: "Alpine Linux —...Основан на musl и BusyBox,..."

> то попробуйте вызвать команду

так это я не ручками вызываю, это в стандартном скрипте netmount стандартного пакета (системы инициализации) openrc. Я предполагал что человек выше с большущим опытом работы наверняка сталкивался с этим (ведь это все монтируемые сетевые ФС тогда "поломаны", а не только SMB) и имеет какое-то стандартное, правильное, решение, а не ручками ломать стандартный скрипт системы инициализации.
А если ручками ломать, то я уже и так поломал. Сейчас не могу проверить, но предложение вызывает удивление - вызов команды внутри тех кавычек запустит что-то другое, что поддерживает  флаг "-O"?

Сейчас еще раз поискал. Ошибка, если я правильно понимаю, открыта 2 года назад и до сих пор не закрыта:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/9923


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено дохтурЛол , 17-Авг-21 19:00 
Раз релиз - значит и правда util-linux.
Чтоб убедиться, что точно не busybox - посмотрите что вернёт `ls -lash $(which umount)`.
`` - это моё обрамление дословных команд для запуска.
Если команда выше не покажет, что umount на самом деле не бинарь от пакета выше, а мягкая ссылка на бизибокс - тогда надо просто это исправить.
А `\umount` - это защита от алиасов, вряд ли защитит от мягкой ссылки на бизибокс.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 10:47 
Обычно люди просто предполагают, что malloc() работает быстро. Это так для glibc, но совсем не так для musl. Поэтому, если нужна хоть какая-то производительность при работе с памятью на musl - просто берём язык с собственным менеджером памяти, который практически не зависит от скорости стандартного аллокатора (Java, Go). Ну или сразу берём в зависимости jemalloc и линкуем с ним.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Dzen Python , 17-Авг-21 11:27 
Зачем тогда нужна стандартная библиотека musl, если пользоваться ей все равно нельзя и нужно линковать внешний jemalloc?

Бред. Как хорошо, что я даже не смотрю на все эти хипстоподелки.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:32 
Так хипстоподелку впихнули, например, в OpenWRT.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:46 
musl известен тем, что там даже в printf() ухитрились переполнение сделать.

Про тормозной аллокатор вообще молчу.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 15:54 
Почему "даже" ? Принтф довольно сложная функция.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:33 
Этой довольно сложной функции уже поди лет 40. И до сих пор допускать в реализации её ошибки -- это уже за гранью добра и зла.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 09:53 
ухты, релиз новой версии уязвимости.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Ананоним , 17-Авг-21 10:01 
Я ж говорил, старые исправили, новые добавили. Главная цель кодирования. Зато "кот" всегда нужен.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено freecoder , 17-Авг-21 10:58 
Мда, печально. Но вот от таких ошибок как раз Rust спасает: по-умолчанию нет никаких NULL, если нужно отсутствие - используешь Option, который типобезопасен и проверяется компилятором. Конечно, в unsafe при желании можно что угодно разыменовать, но на то он и unsafe, чтобы покрывать 0-1% кода, а не 100%.


$ git clone https://github.com/rust-lang/rust
$ cd rust
$ cargo count --separator , --unsafe-statistics
Gathering information...
         Language    Files  Lines    Blanks  Comments  Code     Unsafe (%)
         --------    -----  -----    ------  --------  ----     ----------
         Rust        6,018  528,510  66,984  133,698   327,792  3,163 (0.96%)
         C           54     9,962    1,445   1,492     7,025    7,025 (100.00%)
         CSS         4      1,266    149     52        1,065    
         JavaScript  4      1,118    131     166       821      
         Python      31     4,797    843     585       3,369    
         C Header    13     1,865    284     585       996      996 (100.00%)
         C++         4      1,611    185     81        1,345    1,345 (100.00%)
         --------    -----  -----    ------  --------  ----     ----------
Totals:              6,128  549,129  70,021  136,659   342,413  12,529 (3.66%)


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним зеленый , 17-Авг-21 11:12 
Ансейф в расте очень сложен к проверке корректности. Обычно если ты пишешь ансейф значит пытаешься обойти компилятор и тут закрадываются комплексные ошибки. Может их всего и 1% в коде, но ревьюить их надо как будто это 10%

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Gogi , 17-Авг-21 12:25 
Ну спасает твой раст... а в C# их вообще нет! Будем дальше ржавное Г****вно проталкивать??

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:36 
Свистишь анон. Есть, проверено лично.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:29 
MISRA спасёт, а не этот ваш Хруст.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 14:22 
Кто не хочет гуглить про это мисру - это просто стандарт-пожелание в стиле "Просто не пиши с UB и все. А еще не забывай про статический анализ"

Как глаза мне открыли. Молодцы парни. (сарказм)


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:37 
Ага. Расскажи это от десятка до сотни трупов на кладбище, которые рассекали на Тойоте Короле.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:40 
Может ошибка вообще в том, что он и не должен быть NULL, но по какой-то причине он им стал и часть кода, которая посыпалась, этого и не ожидала. Чем вам поможет в данном случае safe/unsafe, кроме как только замедлит код проверками того, что и не нужно проверять?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Хан , 17-Авг-21 15:17 
ОС/проц не будет разбираться что за лох по ту сторону экрана разыменовывает null pointer просто отправит ее в /dev/null с сообщение в консоли RTFM

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено freecoder , 17-Авг-21 22:29 
В Rust по-умолчанию все инициализировано и не NULL. Если хочется NULL - используется Option, и тогда да, компилятор потребует вставить проверки при использовании. Но точно также Сишный код  должен будет иметь проверки, но компилятор не подскажет где. И нужно будет вставлять лишние проверки, потому что статическими средствами языка невозможно выразить того факта, что объект никогда не должен быть NULL.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 18:41 
Печально что кто-то думает что для того чтобы не делать таких ошибок надо брать какой-то rust.

Для этого вполне достаточно нормального C++ и никакой rust не нужен. И синтаксис нормальный и ошибок таких не будет. И этому уже 100 лет в обед как в современных плюсах этого нет.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:36 
За любое использование unsafe надо избивать палками до посинения. А после этого -- уволнять.
На практике unsafe в го начиная с 2014 года не использовал ни разу, потому что это крест сразу на всём безопасном коде.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено freecoder , 18-Авг-21 22:13 
В Rust принят другой подход: используя unsafe-блок программист должен сам позаботиться о безопасности кода и о том, что никаких небезопасных операций не просочилось в safe часть языка. В открытых проектах обычно обязательно рядом с unsafe-блокам пишут комментарий с меткой SAFETY, в котором разъясняется, почему именно такое использование небезопасных операций в данном случае безопасно.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 23:39 
> В Rust принят другой подход: используя unsafe-блок программист должен сам позаботиться
> о безопасности кода и о том, что никаких небезопасных операций не
> просочилось в safe часть языка. В открытых проектах обычно обязательно рядом
> с unsafe-блокам пишут комментарий с меткой SAFETY, в котором разъясняется, почему
> именно такое использование небезопасных операций в данном случае безопасно.

Это вредная практика. Безопасность кода должна быть доказана. Программист -- это тупое ленивое животное априрори допускающее ошибки. Не может безопасности на 95%. Либо она 100%, либо 0.
Сегодня хак работает, а завтра поменялся компилятор или платформа и хак внезапно становится брешью в пол забора.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено freecoder , 19-Авг-21 11:54 
К сожалению со сторонниками "черное-белое и никаких оттенков" спорить бесполезно. Вас послушаешь, так все равно, 1 уязвимость в программе или 100.

100% безопасность вообще ничто обеспечить не может, как и 100% здоровье. А значит можно "курить, бухать, жрать таблетки - и пох.", я понял вашу идеологию.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 19-Авг-21 13:42 
> К сожалению со сторонниками "черное-белое и никаких оттенков" спорить бесполезно. Вас послушаешь,
> так все равно, 1 уязвимость в программе или 100.
> 100% безопасность вообще ничто обеспечить не может, как и 100% здоровье. А
> значит можно "курить, бухать, жрать таблетки - и пох.", я понял
> вашу идеологию.

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

Вы ни черта не поняли из того, что я написал. Если самолёт не прошёл сертификацию -- его нельзя пускать в производство. Если лекарства не прошли клинические испытания -- их нельзя давать людям. Но это не гарантирует, что конкретный сертифицированный самолёт не упадёт, а конкретное лицензированное лекарство у конкретного человека не вызовет анафилактический шок. Именно это я вам  и пытаюсь объяснить: 100% решение может быть, но его априрори надо ДОКАЗЫВАТЬ. Пока не доказано -- оно никак не может быть безопасным/надёжным/гарантированным. В отношении Раста это означает: никакой код код не может на Расте считаться достаточно надёжным, пока это не доказано. Тем более, когда присутствуют блоки unsafe.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 21-Авг-21 12:21 
>Если лекарства не прошли клинические испытания -- их нельзя давать людям.

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


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 24-Авг-21 09:12 
>>Если лекарства не прошли клинические испытания -- их нельзя давать людям.
> Ты это можешь сказать тем, кто продвигает российскую вакцину? Или рабское сознание
> не позволяет?

Вы меня с кем-то путаете, уважаемый аноним.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено freecoder , 23-Авг-21 16:37 
Вот вам более понятный пример: вы доказываете теорему. При этом ссылаетесь на другие теоремы, уже доказанные, и в процессе доказательства еще выделяете леммы, которые доказываете отдельно. Так вот, есть разница, доказано ли 95% утверждений вашей теоремы или только 5%. Вы этой разницы не видите, но она существенна: зная, что леммы и теоремы, на которые ссылается данная, уже доказаны, вам остается проверить (доказать корректность) только оставшиеся 5% рассуждений, а не доказывать вообще все, что входит в теорему, чего вы в общем случае сделать просто физически не сможете.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 24-Авг-21 09:15 
> а не доказывать вообще все, что входит в теорему, чего вы
> в общем случае сделать просто физически не сможете.

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

Вот вам пример, на пальцах показывающий, что всё, что вы написали -- чушь. Есть в математике число "пи". Человечество научилось выражать эту вполне конкретную математическую величину в виде символа "пи". Попробуйте на практике с такой же математической точностью выразить символ "пи" в двоичном представлении. Вперде!


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 11:28 
Лучшее - враг хорошего

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Zenitur , 17-Авг-21 11:55 
Это американские шпионы добавили, чтобы очернить наш любимый Glibc, когда тот решил стать более независимым.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:27 
Вот, как раз, наоборот, он решил стать более зависимым от копрорастов.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Gogi , 17-Авг-21 12:24 
Вот и выросло "поколение ЕГЭ", пишущее программы!

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 13:23 
Среди разработчиков Glibc есть хоть один россиянин?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Michael Shigorin , 17-Авг-21 14:17 
Выпустивший https://www.opennet.me/opennews/art.shtml?num=48009 с час как зашёл в офис, пообщались с ещё одним участником разработки glibc, ну а третий попозже обычно приходит.
git clone https://sourceware.org/git/glibc.git
cd glibc
git checkout release/2.34/master
git log --author=@altlinux.org | grep ^Author | sort | uniq -c
     55 Author: Dmitry V. Levin <ldv@altlinux.org>
      3 Author: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
      1 Author: Vitaly Chikunov <vt@altlinux.org>


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Microsoft GNU Assembly , 17-Авг-21 14:50 
они, конечно же, придумали как кардинально изменить си-туацию? даю хинт: Dlang

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 18:39 
> они, конечно же, придумали как кардинально изменить си-туацию? даю хинт: Dlang

Даю правильный хинт: выкидываем весь этот треш в виде go, rust, dlang и прочее и начинаем читать книжки.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 19-Авг-21 12:01 
И кто заплатит за чтение книжек? Заказчику надо здесь и сейчас, потом следующую фичу и побольше и потратить поменьше. Пока ты там читаешь книжки, на Го уже написали три стартапа, два из которых уже закрылись, а ты все еще читаешь.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено joda , 17-Авг-21 15:01 
Надо полагать, что следующее исправление приведёт к ещё большему упрощению краха чужих процессов. ;-))

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 15:59 
Вангую, что абсолютное большинство программистов вообще почти ничерта не знает. И это нормально, потому что у большинства людей есть семья, друзья, хобби - в общем, жизнь. Потому и возникают эксперименты, вроде Rust - чтобы спасать время и личную жизнь программистов, ну или хотя бы попытаться это сделать. Это здорово, что есть люди, готовые всю свою жизнь и время посвятить узкой специализации, но их мало, все такими быть не обязаны и все экономические потребости общества эти люди грудью не закроют.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Хан , 17-Авг-21 16:31 
Если не хочешь копаться в особенностях процессора и оси то не стоит связываться с низкоуровневыми языками типа C/C++

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 23:50 
>семья, друзья, хобби

если у меня ничего вышеперечисленного нет - могу ли я стать хорошим системным программистом?


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 18-Авг-21 05:28 
Это необходимое условие, но недостаточное.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 18-Авг-21 08:33 
Программист это что-то врожденное.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 17-Авг-21 16:08 
Зато крестовики уже присобачили борроу чеккер к сиплюсплюшечке https://www.youtube.com/watch?v=Lj1GppqNr8c включили c++ core check из visual studio поигрались и забыли как страшный сон.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Хан , 17-Авг-21 16:32 
Когда в появится в стандарте C++ тогда и говори

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 18-Авг-21 08:33 
О чем с тобой говорить с хрустиком? Ты сначала напиши что-нибудь продакшн реди.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 18-Авг-21 12:22 
Что плохого в borrow checker'e?

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 19-Авг-21 11:59 
Делает мозги почем зря.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Аноним , 18-Авг-21 08:59 
Хм. А в Fedora пока 2.33. Не спешат в таких вопросах.

"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено Брат Анон , 18-Авг-21 12:41 
> Хм. А в Fedora пока 2.33. Не спешат в таких вопросах.

Читайте внимательно новость. Релиз уже отозван, ни в дин дистр это не попадёт по определению.


"Уязвимось в Glibc, позволяющая вызвать крах чужого процесса"
Отправлено village_coder , 20-Авг-21 16:51 
Чужих процессов не бывает...