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 ()
Последнее исправление: ls-h (всего исправлений: 5)

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

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

POSIX включает в себя то, какие функции есть, как их дергать и что получится. А ещё описание опций CLI тулзов.

Прямо как... описание софта FDO :)

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

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

А эти функции точно правильно работают, а то, может, и их надо проконтролировать? А потом и вызовы ядра? Ну, мало ли что.

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

А эти функции точно правильно работают, а то, может, и их надо проконтролировать?

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

А потом и вызовы ядра? Ну, мало ли что.

Когда-нибудь ты вырастешь и узнаешь про syzkaller.

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

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

Их стоит проверить утилитам типа useradd и polkit (внезапно).

Для systemd это детали реализации вспомогательных утилит. Проверка их unit-тестами на стороне systemd нелогична.

Как например нелогично в юнит-тестах проверять может ли systemd запустить mysql на Ubuntu 16.04.

Этот тест-кейс _можно_ было бы добавить в интеграционные тесты systemd, но отсутствие его там не является криминалом.

То что system взаимодействует с большим количеством сервисов не повод все баги этих сервисов вешать на разработчиков systemd.

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

Их стоит проверить утилитам типа useradd и polkit (внезапно).

Это называется unit-тестирование. Когда ты проверяешь отдельный компонент. А ещё есть integration-тестирование. Когда ты проверяешь, что все компоненты связаны и работают *В СВЯЗКЕ* как надо. Что ты получаешь *ОЖИДАЕМОЕ ОТ СИСТЕМЫ* поведение.

Для systemd это детали реализации вспомогательных утилит. Проверка их unit-тестами на стороне systemd нелогична.

Ты проверяешь не polkit, ты проверяешь *ЧТО SYSTEMCTL НЕ ПУСКАЕТ ЮЗЕРА, КОТОРОГО НЕ ДОЛЖЕН ПУСТИТЬ СОГЛАСНО ТЕСТОВОМУ ПЛАНУ*. Потому что баг может оказаться на стыке компонентов. Поэтому unit-тестирование и integration-тестирование — разные виды тестирования, часто приводящие к разному результату.

То что system взаимодействует с большим количеством сервисов не повод все баги этих сервисов вешать на разработчиков systemd.

*ФИЧА SYSTEMD* (то есть возможность выполнения привилегированных операций от непривилегированного юзера) — это фича systemd, а не polkit. То, что оно работает через polkit — детали реализации.

P.S. Жирненьким я отметил важные пункты.

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

Прикинь. Их чуваки из glibc тестируют.

То есть этим чувакам мы можем верить. Это хорошо. А почему, собственно, им верим, а чувакам из polkita нет? В libc багов не бывает? Бывает. Так, почему?

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

То есть этим чувакам мы можем верить. Это хорошо. А почему, собственно, им верим, а чувакам из polkita нет? В libc багов не бывает? Бывает. Так, почему?

А мы им и не верим, мы регулярно прогоняем наш софт через проверки на целостность памяти. Мы так баги в jemalloc нашли.

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

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

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

Но ведь не только systemd-run, а вообще можно «выполнить любую команду systemctl»

И? Я вообще могу выполнить любую команду в системе, хоть rm -rf.

Сорри, я отвечал на реплику «systemd-run - отдельный бинарь, он не является частью критического кода PID 0», неправильно прочитав «PID 0» как «UID 0». Но, прочитав дальнейшие сообщения и поняв, что под «критическим кодом» подразумевался init c pid'ом 1, у меня другой вопрос: почему именно init является критическим, а другие процессы — нет? Чем он отличается от остальных помимо того, что является родителем остальных? Я бы ещё понял, если бы речь шла о режиме ядра против против пользовательского режима, но при чём тут init?

Пока нормально проверяются права, в чем проблема?

Так в том-то и дело, что права проверяются ненормально, и пользователь с uid > 0x7FFFFFFF получает привилегии uid 0. Об этом и новость. А если бы права проверялись нормально, то и вопросов не было, как и самой новости.

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

