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

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

	60. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Sem (??), 07-Окт-24, 19:55
	Что за обертка? О чем речь? pwd_mkdb(8) - это утилита в FreeBSD. Автор предыдущего сообщения спрашивал, этот файл разве не преобразовывается после редактирования в KV-db, как это сделано, например, в FreeBSD?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

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

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

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

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

	25. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	–1 +/–
	Сообщение от Аноним (-), 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 в сис..."	+1 +/–
	Сообщение от Аноним (32), 05-Окт-24, 03:53
	За целый год не припомнишь? Склероз страшная болезнь конечно. Но если освежить память пролистыванием хотя бы одной страницы новостей, то даже буквально на этой неделе только было https://www.opennet.ru/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ообщить модератору

	61. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Sem (??), 07-Окт-24, 20:00
	Бедняга, с памятью проблемы. Последняя в ядре 6.10 от 30.09.24. И там буквально CVE через 1-2, ну 3, проблемы с памятью.
	Ответить | Правка | К родителю #19 | Наверх | 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ообщить модератору

	56. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (10), 05-Окт-24, 16:22
	RHEL с SELinux-ом это конечно не затрагивает :)
	Ответить | Правка | К родителю #40 | Наверх | 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ообщить модератору

	55. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от Аноним (10), 05-Окт-24, 16:07
	2) usersfile=${HOME}/.config/oath/secrets User-owned file that is read/write-protected against other users. The disadvantage is that user can read their OATH secret, and potentially damage their ability to login by messing up the file, but in some situations that MAY BE AN ADVANTAGE. он не только "гений", но и тонкий тролль.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	59. "Уязвимость в pam_oath, позволяющая получить права root в сис..."	+/–
	Сообщение от randomize (?), 07-Окт-24, 10:38
	А если файл почищен вместе с хомяком, то юзер не залогинится больше? ))
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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