Динамический загрузчик ld.so, входящий в состав OpenBSD, при определённых условиях может для SUID/SGID-приложения оставить переменную окружения LD_LIBRARY_PATH и таким образом позволить загрузить сторонний код в контексте процесса, выполняемого с повышенными привилегиями. Патчи с исправлением уязвимости доступны для релизов 6.5 и 6.6. Бинарные патчи (syspatch) для платформ amd64, i386 и arm64 уже запущены в производство и должны быть доступны для загрузки к моменту публикации данной новости...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52012
Вот, пытливые умы :)47645
Что-то OpenBSD в последнее время везет на баги. При том - довольно детские. Вгруз своих либ привилегированым процессам - баян похлеще GET /site/../../../etc/passwd.
Что значит «везёт на баги»? Для того аудит и проводится, чтобы их находить.Если вы прочитаете внимательно описание уязвимости, то поймёте, что простое выставление LD_LIBRARY_PATH не позволяет «вгрузить свою либу», а возникает в ситуации, которая в нормальных условиях практически нереальна. Не удивительно, что проблему нашли только в результате аудита, а не прогона тестов.
Аудит то проводится, но судя по его результатам - OpenBSD до этого момента был всего лишь неуловимым Джо. Недавно рядом была вообще совершенно детская проблема с вгрузкой либы привилегированному процессу. Даже попсовый Linux додумался такое зарубить на корню, много лет назад.
> Аудит то проводится, но судя по его результатам - OpenBSD до этого
> момента был всего лишь неуловимым Джо. Недавно рядом была вообще совершенно
> детская проблема с вгрузкой либы привилегированному процессу. Даже попсовый Linux додумался
> такое зарубить на корню, много лет назад.OpenBSD это рубил тоже много лет. Потом, в 2003 был сделан один не очень аккуратный коммит, который позволил при выполнении определённых условий обойти эту защиту. В том же Linux (точнее, ld.so) были проблемы в той же области месте, хотя и другого рода, ссылка на новость об этом была любезно приложена редактором сайта. Но вы ж читать и восприниматься реальную информацию не хотите, для вас всё устроено просто и очевидно. :(
Опенок уже не торт?!
Наоборот, аудит за аудитом.
Где можно найти новости про этот аудит?
В блоге Qualys: https://blog.qualys.com/ .Про данную уязвимость пока что официального анонса от них не было, но был про пачку недавно: https://www.opennet.dev/opennews/art.shtml?num=51979 .
Думаю, когда (если) они закончат, то сделают сводный пресс-релиз по этому поводу. Пока что же ваш покорный слуга и прочие рабы клавиатуры делают своё маленькое дело — оперативно уведомляют заинтересованную общественность, чтобы всем спокойнее спалось. :)
Общественность признательна.
Что определяет начало проведение аудита?
Они это делают по расписанию или есть какие иные критерии?
Это делает Qualys, по своей инициативе. Их профит — репутация и авторитет («мы умеем находить баги»). Так что внешний аудит — от случая к случаю... Хотя, может, когда-нибудь OpenBSD Foundation займётся спонсированием в этом плане. :)Внутренний же аудит проводится по мере появления новых инструментов, либо нахождения новых предположительно типовых проблем; текущий случай, насколько понимаю, к таковым не относится... хотя намерение проверить другие интересные места в ld.so лично у меня руки чешутся.
Тео стареет однако.
Этот код там с 2013 года.
— Ну дык, Вовочка! Про кого мы все время песенки поем, кого я вам на картинке показывала?Вовочка застывает в священном экстазе и изрекает:
— Так вот ты какой, безопасный BSD...
Конечно, ведь по-настоящему безопасный — это тот, про кого никто не знает, что он опасный. ;)
Не, я конечно всё понимаю, но у мсов абсолютный эпик за размытыми формулировками ченджлога прячется.
Где вы увидели слово «critical» в данном случае? Я пока что живого эксплоита не видел.Qualys проводит аудит кодовой базы OpenBSD, как до этого делали другие люди не раз. Естественно, при этом повышается количество багрепортов. А там, где аудит не проводится, багрепортов тоже нет, логично.
UPDATE: Выпущен официальный анонс, PoC таки есть и уверенно работает (проверил на -CURRENT).
Вы зря пытаетесь что-то отвечать на чисто троллический коммент.Естественно, что на опеннете нет новостей про уязвимости выни. Никто в здравом уме просто так по щелчку не перейдет c бсд на вынь, если уж и припекет, то скорее на линукс.
Человек просто пытается создать видимость, что кто-то там переходит на вин, хотя вокруг происходит ровно наоборот.
Вынь это поддержка легаси и как только появляется возможность от нее избавиться, то тут же это и делается и на серверах в первую очередь.
Завтра я иду к своему гендиректору менять 100500 инстансов выни на линь или бсд, ибо как мы видим, они до сих пор не залатали свой RDP.
https://portal.msrc.microsoft.com/en-US/security-guidance/ad...
Другие уже давно залатали https://0patch.com/patches.html
Так по ссылке же заплатки, что не так?
На XP и Vista даже выпустили https://support.microsoft.com/en-us/help/4500705/customer-gu...
Да все нормально, то был сарказм. Я не пользуюсь продуктами мс.RDP уже сколько лет и до сих пор падают такие шляпы, как и впрочем другие немалые дыры. И ввиду того, что разработка ведется за закрытими дверями вполне возможно, что мы видим вершину айсберга. Это к вопросу "о целесообразности перехода на вынь".
Также остается открытым вопрос о том, если очередной апдейт вам покажет потом синий экран смерти. (Да, они конечно все тестируют, но мы то знаем что окончательное тестирование происходит на конечном железе). Так как потом чинить бинарный блоб? Можно ли вообще рядом ставить прозрачность обновления линь и бсд систем с бинарной помойкой?
Пффф.. не защищаю "вынь", но и "линь" знаете ли.. Один Heartbleed чего стоит.
А поводу апдейта и синих экранов - линуксов "упавших" после апдейта не видели?
По правде говоря не видел ни разу, чтобы линукс намертво умирал после апдейта. Тем более большинство апдейтов не связаны с ядром, ну и что важно - ты видишь что апдейт за собой потянет и какие могут быть последствия. Сбои были, но всегда находилось решение, тк понятно как линь работает и система приспособлена для ручного вмешательства.Я тоже ничего не защищаю, также ни за и ни против. Это всего лишь инструменты. Просто предпочитаю использовать то, что более поддается контролю.
Вы не видели, а я чинил. Иногда проще было переустановить, иногда достаточно было объяснить загрузчику, что он не прав. Но бывало. Как и со многими другими ОС, с которыми работал (как по по своему выбору, так и после «помоги, пожалуйста»).С OpenBSD один раз тоже было, да — там был сам виноват, release notes не просто так пишут. :)
> Пффф.. не защищаю "вынь", но и "линь" знаете ли.. Один Heartbleed чего стоит.Интересно каким боком heartbleed к линю? Openssl вообще сторонняя библиотека, используется всеми кому не лень, и под винь, и под линь, и под много чего еще, типа макосей, бсд и даже неверное каких-нибудь гаек и реактосов.
Смелое решение, анон. Но новую жизнь лучше начинать не с вечера, а с утра!
Если подумать, то над нашей страной никогда не заходит солнце - когда в Каленинграде вечер, на Сахалине утро. Посему, неведая о географическом положении опонента нестоит думать о том, что он в соседнем доме :)
Настрой автообновление в OpenBSD.
Но "баги", которые по просьбе NSA, она обновлять не будет.
Не баг, а фича. И вообще, мы вам код не дадим.
Если ты будешь ковырять в правой ноздре указательным пальцем левой руки, а правую руку перекинешь через голову и будешь чесать мизинцем в левом ухе, стоя на одной ноге, а вторую вытянув назад, то, если автобус резко затормозит, ты можешь потерять равновесие и упасть.
Моя любимая поза, как же так! Звучит зело опасно, падение будет очень болезненным!А такие проблемы легко и непринуждённо эксплуатируются, никто и не ждёт что пользователь сам с ними столкнётся.
Проблема в том, что в случае с OpenBSD от твоего поведения ничего не зависит. Если в твоей системе есть непривилегированный пользователи, они могут воспользоваться уязвимостью, независимо от того, чешешь ты ухо мизинцем или нет.
Кстати, а в Linux использование LD_PRELOAD и LD_LIBRARY_PATH уже полностью безопасно? Как-то много пугалок было. А то ответ на вопрос Is there any way to block LD_PRELOAD and LD_LIBRARY_PATH неюзабелен. Как их просто отключить?
Боюсь, что их отключение может оказаться чревато самыми неожиданными поломками привычного софта. Так что на это вряд ли кто пойдёт, и единственный способ отключить эти механизмы я вижу в правке исходников ld.so. :-\ Благо что найти в коде данные строчки и аккуратно их поправить должно быть под силу даже начинающему наСильнику.Ну а насчёт «уже полностью безопасно» — гарантию даст только страховой полис. :)
> Кстати, а в Linux использование LD_PRELOAD и LD_LIBRARY_PATH уже полностью безопасно? Как-то много пугалок было. А то ответ на вопрос Is there any way to block LD_PRELOAD and LD_LIBRARY_PATH неюзабелен. Как их просто отключить?Есть вот такой патчик на glibc, вычищающий переменные окружения, например, для suid-ных процессов (но не только для них), но почему-то его применяют только в Альт и Owl:
http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=comm...
Пасиба! Интересно...
https://www.openwall.com/lists/oss-security/2019/12/11/9
Подробное описание уязвимости
Уже отправил корректировку новости. :) Там ещё и рабочий PoC приложен. Что-то я сначала не сообразил, что объём доступной памяти можно искусственно точно ограничить через setrlimit()...
Only two remote holes in the default install, in a heck of a long time!Сказки на ночь
Это не remote hole, это local root. Тоже неприятно, но всё же другого сорта и менее опасно.
К тому же, для эксплуатации уязвимости нужно сожрать всю память, да так точно, чтобы обломилась именно _dl_split_path(), не раньше.
Предложенный эксплоит — https://www.openwall.com/lists/oss-security/2019/12/11/9 — изящно решает эту проблему установкой лимита на объём доступной памяти через setrlimit(2).
Извините, тормознул.
Кого ж винить, что вы так и не научились читать?
В опенке дыры может и есть, но не в таком количестве как в линуксах...
Кто-то всерьёз взялся за ненужно, похоже.