The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в pam_oath, позволяющая получить права root в системе

04.10.2024 21:58

В PAM-модуле pam_oath, входящем в состав пакета oath-toolkit и применяемого при двухфакторной аутентификации с использованием одноразовых паролей (OTP), выявлена уязвимость (CVE-2024-47191), позволяющая непривилегированному пользователю получить root-доступ в системе.

Модуль pam_oath выполняется с правами root и изначально был рассчитан на размещение OATH-ключей в файле /etc/users.oath, доступ к которому имеет только пользователь root. В версии oath-toolkit 2.6.7 была добавлена поддержка размещения файлов с ключами в домашних каталогах пользователей (~/.config/users.oath). Непривилегированные пользователи получили возможность изменения файлов со своими ключами, но pam_oath при обращении к этим файлам не сбрасывал привилегии и продолжил использование небезопасных методов работы с файлами, рассчитанные на то, что файлы размещены в каталоге, недоступном для изменения.

Уязвимость вызвана тем, что после каждой успешной аутентификации по одноразовому паролю, pam_oath выполнял перезапись файла с ключами чтобы не допустить использование одного пароля несколько раз. Операция перезаписи сводилась к созданию в том же каталоге lock-файла, записи нового содержимого в файл с расширением ".new" и замене старого файла на новый вариант. При этом файл с расширением ".new" создавался с теми же правами, что и целевой файл, но запись в него производилась процессом с правами root и без проверки существования файла.

Если файл размещался в системном каталоге проблем не возникало, но после появления поддержки размещения файлов с ключами в домашних каталогах, возникла легко эксплуатируемая уязвимость. Для атаки достаточно создать символическую ссылку "~/.config/oath.secrets.new" и направить её на любой системный файл, который будет перезаписан после успешной аутентификации.

Для получения доступа root можно направить символическую ссылку на файл /etc/shadow. В этом случае pam_oath запишет в /etc/shadow актуальный список ключей и синхронизирует владельца и права доступа с файлом users.oath. Так как файл users.oath принадлежит пользователю, то в качестве владельца /etc/shadow будет выставлен этот пользователь, после чего атакующий сможет отредактировать файл /etc/shadow и записать в него новые параметры входа для учётной записи root.

Уязвимость проявляется начиная с выпуска oath-toolkit 2.6.7 и устранена (1,2,3) в версии 2.6.12. Отследить устранение уязвимости в дистрибутивах можно на данных страницах: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch. Уязвимость затрагивает только конфигурации, в которых разрешено размещение файлов с ключами в домашних каталогах, например, при использовании в настройках PAM строки "auth [user_unknown=ignore success=ok] pam_oath.so usersfile=${HOME}/user.oath".

Дополнительно можно упомянуть выявленную на днях уязвимость (CVE-2024-9313) в PAM-модуле из состава пакета Authd, развиваемого проектом Ubuntu. Уязвимость позволяет пользователю, управляемому через брокер Authd, выдать себя за любого другого пользователя, управляемого этим же брокером, и успешно пройти аутентификацию через su, sudo или ssh под другим пользователем. Проблема устранена в версии Authd 0.3.5.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Локальная root-уязвимость в pam-python
  3. OpenNews: Критическая уязвимость в обработчике крахов приложений, применяемом в Ubuntu
  4. OpenNews: Критическая уязвимость в PolKit, позволяющая получить root-доступ в большинстве дистрибутивов Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61987-pam_oath
