LINUX.ORG.RU

Обнаружена уязвимость в Polkit, которая позволяет выполнять любую команду systemctl пользователю с низкими привилегиями

 , , ,


1

2

Уязвимость CVE-2018-19788 присутствует на большинстве операционных систем GNU/Linux и позволяет пользователю, чей UID превышает 2147483647, выполнить любую команду systemctl, равно как и получить root-права.

Проблема существует из-за ошибки в библиотеке Polkit (другое название PolicyKit), заключающейся в неправильной проверки запросов от пользователей с UID > INT_MAX. Где INT_MAX это константа определяющая максимальное значение переменной типа int, равняющаяся 0x7FFFFFFF в шестнадцатеричной или 2147483647 в десятичной системе счисления.

Исследователь по безопасности Rich Mirch (аккаунт в Twitter 0xm1rch) представил успешно работающий эксплоит, демонстрирущий данную уязвимость. Для его корректной работы требуется наличие пользователя с идентификатором 4000000000.

В Twitter'е предлагают гораздо более простой способ получения root-прав:

systemd-run -t /bin/bash

Компания Red Hat рекомендует системным администраторам не создавать аккаунты с отрицательными значениями UID или UID превышающими 2147483647 до тех пор, пока не будет выпущен патч, исправляющий уязвимость.

>>> Подробности

★★★

Проверено: Shaman007 ()

Ответ на: комментарий от alpha

И так чуточку, совсем ненавязчиво передергиваем.

Вообще-то именно произвольный. Потому, что в реальности такие UID выдаются именно произвольно, о чём выше уже писали несколько раз.

Вообще это отличная идея конечно, требовать чтобы systemd теперь своими юнит-тестами покрыл весь софт написанный за двадцать лет до него

Речь о том, что RHEL делают рукожопы. Факт наличия systemd тут скорее индикатор. Да и за каким хреном systemd берёт на себя полномочия запуска софта от рута со стороны пользователя, пусть и через policykit?

Quasar ★★★★★ ()
Ответ на: комментарий от ncrmnt

приведет ли дефолтная/типичная/кривая (но тем не менее типичная) настройка LDAP (или иного костыля авторизации) в среде где не овердохрена пользователей к самопроизвольному появлению таких UID, которые можно проэксплуатировать, или нет?

Думаю, зависит от конфига по умолчанию в конкретном дистрибутиве. Если UID будут раздаваться рандомно из указанного диапазона, то риск ненулевой. На деле закрыть эту дырищу можно самостоятельно без исправления софта.

Quasar ★★★★★ ()
Ответ на: комментарий от alpha

это базовая функциональность системы существовавшая задолго до появления systemd и являющаяся стандартом.

Ссылочку на ISO или RFC по policykit (включая конфиги на жабоскрипте) приведёшь?

И любой современный проект должен её поддерживать.

Вот тут ты и передёргиваешь. См. выше.

И да, можно долго разговаривать о том как линукс стал сложнее, умнее и как страшно жить. Можно пойди сделать hardened-дистр с отлючением всех «новомодных» фишечек (новомодность начинается с 2009 примерно). А можно взять себя в руки, перестать истерить и поработать над налаживанием обновлений на всех подконтрольных серверах, потому что уязвимости есть и будут и никто от них не застрахован. Святое ядро в том числе.

«Нет, это не новомодные хипстеры дебилы, что наплодили полурабочего говнеца! Это вы дебилы, раз не хотите за ними говно выстраивать фигурками так, чтобы оно хоть как-то работало и не так сильно воняло!»

Офигеть логика.

Quasar ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Штука в том, что polkit является стандартом только для FDO софта

Нет, не является. Freedesktop вообще никакие стандарты не имеет - в этом проекте есть только спецификации по работе с их стеком. На стандарты ЭТО не тянет. Это примерно то же, что называть DirectX стандартом.

Quasar ★★★★★ ()
Последнее исправление: Quasar (всего исправлений: 1)
Ответ на: комментарий от Quasar

С позиции разработчика systemd это так.

Даже с позиции разработчика systemd это косяк, потому что они используют дырявой метод авторизации. Это не libc и не ядро, они могут выкинуть polkit к чертовой матери и для пользователя вообще ничего не изменится.

kirk_johnson ★★ ()
Ответ на: комментарий от Quasar

