В PAM-модуле pam_oath, входящем в состав пакета oath-toolkit и применяемого при двухфакторной аутентификации с использованием одноразовых паролей (OTP), выявлена уязвимость (CVE-2024-47191), позволяющая непривилегированному пользователю получить root-доступ в системе...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61987
> после чего атакующий сможет отредактировать файл /etc/shadow и записать в него новые параметры входа для учётной записи root.а там не надо делать что-то на подобии pwd_mkdb?
Это просто текстовый файл. pwd_mkdb - это просто обёртка в стандартной библиотеке. Можно читать самостоятельно и самостоятельно парсить, там даже формат очень простой.
> Это просто текстовый файл.да, это просто пользовательский текстовый файл, а не какой-то там системный "важный" файл.
Что за обертка? О чем речь? pwd_mkdb(8) - это утилита в FreeBSD.Автор предыдущего сообщения спрашивал, этот файл разве не преобразовывается после редактирования в KV-db, как это сделано, например, в FreeBSD?
ну наконец-то кто-то понял юмор :)
Фикс, похоже, заключается в том, чтобы добавить O_EXCL помимо O_CREAT в open(). По POSIX, комбинация O_EXCL | O_CREAT должна выдать ошибку, если путь уже существует, даже если это симлинк.
1) а что, система(pam_oath) даже не проверяет содержимое файла парсингом, тупо копирует неизвестные данные "справа налево" с сохранением атрибутов файла?
2) почему pam_oath имеет доступ к файлу /etc/shadow (да и вообще в /etc/) ?
3) если бы подобное реализовал я, ну как минимум из под ограниченного пользователя подобное(службы) надо создавать.
А так - похоже на лютый студенческий скрипто-костылинг.
1) даже, если б проверяла, что мешает пропихнуть файл в промежуток между проверкой и перемещением? ничего. довольно, к слову, попудю́
2) потому что службы PAM'у нужен рут. он просто грузит .so-файлы модулей.
3) похоже на лютое студенческое незнание матчасти!
тьфу, забыла дописать)
1) ... довольно популярная ошибка. даже в ман'ах о ней пишут.
> 1) даже, если б проверяла, что мешает пропихнуть файл в промежуток между
> проверкой и перемещением? ничего. довольно, к слову, попудю́Это называется TOCTOU если что. (Time Of Check VS Time Of Use). Но тут до этого не дошло и факап проще оказался.
Вы не показали свой способ реализации(что бы избежать подобной ошибки).
Я, хоть что то предложил, хоть и не программист. (критикуешь - предлагай то, что считаешь правильным)
самое забавное что за последний год я что-то не припомню чистой проьблемы с памятью, вечно то ресур не освободят какой то проверку не проведут то файл нулями забъют (привет синие экраны на винде во всем мире). А молятся все на раст... и плавать что это еще 1 компилятор нестабильный к тому же. Без настолько провереных десятилетиями статических анализаторов и готового парка библиотек.
причем, единый компилятор.
вместо того, что б написать стандарт и реализовать, они реалтзуют и описывают. но продвигают, как "стандарт".
поттеринг так же делал с его uapi.
Так компилятор и есть стандарт просто реальзованый в настоящем коде. Куда лучше чем у С/С++
> Так компилятор и есть стандарт просто реальзованый в настоящем коде. Куда лучше чем у С/С++Замечательный просто - когда самые базовые системные аспекты профачены даже в 2024, и на каждый такой факап телепают именно синтаксис ЯП и тулчейн. Обратно несовместимым способом.
зато куда хуже, чем у реального стандарта IEEE(POSIX), принятого во всем мире всеми(даже виндой в некотором плане).
а "стандарт в коде" - это не более, чем.. хз даже, что. лень?
> поттеринг так же делал с его uapi.Что за uapi у Поттеринга? Вроде uapi это про ядро линуха и делается оно ядерщиками. Но в общем то официальный апи у ядра - вон те сисколы и проч, типа posix. Но есьт и хренова куча более внутренних ифейсов, и ессно - весьма изменчивых.
Кстати Поттеринг и ко недавно все же устали кажется от факапов dbus'еров и кажется в настроении больше юзать внутренний ифейс, который они юзают когда dbus в ОС нету. Dbus все же с рядом тупняков. То что брокер после апдейта перезаутсить нельзя - это вообще лол. Но поттер в этом не виноват, системда как раз отлично перезапускает сам себя и состояние корректно сериализует-десериализует.
про линуксовое - не в курсе.
см. uapi-group.org
Linux API давно есть и называется оно GLibc.
>TPM – Trusted Platform Module (security chip)Ну и зачем этот тивоизатор к API пристёгивать? Чувствуется направляющая рука Редмонда.
затем, что он является единственным аппаратным корнем доверия для системы?
Давайте не будем забывать, что Дибас все же исторически притянутая штука, для реализации конкретных ништяков между процессами.
Альтернативы есть?
Вот Поттеринг в свое время хотя бы СистемДы предложил для своих целей. Может стоит ее доработать\расширить, что бы вместо ДиБаса работала? Или свое что то с нуля написать?(на расте)
> причем, единый компилятор.кажется в теме про POFIG тебе писали, что компилятор не один
и ты даже ответила "глянула, действительно" (opennet.ru/openforum/vsluhforumID3/134869.html#361)
Это та самая девичья память про которую все любят рассказывать? Или это просто вброс тролля))?> вместо того, что б написать стандарт и реализовать,
Хорошо что с другими языками не так..
А назовите мне компилятор который полностью реализует стандарт СИ, желательно не протухшей версии и не за 100500 денег от проприетарщиков.
>У Раста есть фронт и бек, как у многих языков которые делались под llvmИзначально компилятор писался на окалме, а потом переписали на сам раст (rustc).
Но это фронт.
А бек у него был с использованием llvm (который написан на С++).
Но есть и альтернатива в виде cranelift - бекенд написанный полностью на расте.
Т.е есть у нас есть рабочий вариант "rust front + rust back".это связано как-то?
я по поводу cranelift'a написала, не знала о нем.
но, вроде, тут про стандарт ничего не сказано.
моя притензия в том, что, посмотрев, например, POSIX и UAPI, сразу видно, что и где составлялось с нуля, а где "описывали готовое"(в POSIX тоже есть такое, но немного).
вон, gnu-расширения clang реализует. но это не отменяет того факта, что это по сути "хотьба по минному полю", ни у кого никаких гарантий, что завтра все не поменяется, или, что _вон там_ все, как у всех. с coreutils та же фигня.
просто "еще одна реализация man'a".
Вы UAPI видели?
это почти
```
man systemd.* | sed -е 's/systemd/реализация/'
```
забыла дописать, спала не очень.
видно в основном по продумонности и универсальности решений.
сделать "сразу хорошо" довольно сложно. а написать на любом языке то, что предварительно было вдумчиво прописано - относительно просто.
хотя, написать сразу хорошо тоже сложно.
поэтому иногда сходит к "написали, начали реализовывать, пошли опять писать/переписывать".
что, в принципе, хорошо.
>А назовите мне компилятора хз?
мне их подход к стандартописанию не нравится.
даже IEEE до конца все поправить не до конца смогли, хоть и стало куда лучше.
могу назвать рантаймы для posix sh.
это другое дело. но тоже недостатки есть, ибо расширения прописаны, а способ приведение к требованием стандарта/уровню комфорта - нет.
За целый год не припомнишь? Склероз страшная болезнь конечно.
Но если освежить память пролистыванием хотя бы одной страницы новостей, то даже буквально на этой неделе только было https://www.opennet.me/opennews/art.shtml?num=61956
Кто все, это халивар мирового масштаба
Лол, просто ищешь по форуму слово "Уязвимость" и смотришь сколько там будет ʼчистой проблемы с памятьюʼ))Компилятор у раста не один, это миф фанатиков.
Проверенны десятилетиями (но все еще дырявые) либы можно брать готовые, с пометкой "переписать когда будет время".
Но пригодный к использоваеию только один, на данный момент. Gccrs всё ещё не готов.
Бедняга, с памятью проблемы. Последняя в ядре 6.10 от 30.09.24. И там буквально CVE через 1-2, ну 3, проблемы с памятью.
> отредактировать файл /etc/shadow и записать в него новые
> параметры входа для учётной записи root.- У нас дыра в безопасности!
- Ну хоть что-то у нас в безопасности...
А чему удивляетесь то? это же ОС общего назначения, для нее /etc/shadow это обычный пользовательский файл, и вовсе не системный, перезаписали ну и бог с ним, ядро то и без него запустится, а вот что будет делать пользователь с поврежденным файлом, так ядру до лампочки.
> А чему удивляетесь то? это же ОС общего назначения, для нее /etc/shadow
> это обычный пользовательский файл, и вовсе не системный,
> перезаписали ну и бог с ним,Ну так если его не перезаписывать - вы и легитимных юзерей добавлять не сможете, как и пароли менять. То-есть разложить core системы на, допустим, readonly пожложке, конечно, можно. И атакующие обломаются. Попробуйте вообще перезаписать что-то в вон том дебиане у меня в squashfs? :).
Но проблема в том что неудобно от этого - не только атакующему. И стало быть очень нишевое решение.
> ядро то и без него запустится, а вот что будет делать пользователь с поврежденным
> файлом, так ядру до лампочки.В конечном итоге факап все же - в приблуде которая ведется на левые манипуляции, зачем-то доверяя юзерам и давая им делать вон то - на чем и погорело. Тот неловкий момент когда в погоне за фичами и удобствами подстрелили себе пятку.
обоим - google://MAC
Мявочка сегодня была очень лаконична :)Я думаю что они найдут по запросу МАС в гугле страниц 10 про MacOS или кучу других покупаемых продуктов с которых гугля тянет мзду... вместо Mandatory Access Control (aka MAC)
> вместо Mandatory Access ControlА че не Medium Access Control?
RHEL с SELinux-ом это конечно не затрагивает :)
> Ну так если его не перезаписывать - вы и легитимных юзерей добавлять не сможете, как и пароли менять.Ну я же и говорю, чему тут удивляться? это обычный пользовательский файл. И в этой системе (модели безопасТности) есть всегда "пользователь" (root) который может изменять любой файл любого "пользователя". Зачем такой "пользователь" нужен - нам любезно ответит мадам Мяу.
> То-есть разложить core системы на, допустим, readonly пожложке, конечно, можно.
Для ОС общего назначения нах не нужно, никого это не заботит.
> И стало быть очень нишевое решение.
Нету общей модели безопасности, она всегда затачивается под задачи, и ОС должны проектироваться под конкретные модели.
> В конечном итоге факап все же - в приблуде которая ведется на левые манипуляции
Вопрос в том, с какого бодуна можно создавать ссылки на "чужие" файлы? Вот кто эту ересь придумал? Думаю, нам любезно ответит мадам Мяу.
> Тот неловкий момент когда в погоне за фичами и удобствами подстрелили себе пятку.
Я сколняюсь к версии о бекдоре, ибо изначально оно было спроектированно именно так как требовала дефолтная модель безопасТности линуха, то есть все системное - от рута и под рутом.
# chmod 600 /etc/users.oath
# chown root /etc/users.oathА потом какой-то гений придумал, что лучше будет дать это управление самому пользователю и пусть он настраивает отп доступ, ДЕВЖОПС, что сказать. Ну дайте пользователю доступ, чтобы он вообще мог себе настроить беспарольный доступ, и дайте возможность установить пароль 123 и плевать на всякие политики безопасности, что бл**ть за МАРАЗМ?
2) usersfile=${HOME}/.config/oath/secretsUser-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.он не только "гений", но и тонкий тролль.
А если файл почищен вместе с хомяком, то юзер не залогинится больше? ))
> но pam_oath при обращении к этим файлам не сбрасывал привилегиидальше можно не читать