Я бы ещё понял, если бы речь шла о режиме ядра против против пользовательского режима, но при чём тут init?

Дескать, даже init, который должен быть простым, как валенок, испортить умудрились.

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

Сама RedHat, судя по новости, считает это багом

Да, только не в systemd, а в polkit.

Я согласен, что основная вина тут лежит на разработчиках polkit. Однако, как здесь уже говорили, разработчики systemd, линковавшиеся с polkit, тоже должны были протестировать свой код, особенно на уязвимости. Я подчёркиваю: свой слинкованный код, а не библиотеку. И если бы они это сделали достаточно тщательно, то обнаружили бы проблему и решили её сразу. Как здесь уже говорили, другие программы, использующие polkit, не предоставляют таких прав простому пользователю с большим uid'ом, потому что сами проверяют этот самый uid. И, ещё раз: я не кричу, что systemd сплошное решето и ужас-ужас, хотя многое и в его архитектуре, и в реакции Поттеринга на любую критику мне не нравится (но не настолько, чтоб уходить с debian и мучиться с devuan). Я только говорю, что это баг, в котором, помимо разработчиков polkit, отчасти виноваты и разработчики systemd.

Но местные хейтеры и слышать/видеть ничего не хотят - у них вегда systemd виноват. Убогие.

Но я прокомментировал даже не сообщения о том, кто виноват — polkit или systemd, — а огромное число сообщений о том, что проблемы вообще нет, потому что таких uid не бывает. И подобных фанатов в теме куда больше, чем хейтеров, кричащих, что systemd — по определению решето. И даже те, кто высказался подобным образом в этом треде, аргументировали свою позицию, в отличие от первых.

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

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

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

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

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Какие интерфейсы, что фазим? А то вот создание файлика фазить проблемы нет.

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

почему именно init является критическим, а другие процессы — нет?

Потому что от функционирования init зависит функционирование системы; а падение init - это крах системы.

Так в том-то и дело, что права проверяются ненормально, и пользователь с uid > 0x7FFFFFFF получает привилегии uid 0.

Да. Но это не проблема systemd-run.

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

А мы им и не верим, мы регулярно прогоняем наш софт через проверки на целостность памяти. Мы так баги в jemalloc нашли.

И, типа, больше ошибок нет и не будет?

Будь последователен: libc - своя, ядро своё и т.д. Причём, каждый последующий слой не верит предыдущему, поэтому таскает с собой ещё одну «безошибочную» собственную реализацию. Чёрт, но ей тоже нельзя верить. В какой момент собираешься остановиться?

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

Это ты ничего не понял и отвечаешь на условный рефлекс.

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

И, типа, больше ошибок нет и не будет?

Кто тебе сказал?

Будь последователен: libc - своя, ядро своё и т.д. Причём, каждый последующий слой не верит предыдущему, поэтому таскает с собой ещё одну «безошибочную» собственную реализацию. Чёрт, но ей тоже нельзя верить. В какой момент собираешься остановиться?

Это ты сейчас к чему? Если что, ребята из glibc в том числе проверяют, что с новой версией ядра сисколы не вносят искажений в работу glibc.

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

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Какие интерфейсы, что фазим?

Фазим systemd-run для того, чтобы найти сабжевый баг, естественно. Интерфейсы - CLI systemd-run и DBus-интефейс polkit.

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

Фазим systemd-run для того, чтобы найти сабжевый баг, естественно. Интерфейсы - CLI systemd-run и DBus-интефейс polkit.

Запускаем контейнер с PID namespace'ом и попердолили. А в чем проблема?

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

*ЧТО SYSTEMCTL НЕ ПУСКАЕТ ЮЗЕРА, КОТОРОГО НЕ ДОЛЖЕН ПУСТИТЬ СОГЛАСНО ТЕСТОВОМУ ПЛАНУ*

согласно тестовому плану systemd пускает юзера которого ему сказал пустить polkit

Поэтому unit-тестирование и integration-тестирование — разные виды тестирования

Да, и требования к ним разные. Если по unit-тестированию ты можешь наезжать на разработчиков почему они не покрыли такую-то фичу тестами, какие нехорошие люди, это должно быть в системе изначально... то по интеграционному отсутствие тестирования corner-case из совсем другой темы - это не криминал, а нормальная работа.

Весь мир в интеграционные тесты одного проекта не запихнешь и на одну команду разработчиков не повесишь.

И поэтому собственно смешно как по поводу отсутствия интеграционного теста ты тут два дня шумишь, а отсутствие unit-тестов у polkit - ну это ладно, там не Поттеринг же. Даже имени разработчиков их не знаем, вся ненависть на systemd ушла.

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

согласно тестовому плану systemd пускает юзера которого ему сказал пустить polkit

Любого? Типа политики, которые systemd устанавливает, ничего не значат? :D

Да, и требования к ним разные. Если по unit-тестированию ты можешь наезжать на разработчиков почему они не покрыли такую-то фичу тестами, какие нехорошие люди, это должно быть в системе изначально... то по интеграционному отсутствие тестирования corner-case из совсем другой темы - это не криминал, а нормальная работа.

Не понял, раскрой.

Весь мир в интеграционные тесты одного проекта не запихнешь и на одну команду разработчиков не повесишь.

Поэтому они напихали столько фичей, что не могут их нормально протестировать, и теперь постоянно вляпываются в глупые баги?

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

Расскажи, как фаззить многопроцессную программу, один из процессов которой - короткоживущий.

Какие интерфейсы, что фазим?

Фазим systemd-run для того, чтобы найти сабжевый баг, естественно. Интерфейсы - CLI systemd-run и DBus-интефейс polkit.

Запускаем контейнер с PID namespace'ом и попердолили.

Ясно.

А в чем проблема?

По описанию «запускаем и попердолили» трудно сказать.

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

И подобных фанатов в теме куда больше, чем хейтеров, кричащих, что systemd — по определению решето.

куда больше

А слабо посчитать?

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

По описанию «запускаем и попердолили» трудно сказать.

Ну вот и я не вижу.

Наверное, в «запустить и попердолили» проблем и правда нет. Но задача не в этом.

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

Это ты сейчас к чему? Если что, ребята из glibc в том числе проверяют, что с новой версией ядра сисколы не вносят искажений в работу glibc.

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

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

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

Нет. Потому-что в манах действительно прописаны все допустимые значения, которые действительно стоит проверять (во избежание n > ssize_t, например, который ведет к непойми чему). И да, многие вещи (типа работы с изоляцией) требуют определенных настроек системы, которые тоже учитываются при тестировании (вплоть до проверок, доступен ли тебе вообще сисколл). Я так понимаю, в твоей конторе тестировщиков нет?

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

Ты контролируешь чужой софт? Нет? Тогда результат может быть любым. Ты может либо провести в разумных пределах тестирование своего софта, либо заявить, что ты д'Артаньян. Разумные пределы определяются ожидаемым от софта поведением. А теперь ролевая модель: ты продаешь сборку за деньги. И тут в твоей сборке дыра, причем проявляющаяся при использовании программы, разрабатывающейся у тобой же. Расскажи нам, как ты собираешься рассказывать заказчикам, что виноват не ты, а непонятный хер с горы, потому что его софт не так работает.

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

Расскажи нам, как ты собираешься рассказывать заказчикам, что виноват не ты, а непонятный хер с горы, потому что его софт не так работает.

А что в этом сложного? «Виноваты вон те парни, но мы можем сделать заплату, если вы пожелаете». Дело житейское. Только не рассказывай про возмещение заказчику убытков и судебную ответственность - не только у заказчика есть юристы.

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

Если не использовать sudo, потребует пароль:

root@devuan:~# su testingu
$ whoami
testingu
$ pkexec /bin/bash

(process:23938): GLib-GObject-WARNING **: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/bin/bash' as the super user
Authenticating as: root
Password: 

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

Не понял, раскрой.

См. выше.

Работает ли mysql-юнит с такой-то версией systemd - это тоже интеграционный тест. Но по умолчанию его никто не будет делать на стороне systemd. Потому что таких интеграций можно придумать миллионы.

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

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

Поэтому они напихали столько фичей, что не могут их нормально протестировать, и теперь постоянно вляпываются в глупые баги?

Что ж так тебя плющит-то. Ничего глупого нет в баге в стороннем сервисе. Баг как баг.

И те три «постоянно», про которые тут были баталии до того, точно также никакими «глупыми багами» не были.

Глупая тут только истерия, которая мешает вникать в подробности.

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

Нет.

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

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

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

Нет, это твои слова. Мои слова были про тестирование.

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

А я бы пошел еще дальше. Ведь это спо. Никто никому ничего не должен. Значит, и разрабы чужой софтины никому ничего не должны. А значит, их софт работает так, как работает.

anonymous
()

в первую очередь хочу заявить, что да, системд - говно, но это очевидно :)

а вот, что получается:

sbauer@metabook ~/devel/DE1-SOC/linux-socfpga-4.4 {socfpga-4.4}$ sudo useradd -u 4000000000 testpolit
sbauer@metabook ~/devel/DE1-SOC/linux-socfpga-4.4 {socfpga-4.4}$ sudo su - testpolit
Каталог отсутствует или недоступен, вход в систему выполняется с HOME=/
$ pkexec bash

(process:9277): GLib-GObject-WARNING **: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
**
ERROR:../../../src/programs/pkexec.c:692:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
Aborted
$ logout

но
sbauer@metabook ~/devel/DE1-SOC/linux-socfpga-4.4 {socfpga-4.4}$ sudo -u testpolit pkexec /bin/bash

(process:9630): GLib-GObject-WARNING **: value "-294967296" of type 'gint' is invalid or out of range for property 'uid' of type 'gint'
root@metabook:~#

во втором случае да, рута получили, но настораживает безпарольный sudo

p.s. система - devuan ascii

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

А я бы пошел еще дальше. Ведь это спо. Никто никому ничего не должен. Значит, и разрабы чужой софтины никому ничего не должны. А значит, их софт работает так, как работает.

А кто спорит? Это правда не отменяет того факта, что можно делать выводы о том, как именно он работает.

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

Это я к писал к утверждению про использование чужих софтин в своем комбайне. И к тестированию.

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

Их программный продукт работает правильно:
спрашивает у polkit, можно ли пользователю запустить данную операцию;
получает ответ, что можно;
запускает операцию.
В чём здесь, по-вашему, ошибка?

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

То есть софт должен сам проверять, допустима ли запрошенная операция, игнорируя ответ других системных компонент. Так и представляю себе: ls, вместо того, чтобы показать список файлов и директорий, лезет в сеть в хранилище ldap и начинает выяснять, а пользователь, который её выpвал, вообще существует?

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

То есть софт должен сам проверять, допустима ли запрошенная операция, игнорируя ответ других системных компонент. Так и представляю себе: ls, вместо того, чтобы показать список файлов и директорий, лезет в сеть в хранилище ldap и начинает выяснять, а пользователь, который её выpвал, вообще существует?

Нет, не должен, откуда ты это взял? Я про тестирование говорю. Ну, знаешь, нормальные разработчики такое проводят перед выпуском релиза :)

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

Ну, знаешь, нормальные разработчики такое проводят перед выпуском релиза

Так почему тогда претензии к разработчикам systemd, а не к разработчикам bash? Ведь это bash, получив строку с командой, позволяет получить привилегии администратора? Значит разработчики bash должны были протестировать такое поведение.

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

Так почему тогда претензии к разработчикам systemd, а не к разработчикам bash? Ведь это bash, получив строку с командой, позволяет получить привилегии администратора? Значит разработчики bash должны были протестировать такое поведение.

Это все Гитлер виноват.

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

нет, не значит

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

А в этом здесь косяк. Но я бы не стал говорить, что это косяк баша. Уязвимость в ядре, увы.

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

шапконаркоман о токсичной атмосфере

made my day

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

И подобных фанатов в теме куда больше, чем хейтеров, кричащих, что systemd — по определению решето.

А слабо посчитать?

Ну вот посчитал среди первых 300 сообщений тех, кто говорил (или намекал/язвил/и т. д.) о том, что таких uid не бывает, а значит всё это ерунда. Считал только уникальных юзеров (без повторений тех же мыслей теми же людьми) и только о невозможности таких uid, а не какие-то другие сообщения в защиту systemd (например, о том, что виноват на самом деле polkit). Всего среди первых 300 насчитал 13 таких уникальных сообщений. Вот список:

  1. На один хост логинилась половина населения земли и его взломали? Теперь-то мы точно все умрем.

    (tailgunner ★★★★★ (11.12.2018 15:07:32))
  2. Я такие UID встречал только у пользователей из LXC контейнеров, так они выглядят снаружи. Но пока не придумал, как это использовать изнутри контейнера.

    (ls-h ★★★ (11.12.2018 15:09:19))
  3. Половина населения земли? Я ставлю на одного наркомана =)

    (t184256 ★★★★★ (11.12.2018 15:09:31))
  4. так это бэкдур от наркоконтроля?

    (anonymous (11.12.2018 15:10:59))
  5. позволяет пользователю, чей UID превышает 2147483647

    дальше не читал.

    (mos ★★★★★ (11.12.2018 15:33:25))
  6. Какая ужасная уязвимость. А если пользователю дать uid=0, он тоже будет выполнять команды от рута!!11

    (vasily_pupkin ★★★★★ (11.12.2018 15:33:27))
  7. Чтобы такой пользователь существовал, его нужно создать, а чтобы его создать — нужны права root. Если админ идиот, то и эксплоиты не нужны.

    (mord0d (11.12.2018 15:36:48))

    Проблема, описанная в новости, практически невозможна, а потому повод высосан из пальца.

    (mord0d (11.12.2018 15:38:54))
  8. А разве есть такие «мудрые одмины», которые такие UID или UID делают?

    (mango ★★ (11.12.2018 15:55:45))
  9. Стесняюсь спросить, что надо сделать с линуксом, чтобы там появилось больше 2147483647 UID'ов?

    (ncrmnt ★★★★★ (11.12.2018 17:10:37))
  10. Не совсем понятно, а где в редхате предполагается создание юзеров с отрицательными уидами или уидом в 4000000000? Даже winbind такие диапазоны не использует имхо.

    (AVL2 ★★★★★ (11.12.2018 17:20:27))
  11. так у тебя что нет пользователя с UID превышающими 2147483647? ну ты лошара ваще..

    (Thero ★★★★★ (11.12.2018 19:00:07))
  12. Опять таки, если не рутом, то кем внесется пользователь с таким uid

    (sehellion ★★★★★ (11.12.2018 20:58:04))
  13. Я думал ерунда... А потом прочитал:

    не создавать аккаунты с отрицательными значениями UID или UID превышающими 2147483647

    и уполз под стол.

    (kirill_rrr ★★★★★ (11.12.2018 22:37:28))

Теперь предлагаю тебе посчитать среди тех же первых 300 сообщений неаргументированные уникальные сообщения типа «сустемд решето ще то», не включая, разумеется, сообщения аргументированные, и вывести приблизительно в таком же формате, как у меня, чтоб легко было проверить.

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

нет, но насторажило не то, что sudo пароль не просил (так и должно быть - ноут «однопользовательский»)

просто, нужно было проверять без sudo, а как-нить через «su -l testpolkit -c /bin/bash»

[upd]
но

sbauer@metabook ~/devel$ sudo useradd -u 4000000000 testpolit
sbauer@metabook ~/devel$ su -l testpolit -c /bin/bash
Password:

так что бага не стоит выеденного яйца

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

то есть ты не отличаешь «невозможность» от «редкости», а «фанатов кричащих что не баг» от людей которые пишут что-то на тему «забавный баг, не знал что такие uid бывают».

Ни один из перечисленных тобой примеров не утверждает что описанная ситуация не баг. Поэтому найденное тобой количество примеров - 0.

и ноль не может быть «куда больше».

ЧТД.

alpha ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.