Нет, не является. Freedesktop вообще никакие стандарты не имеет - в этом проекте есть только спецификации по работе с их стеком. На стандарты ЭТО не тянет. Это примерно то же, что называть DirectX стандартом.

Я не знаю, что ты называешь БОЖЕСТВЕННЫМ СТАНДАРТОМ КОТОРЫЙ НАПИСАН ПРАВИЛЬНО И ТЯНЕТ НА ЭТО ВЫСОКОЕ ЗВАНИЕ, но де-факто стандартом у fdoшного софта является использовать polkit для таких вот штук. Смирись.

kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от monk

Там в основном в пакете зависимости прописаны. Встречаются такие, для работы которых policykit не нужен в принципе. Например, winetricks.

Quasar ★★★★★ ()
Ответ на: комментарий от crypt

Специальное значение, о котором ты говоришь - это fork return status for child

То, о котором я говорил - это 0 в kill(2). Но fork тоже подходит.

А «глобальная переменная» с таким значением тоже существует: это сваппер-шедуллер.

С каким «таким»?

От ссылок на википедию уже изжога, так что вот lkml.

В трейсе, на который ты ссылаешься, pid 0 тоже используется в смысле «в данный момент нет ЦП нет процесса с валидным PID» (трейс начинается в start_kernel, потом do_IRQ - это прерывание).

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

но де-факто стандартом у fdoшного софта является использовать polkit для таких вот штук. Смирись.

Если объяснять на пальцах, то стандарт - это что-то вроде POSIX, ISO, OASIS и т.д. То, что не привязано к реализации. То, что в FDO - это привязка к реализациям. В FDO не стандарты, а спецификации по работе со стеком технологий.

Quasar ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Даже с позиции разработчика systemd это косяк

Это заявление разработчика systemd?

tailgunner ★★★★★ ()
Ответ на: комментарий от Quasar

Если ты вдруг не в курсе, то POSIX это именно описание работы со стеком технологий. Это такая общая сумма реализаций. И пишется он по устояшимся практикам, а не наоборот.

kirk_johnson ★★ ()
Ответ на: комментарий от Quasar

Попробовал в Devuan через policykit получить права рута. не получилось.

Это только в арче у людей получилось. Вопрос с pkexec разобрали в теме, почему у кого-то срабатывает, а у кого-то нет.
У меня не срабатывает уязвимость ни через pkexec, ни через systemd-run.

imul ★★★★★ ()
Ответ на: комментарий от Quasar

Андроид и эмбед в данном случае не рассматривался.

imul ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Если ты вдруг не в курсе, то POSIX это именно описание работы со стеком технологий.

Если ты не в курсе, то POSIX - это описание того, как стек технологий должен работать, а не наоборот.

Это такая общая сумма реализаций. И пишется он по устояшимся практикам, а не наоборот.

А спецификации FDO - это как раз наоборот.

Quasar ★★★★★ ()
Ответ на: комментарий от imul

Рассматривается всё. Но в первую очередь - серверы.

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

Ты б сначала хотя бы попытался понять о чём была речь там. Для этого много не надо.

imul ★★★★★ ()
Ответ на: комментарий от imul

Я как раз всё понял, чего нельзя сказать о тебе. Потому, что когда говорят о доле линукса и эксплуатации уязвимостей, речь идёт исключительно о возможности массово эти уязвимости эксплуатировать. Не имеет значения, какая доля линукса на десктопе - имеет значение только то, какая доля линукса вообще. Она огромна. По сабжу получается, что та область, в которой линукс доминирует, позволяет эксплуатировать уязвимость массово.

Quasar ★★★★★ ()
Ответ на: комментарий от anonymous

polkit позволяет и вовсе обходиться без ввода пароля в допустимых случаях

Ну вот. И как быть без polkit-а?

CryNet ★★ ()
Ответ на: комментарий от Quasar

Есть примеры использования кроме как через systemd? А то в сабжевой новости фигурирует сочетание systemd и policykit, что уже способствует развитию дискуссии в соответствующем направлении.

Естественно. Уже показали через pkexec.

Лёня «Обосрамс» Поцеринг точно такую же риторику толкал, когда визжал аки свинка, что в неработоспособности его системуды виноват стандарт FHS, а не его кривые руки