Ключевые слова: pam_oath, pam
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.10, Аноним (10), 22:49, 04/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > после чего атакующий сможет отредактировать файл /etc/shadow и записать в него новые параметры входа для учётной записи root.

    а там не надо делать что-то на подобии pwd_mkdb?

     
     
  • 2.12, Аноним (12), 23:03, 04/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это просто текстовый файл. pwd_mkdb - это просто обёртка в стандартной библиотеке. Можно читать самостоятельно и самостоятельно парсить, там даже формат очень простой.
     
     
  • 3.30, Аноним (10), 02:48, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Это просто текстовый файл.

    да, это просто пользовательский текстовый файл, а не какой-то там системный "важный" файл.

     

  • 1.13, Аноним (12), 23:09, 04/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Фикс, похоже, заключается в том, чтобы добавить O_EXCL помимо O_CREAT в open(). По POSIX, комбинация O_EXCL | O_CREAT должна выдать ошибку, если путь уже существует, даже если это симлинк.
     
  • 1.17, Аноним (17), 00:49, 05/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    1) а что, система(pam_oath) даже не проверяет содержимое файла парсингом, тупо копирует неизвестные данные "справа налево" с сохранением атрибутов файла?
    2) почему pam_oath имеет доступ к файлу /etc/shadow (да и вообще в /etc/) ?
    3) если бы подобное реализовал я, ну как минимум из под ограниченного пользователя подобное(службы) надо создавать.
    А так - похоже на лютый студенческий скрипто-костылинг.
     
     
  • 2.20, мяв (?), 01:17, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1) даже, если б проверяла, что мешает пропихнуть файл в промежуток между проверкой и перемещением? ничего. довольно, к слову, попудю́
    2) потому что службы PAM'у нужен рут. он просто грузит .so-файлы модулей.
    3) похоже на лютое студенческое незнание матчасти!
     
     
  • 3.21, мяв (?), 01:18, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    тьфу, забыла дописать)
    1) ... довольно популярная ошибка. даже в ман'ах о ней пишут.
     
  • 3.26, Аноним (-), 02:08, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > 1) даже, если б проверяла, что мешает пропихнуть файл в промежуток между
    > проверкой и перемещением? ничего. довольно, к слову, попудю́

    Это называется TOCTOU если что. (Time Of Check VS Time Of Use). Но тут до этого не дошло и факап проще оказался.

     
  • 3.46, Аноним (17), 12:37, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не показали свой способ реализации(что бы избежать подобной ошибки).
    Я, хоть что то предложил, хоть и не программист. (критикуешь - предлагай то, что считаешь правильным)
     

  • 1.19, Аноним (19), 00:55, 05/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    самое забавное что за последний год я что-то не припомню чистой проьблемы с памятью, вечно то ресур не освободят какой то проверку не проведут то файл нулями забъют (привет синие экраны на винде во всем мире). А молятся все на раст... и плавать что это еще 1 компилятор нестабильный к тому же. Без настолько провереных десятилетиями статических анализаторов и готового парка библиотек.  
     
     
  • 2.22, мяв (?), 01:23, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    причем, единый компилятор.
    вместо того, что б написать стандарт и реализовать, они реалтзуют и описывают. но продвигают, как "стандарт".
    поттеринг так же делал с его uapi.
     
     
  • 3.23, Самый Лучший Гусь (?), 01:27, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Так компилятор и есть стандарт просто реальзованый в настоящем коде. Куда лучше чем у С/С++
     
     
  • 4.25, Аноним (-), 01:54, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Так компилятор и есть стандарт просто реальзованый в настоящем коде. Куда лучше чем у С/С++

    Замечательный просто - когда самые базовые системные аспекты профачены даже в 2024, и на каждый такой факап телепают именно синтаксис ЯП и тулчейн. Обратно несовместимым способом.

     
  • 4.39, мяв (?), 10:11, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    зато куда хуже, чем у реального стандарта IEEE(POSIX), принятого во всем мире всеми(даже виндой в некотором плане).
    а "стандарт в коде" - это не более, чем.. хз даже, что. лень?
     
  • 3.27, Аноним (-), 02:11, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > поттеринг так же делал с его uapi.

    Что за uapi у Поттеринга? Вроде uapi это про ядро линуха и делается оно ядерщиками. Но в общем то официальный апи у ядра - вон те сисколы и проч, типа posix. Но есьт и хренова куча более внутренних ифейсов, и ессно - весьма изменчивых.

    Кстати Поттеринг и ко недавно все же устали кажется от факапов dbus'еров и кажется в настроении больше юзать внутренний ифейс, который они юзают когда dbus в ОС нету. Dbus все же с рядом тупняков. То что брокер после апдейта перезаутсить нельзя - это вообще лол. Но поттер в этом не виноват, системда как раз отлично перезапускает сам себя и состояние корректно сериализует-десериализует.

     
     
  • 4.38, мяв (?), 07:53, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    про линуксовое - не в курсе.
    см. uapi-group.org
     
     
  • 5.50, Аноним (50), 13:54, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Linux API давно есть и называется оно GLibc.
     
  • 5.51, Аноним (50), 14:17, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >TPM – Trusted Platform Module (security chip)

    Ну и зачем этот тивоизатор к API пристёгивать? Чувствуется направляющая рука Редмонда.

     
     
  • 6.54, мяв (?), 14:55, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    затем, что он является единственным аппаратным корнем доверия для системы?
     
  • 4.48, Аноним (17), 12:42, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте не будем забывать, что Дибас все же исторически притянутая штука, для реализации конкретных ништяков между процессами.
    Альтернативы есть?
    Вот Поттеринг в свое время хотя бы СистемДы предложил для своих целей. Может стоит ее доработать\расширить, что бы вместо ДиБаса работала? Или свое что то с нуля написать?(на расте)
     
  • 3.43, Аноним (-), 11:01, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > причем, единый компилятор.

    кажется в теме про POFIG тебе писали, что компилятор не один
    и ты даже ответила "глянула, действительно" (opennet.ru/openforum/vsluhforumID3/134869.html#361)
    Это та самая девичья память про которую все любят рассказывать? Или это просто вброс тролля))?

    > вместо того, что б написать стандарт и реализовать,

    Хорошо что с другими языками не так..
    А назовите мне компилятор который полностью реализует стандарт СИ, желательно не протухшей версии и не за 100500 денег от проприетарщиков.

     
     
  • 4.44, мяв (?), 12:29, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >У Раста есть фронт и бек, как у многих языков которые делались под llvm

    Изначально компилятор писался на окалме, а потом переписали на сам раст (rustc).
    Но это фронт.
    А бек у него был с использованием llvm (который написан на С++).
    Но есть и альтернатива в виде cranelift - бекенд написанный полностью на расте.
    Т.е есть у нас есть рабочий вариант "rust front + rust back".

    это связано как-то?
    я по поводу cranelift'a написала, не знала о нем.
    но, вроде, тут про стандарт ничего не сказано.
    моя притензия в том, что, посмотрев, например, POSIX и UAPI, сразу видно, что и где составлялось с нуля, а где "описывали готовое"(в POSIX тоже есть такое, но немного).
    вон, gnu-расширения clang реализует. но это не отменяет того факта, что это по сути "хотьба по минному полю", ни у кого никаких гарантий, что завтра все не поменяется, или, что _вон там_ все, как у всех. с coreutils та же фигня.
    просто "еще одна реализация man'a".
    Вы UAPI видели?
    это почти
    '''
    man systemd.* | sed -е 's/systemd/реализация/'
    '''

     
     
  • 5.45, мяв (?), 12:35, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    забыла дописать, спала не очень.
    видно в основном по продумонности и  универсальности решений.
    сделать "сразу хорошо" довольно сложно. а написать на любом языке то, что предварительно было вдумчиво прописано - относительно просто.
    хотя, написать сразу хорошо тоже сложно.
    поэтому иногда сходит к "написали, начали реализовывать, пошли опять писать/переписывать".
    что, в принципе, хорошо.
     
  • 4.47, мяв (?), 12:39, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >А назовите мне компилятор

    а хз?
    мне их подход к стандартописанию не нравится.
    даже IEEE до конца все поправить не до конца смогли, хоть и стало куда лучше.
    могу назвать рантаймы для posix sh.
    это другое дело. но тоже недостатки есть, ибо расширения прописаны, а способ приведение к требованием стандарта/уровню комфорта - нет.

     
  • 2.32, Аноним (32), 03:53, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    За целый год не припомнишь? Склероз страшная болезнь конечно.
    Но если освежить память пролистыванием хотя бы одной страницы новостей, то даже буквально на этой неделе только было https://www.opennet.ru/opennews/art.shtml?num=61956
     
  • 2.37, Продавец (?), 06:03, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Кто все, это халивар мирового масштаба
     
  • 2.41, Аноним (-), 10:54, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Лол, просто ищешь по форуму слово "Уязвимость" и смотришь сколько там будет ʼчистой проблемы с памятьюʼ))

    Компилятор у раста не один, это миф фанатиков.

    Проверенны десятилетиями (но все еще дырявые) либы можно брать готовые, с пометкой "переписать когда будет время".

     
     
  • 3.49, Аноним (50), 13:42, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Но пригодный к использоваеию только один, на данный момент. Gccrs всё ещё не готов.
     

  • 1.24, Аноним (-), 01:53, 05/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > отредактировать файл /etc/shadow и записать в него новые
    > параметры входа для учётной записи root.

    - У нас дыра в безопасности!
    - Ну хоть что-то у нас в безопасности...

     
     
  • 2.29, Аноним (10), 02:46, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А чему удивляетесь то? это же ОС общего назначения, для нее /etc/shadow это обычный пользовательский файл, и вовсе не системный, перезаписали ну и бог с ним, ядро то и без него запустится, а вот что будет делать пользователь с поврежденным файлом, так ядру до лампочки.
     
     
  • 3.33, Аноним (-), 04:15, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так если его не перезаписывать - вы и легитимных юзерей добавлять не сможете,... большой текст свёрнут, показать
     
     
  • 4.40, мяв (?), 10:12, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    обоим - google://MAC
     
     
  • 5.42, OpenEcho (?), 10:54, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мявочка сегодня была очень лаконична :)

    Я думаю что они найдут по запросу МАС в гугле страниц 10 про MacOS  или кучу других покупаемых продуктов с которых гугля тянет мзду... вместо Mandatory Access Control (aka MAC)

     
     
  • 6.53, Аноним (10), 14:32, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > вместо Mandatory Access Control

    А че не Medium Access Control?

     
  • 5.56, Аноним (10), 16:22, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    RHEL с SELinux-ом это конечно не затрагивает :)
     
  • 4.52, Аноним (10), 14:31, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я же и говорю, чему тут удивляться это обычный пользовательский файл И в эт... большой текст свёрнут, показать
     
  • 4.55, Аноним (10), 16:07, 05/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    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.

    он не только "гений", но и тонкий тролль.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру