Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в pam_oath, позволяющая получить права root в системе"	+/–
Сообщение от opennews (??), 04-Окт-24, 22:27
В PAM-модуле pam_oath, входящем в состав пакета oath-toolkit и применяемого при двухфакторной аутентификации с использованием одноразовых паролей (OTP), выявлена уязвимость (CVE-2024-47191), позволяющая непривилегированному пользователю получить root-доступ в системе... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61987
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

10. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
Сообщение от Аноним (10), 04-Окт-24, 22:49
> после чего атакующий сможет отредактировать файл /etc/shadow и записать в него новые параметры входа для учётной записи root. а там не надо делать что-то на подобии pwd_mkdb?
Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+1 +/–
	Сообщение от Аноним (12), 04-Окт-24, 23:03
	Это просто текстовый файл. pwd_mkdb - это просто обёртка в стандартной библиотеке. Можно читать самостоятельно и самостоятельно парсить, там даже формат очень простой.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (10), 05-Окт-24, 02:48
	> Это просто текстовый файл. да, это просто пользовательский текстовый файл, а не какой-то там системный "важный" файл.
	Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+3 +/–
Сообщение от Аноним (12), 04-Окт-24, 23:09
Фикс, похоже, заключается в том, чтобы добавить O_EXCL помимо O_CREAT в open(). По POSIX, комбинация O_EXCL | O_CREAT должна выдать ошибку, если путь уже существует, даже если это симлинк.
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+1 +/–
Сообщение от Аноним (17), 05-Окт-24, 00:49
1) а что, система(pam_oath) даже не проверяет содержимое файла парсингом, тупо копирует неизвестные данные "справа налево" с сохранением атрибутов файла? 2) почему pam_oath имеет доступ к файлу /etc/shadow (да и вообще в /etc/) ? 3) если бы подобное реализовал я, ну как минимум из под ограниченного пользователя подобное(службы) надо создавать. А так - похоже на лютый студенческий скрипто-костылинг.
Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+1 +/–
	Сообщение от мяв (?), 05-Окт-24, 01:17
	1) даже, если б проверяла, что мешает пропихнуть файл в промежуток между проверкой и перемещением? ничего. довольно, к слову, попудю́ 2) потому что службы PAM'у нужен рут. он просто грузит .so-файлы модулей. 3) похоже на лютое студенческое незнание матчасти!
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+1 +/–
	Сообщение от мяв (?), 05-Окт-24, 01:18
	тьфу, забыла дописать) 1) ... довольно популярная ошибка. даже в ман'ах о ней пишут.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+2 +/–
	Сообщение от Аноним (-), 05-Окт-24, 02:08
	> 1) даже, если б проверяла, что мешает пропихнуть файл в промежуток между > проверкой и перемещением? ничего. довольно, к слову, попудю́ Это называется TOCTOU если что. (Time Of Check VS Time Of Use). Но тут до этого не дошло и факап проще оказался.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	46. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+1 +/–
	Сообщение от Аноним (17), 05-Окт-24, 12:37
	Вы не показали свой способ реализации(что бы избежать подобной ошибки). Я, хоть что то предложил, хоть и не программист. (критикуешь - предлагай то, что считаешь правильным)
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

19. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
Сообщение от Аноним (19), 05-Окт-24, 00:55
самое забавное что за последний год я что-то не припомню чистой проьблемы с памятью, вечно то ресур не освободят какой то проверку не проведут то файл нулями забъют (привет синие экраны на винде во всем мире). А молятся все на раст... и плавать что это еще 1 компилятор нестабильный к тому же. Без настолько провереных десятилетиями статических анализаторов и готового парка библиотек.
Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+2 +/–
	Сообщение от мяв (?), 05-Окт-24, 01:23
	причем, единый компилятор. вместо того, что б написать стандарт и реализовать, они реалтзуют и описывают. но продвигают, как "стандарт". поттеринг так же делал с его uapi.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	–4 +/–
	Сообщение от Самый Лучший Гусь (?), 05-Окт-24, 01:27
	Так компилятор и есть стандарт просто реальзованый в настоящем коде. Куда лучше чем у С/С++
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (-), 05-Окт-24, 01:54
	> Так компилятор и есть стандарт просто реальзованый в настоящем коде. Куда лучше чем у С/С++ Замечательный просто - когда самые базовые системные аспекты профачены даже в 2024, и на каждый такой факап телепают именно синтаксис ЯП и тулчейн. Обратно несовместимым способом.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 10:11
	зато куда хуже, чем у реального стандарта IEEE(POSIX), принятого во всем мире всеми(даже виндой в некотором плане). а "стандарт в коде" - это не более, чем.. хз даже, что. лень?
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	27. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (-), 05-Окт-24, 02:11
	> поттеринг так же делал с его uapi. Что за uapi у Поттеринга? Вроде uapi это про ядро линуха и делается оно ядерщиками. Но в общем то официальный апи у ядра - вон те сисколы и проч, типа posix. Но есьт и хренова куча более внутренних ифейсов, и ессно - весьма изменчивых. Кстати Поттеринг и ко недавно все же устали кажется от факапов dbus'еров и кажется в настроении больше юзать внутренний ифейс, который они юзают когда dbus в ОС нету. Dbus все же с рядом тупняков. То что брокер после апдейта перезаутсить нельзя - это вообще лол. Но поттер в этом не виноват, системда как раз отлично перезапускает сам себя и состояние корректно сериализует-десериализует.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	38. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 07:53
	про линуксовое - не в курсе. см. uapi-group.org
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (50), 05-Окт-24, 13:54
	Linux API давно есть и называется оно GLibc.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (50), 05-Окт-24, 14:17
	>TPM – Trusted Platform Module (security chip) Ну и зачем этот тивоизатор к API пристёгивать? Чувствуется направляющая рука Редмонда.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	54. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 14:55
	затем, что он является единственным аппаратным корнем доверия для системы?
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (17), 05-Окт-24, 12:42
	Давайте не будем забывать, что Дибас все же исторически притянутая штука, для реализации конкретных ништяков между процессами. Альтернативы есть? Вот Поттеринг в свое время хотя бы СистемДы предложил для своих целей. Может стоит ее доработать\расширить, что бы вместо ДиБаса работала? Или свое что то с нуля написать?(на расте)
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	43. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (-), 05-Окт-24, 11:01
	> причем, единый компилятор. кажется в теме про POFIG тебе писали, что компилятор не один и ты даже ответила "глянула, действительно" (opennet.ru/openforum/vsluhforumID3/134869.html#361) Это та самая девичья память про которую все любят рассказывать? Или это просто вброс тролля))? > вместо того, что б написать стандарт и реализовать, Хорошо что с другими языками не так.. А назовите мне компилятор который полностью реализует стандарт СИ, желательно не протухшей версии и не за 100500 денег от проприетарщиков.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	44. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 12:29
	>У Раста есть фронт и бек, как у многих языков которые делались под llvm Изначально компилятор писался на окалме, а потом переписали на сам раст (rustc). Но это фронт. А бек у него был с использованием llvm (который написан на С++). Но есть и альтернатива в виде cranelift - бекенд написанный полностью на расте. Т.е есть у нас есть рабочий вариант "rust front + rust back". это связано как-то? я по поводу cranelift'a написала, не знала о нем. но, вроде, тут про стандарт ничего не сказано. моя притензия в том, что, посмотрев, например, POSIX и UAPI, сразу видно, что и где составлялось с нуля, а где "описывали готовое"(в POSIX тоже есть такое, но немного). вон, gnu-расширения clang реализует. но это не отменяет того факта, что это по сути "хотьба по минному полю", ни у кого никаких гарантий, что завтра все не поменяется, или, что _вон там_ все, как у всех. с coreutils та же фигня. просто "еще одна реализация man'a". Вы UAPI видели? это почти ``` man systemd.* | sed -е 's/systemd/реализация/' ```
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 12:35
	забыла дописать, спала не очень. видно в основном по продумонности и  универсальности решений. сделать "сразу хорошо" довольно сложно. а написать на любом языке то, что предварительно было вдумчиво прописано - относительно просто. хотя, написать сразу хорошо тоже сложно. поэтому иногда сходит к "написали, начали реализовывать, пошли опять писать/переписывать". что, в принципе, хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 12:39
	>А назовите мне компилятор а хз? мне их подход к стандартописанию не нравится. даже IEEE до конца все поправить не до конца смогли, хоть и стало куда лучше. могу назвать рантаймы для posix sh. это другое дело. но тоже недостатки есть, ибо расширения прописаны, а способ приведение к требованием стандарта/уровню комфорта - нет.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	32. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (32), 05-Окт-24, 03:53
	За целый год не припомнишь? Склероз страшная болезнь конечно. Но если освежить память пролистыванием хотя бы одной страницы новостей, то даже буквально на этой неделе только было https://www.opennet.dev/opennews/art.shtml?num=61956
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	37. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Продавец (?), 05-Окт-24, 06:03
	Кто все, это халивар мирового масштаба
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	41. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (-), 05-Окт-24, 10:54
	Лол, просто ищешь по форуму слово "Уязвимость" и смотришь сколько там будет ʼчистой проблемы с памятьюʼ)) Компилятор у раста не один, это миф фанатиков. Проверенны десятилетиями (но все еще дырявые) либы можно брать готовые, с пометкой "переписать когда будет время".
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	49. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (50), 05-Окт-24, 13:42
	Но пригодный к использоваеию только один, на данный момент. Gccrs всё ещё не готов.
	Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+2 +/–