Это, случайно, не вывод предупреждения о том, что с отдельным /usr может ломаться самый разнообразный не связанный с systemd софт, но которое никак не влияло на работоспособность самого systemd, превратилось в «неработоспособность системуды из-за FHS»? :D

anonymous ()
Ответ на: комментарий от tailgunner

С каким «таким»?

мы вроде про pid 0

В трейсе, на который ты ссылаешься, pid 0 тоже используется в смысле «в данный момент нет ЦП нет процесса с валидным PID»

почему «тоже» не понял. «тоже» как с форк? да нет.

(трейс начинается в start_kernel, потом do_IRQ - это прерывание).

Process swapper/0 (pid: 0, threadinfo ffffffff8138e000, task ffffffff813a1020) - pid 0 - это глобальный indentifier процесса.

crypt ★★★★★ ()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Предлагаете покрывать юнит-тестами чужой продукт? o_O

anonymous ()
Ответ на: комментарий от int13h

Что-то прокосоглазил я твой пример с rhel.

imul ★★★★★ ()
Ответ на: комментарий от crypt

А «глобальная переменная» с таким значением тоже существует: это сваппер-шедуллер.

С каким «таким»?

мы вроде про pid 0

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

Process swapper/0 (pid: 0, threadinfo ffffffff8138e000, task ffffffff813a1020) - pid 0 - это глобальный indentifier процесса.

См. выше.

tailgunner ★★★★★ ()
Ответ на: комментарий от Quasar

Потому, что когда говорят о доле линукса и эксплуатации уязвимостей, речь идёт исключительно о возможности массово эти уязвимости эксплуатировать.

Я в том месте говорил не о эксплуатации уязвимостей, а о набежавших в топик истеришных с криками про systemd.

Я как раз всё понял, чего нельзя сказать о тебе.

Коля, то что ты понял годится только для принтов на туалетной бумаге.

imul ★★★★★ ()
Ответ на: комментарий от tailgunner

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

может быть, это процесс с фиксированным pid?:) также, как pid 1 в случае с init.

crypt ★★★★★ ()
Ответ на: комментарий от anonymous

Естественно. Уже показали через pkexec.

И показали, что не всегда это работает.

Это, случайно, не вывод предупреждения о том, что с отдельным /usr может ломаться самый разнообразный не связанный с systemd софт, но которое никак не влияло на работоспособность самого systemd, превратилось в «неработоспособность системуды из-за FHS»? :D

Нет. Я даже не знаю, откуда ты это взял. Там была проблема с запуском системы через systemd.

Quasar ★★★★★ ()
Ответ на: комментарий от tailgunner

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

раз не знаешь, то держи:

https://en.wikipedia.org/wiki/Process_identifier

There are two tasks with specially distinguished process IDs: swapper or sched has process ID 0 and is responsible for paging, and is actually part of the kernel rather than a normal user-mode process.

crypt ★★★★★ ()
Ответ на: комментарий от Quasar

И показали, что не всегда это работает.

Это и через systemd не всегда работает. Обновление polkit много куда пришло уже.

Нет. Я даже не знаю, откуда ты это взял. Там была проблема с запуском системы через systemd.

Можно ссылочку, пожалуйста?

anonymous ()
Ответ на: комментарий от crypt

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

раз не знаешь, то держи:
https://en.wikipedia.org/wiki/Process_identifier

Ты даже не понял, в чем была нелепость твоих слов.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от crypt

оу? мы опять включили режим умника?

Мы? Я его никогда и не выключаю, ты его еще и не включал.

чья бы корова мычала: Обнаружена уязвимость в Polkit, которая позволяет выполнять любую команду systemctl пользователю с низкими привилегиями

И что? Там всё правильно. Даже твоя ссылка на Wikipedia не говорит, что у ядра есть PID.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Проверить, а не глюканёт ли чужой продукт при передаче ему охренеть какого большого значения UID, - это ну никак не проверка своего продукта. А иначе этот баг было не поймать.

anonymous ()
Ответ на: комментарий от tailgunner

что у ядра есть PID.

а ты меня так понял, да? ох, умник - это далеко не умный человек, скорее глухой. ну да и хрен с тобой золотая рыбка.

crypt ★★★★★ ()
Ответ на: комментарий от crypt

что у ядра есть PID.

а ты меня так понял, да?

Я понял, что у тебя были какие-то претензии к моим утверждениям, которые ты не опроверг.

ну да и хрен с тобой золотая рыбка.

И тебе того же.

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

Проверить, а не глюканёт ли чужой продукт при передаче ему охренеть какого большого значения UID, - это ну никак не проверка своего продукта. А иначе этот баг было не поймать.

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

kirk_johnson ★★ ()
Ответ на: комментарий от kirk_johnson

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

Угу. На запись любого файла написать юнит-тест, проверяющий, что файл действительно создался, действительно с теми правами, его действительно могут читать те кто должны и не могут те, кто не должны (проверить все возможные UID, а то вдруг файл с правами 700 принадлежащий UID 4000000000 тоже все могут читать).

На вывод любой строки написать юнит-тест, снимающий состояние экрана, чтобы убедиться что строка действительно вывелась. На выполнение любого арифметического действия добавить юнит тест, проверяющий, что арифметика действительно работает верно...

Так что ли?

monk ★★★★★ ()
Ответ на: комментарий от kirk_johnson

домыслы неумею, да. только то что написано.

Thero ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Проверить, правильно ли работает твой программный продукт

Их программный продукт работает правильно:

  1. спрашивает у polkit, можно ли пользователю запустить данную операцию;
  2. получает ответ, что можно;
  3. запускает операцию.

В чём здесь, по-вашему, ошибка?

anonymous ()
Ответ на: комментарий от crypt

странно что pkexec себя по разному в разных дистрибутивах ведёт.. кто-то не возвращает патчи в апстрим или шо?

Thero ★★★★★ ()

самая вишенка истории конечно же в том что если pkexec в некоторых дистрибутивах дополнительно проверяет uid за полкитом, значит они нашли что полкит неправильно себя ведёт, но вместо того что-бы зарепортить багу в полкит они у себя костылик добавили..

Thero ★★★★★ ()
Ответ на: комментарий от Thero

Может они сделали и то и другое одновременно. Надо сверять даты

duraki ★★★ ()
Ответ на: комментарий от tailgunner

а точно.. run это тот который всё что угодно как сервис запускает?

Thero ★★★★★ ()
Ответ на: комментарий от duraki

такто да надо теперь смотреть когда в pkexec эта проверка появилась..

Thero ★★★★★ ()
Ответ на: комментарий от anonymous

Их программный продукт работает правильно:

спрашивает у polkit, можно ли пользователю запустить данную операцию;
получает ответ, что можно;
запускает операцию.

В чём здесь, по-вашему, ошибка?

В классической ошибке программиста. Фича заключается не в том, чтобы у polkit'а спросить, а в том, чтобы сделать возможным выполнение привилегированных операций без привлечения рута, но только тем юзерам, которым явно разрешили. В данном случае, решили сделать через polkit и дать возможность выполнять команды только юзерам с правами auth_admin. И вот этот момент они и не проверили.

Тестировать нужно видную пользователю функциональность. В данном случае — выполнение привилегированных команд через systemctl, и совсем не важно, через что там это реализовано. А то вдруг у них там

if (uid > 0 && uid <= INT_MAX)
    res = ask_polkit();

И все, привет.

kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 4)
Ответ на: комментарий от monk

Угу. На запись любого файла написать юнит-тест, проверяющий, что файл действительно создался, действительно с теми правами, его действительно могут читать те кто должны и не могут те, кто не должны

У тебя есть uid, у него есть три типа значений — ноль (рут), 1 - UID_MAX (юзеры) и все, что выше. И да, их по хорошему стоит проверить. Хотя бы по одному из группы.

(проверить все возможные UID, а то вдруг файл с правами 700 принадлежащий UID 4000000000 тоже все могут читать).

Слово «fuzzing» ты, видимо, в первый раз слышишь.

На вывод любой строки написать юнит-тест, снимающий состояние экрана, чтобы убедиться что строка действительно вывелась.

Если от вывода на экран зависит, пустили ли меня в суперсекретную часть программы — да, наверное стоит.

На выполнение любого арифметического действия добавить юнит тест, проверяющий, что арифметика действительно работает верно...

Проверки на integer overflow обычно пытаются зашить в фукнции. realloc, calloc и reallocarray не просто так придумали.

kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.