Сообщение от Аноним (-), 05-Окт-24, 01:53
> отредактировать файл /etc/shadow и записать в него новые > параметры входа для учётной записи root. - У нас дыра в безопасности! - Ну хоть что-то у нас в безопасности...
Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (10), 05-Окт-24, 02:46
	А чему удивляетесь то? это же ОС общего назначения, для нее /etc/shadow это обычный пользовательский файл, и вовсе не системный, перезаписали ну и бог с ним, ядро то и без него запустится, а вот что будет делать пользователь с поврежденным файлом, так ядру до лампочки.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (-), 05-Окт-24, 04:15
	> А чему удивляетесь то? это же ОС общего назначения, для нее /etc/shadow > это обычный пользовательский файл, и вовсе не системный, > перезаписали ну и бог с ним, Ну так если его не перезаписывать - вы и легитимных юзерей добавлять не сможете, как и пароли менять. То-есть разложить core системы на, допустим, readonly пожложке, конечно, можно. И атакующие обломаются. Попробуйте вообще перезаписать что-то в вон том дебиане у меня в squashfs? :). Но проблема в том что неудобно от этого - не только атакующему. И стало быть очень нишевое решение. > ядро то и без него запустится, а вот что будет делать пользователь с поврежденным > файлом, так ядру до лампочки. В конечном итоге факап все же - в приблуде которая ведется на левые манипуляции, зачем-то доверяя юзерам и давая им делать вон то - на чем и погорело. Тот неловкий момент когда в погоне за фичами и удобствами подстрелили себе пятку.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от мяв (?), 05-Окт-24, 10:12
	обоим - google://MAC
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+1 +/–
	Сообщение от OpenEcho (?), 05-Окт-24, 10:54
	Мявочка сегодня была очень лаконична :) Я думаю что они найдут по запросу МАС в гугле страниц 10 про MacOS  или кучу других покупаемых продуктов с которых гугля тянет мзду... вместо Mandatory Access Control (aka MAC)
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (10), 05-Окт-24, 14:32
	> вместо Mandatory Access Control А че не Medium Access Control?
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (10), 05-Окт-24, 14:31
	> Ну так если его не перезаписывать - вы и легитимных юзерей добавлять не сможете, как и пароли менять. Ну я же и говорю, чему тут удивляться? это обычный пользовательский файл. И в этой системе (модели безопасТности) есть всегда "пользователь" (root) который может изменять любой файл любого "пользователя". Зачем такой "пользователь" нужен - нам любезно ответит мадам Мяу. > То-есть разложить core системы на, допустим, readonly пожложке, конечно, можно. Для ОС общего назначения нах не нужно, никого это не заботит. > И стало быть очень нишевое решение. Нету общей модели безопасности, она всегда затачивается под задачи, и ОС должны проектироваться под конкретные модели. > В конечном итоге факап все же - в приблуде которая ведется на левые манипуляции Вопрос в том, с какого бодуна можно создавать ссылки на "чужие" файлы? Вот кто эту ересь придумал? Думаю, нам любезно ответит мадам Мяу. > Тот неловкий момент когда в погоне за фичами и удобствами подстрелили себе пятку. Я сколняюсь к версии о бекдоре, ибо изначально оно было спроектированно именно так как требовала дефолтная модель безопасТности линуха, то есть все системное - от рута и под рутом. # chmod 600 /etc/users.oath # chown root /etc/users.oath А потом какой-то гений придумал, что лучше будет дать это управление самому пользователю и пусть он настраивает отп доступ, ДЕВЖОПС, что сказать. Ну дайте пользователю доступ, чтобы он вообще мог себе настроить беспарольный доступ, и дайте возможность установить пароль 123 и плевать на всякие политики безопасности, что бл**ть за МАРАЗМ?
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема