LINUX.ORG.RU

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

 , , ,


1

2

Уязвимость в компоненте pkexec пакета Polkit, идентифицированная как CVE-2021-4034 (PwnKit), присутствует в конфигурации всех основных дистрибутивов Linux и может быть использована для получения привилегий root в системе, предупреждают исследователи из Qualys.

Уязвимый участок кода был отслежен до начального коммита pkexec, более 12 лет назад, что означает, что все текущие версии Polkit затронуты.

Бхарат Джоги, директор по исследованию уязвимостей и угроз в Qualys, пояснил, что PwnKit — это «уязвимость повреждения памяти в Polkit, которая позволяет любому непривилегированному пользователю получить полные привилегии root на уязвимой системе, при использовании конфигурации Polkit по умолчанию».

Код эксплойта для доказательства концепции (PoC), уже стал общедоступным.

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

★★★★☆

Проверено: cetjs2 ()
Последнее исправление: maxcom (всего исправлений: 7)

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

Посоны похоже линуксы ушли переустанавливать

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

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

А какими сёвыми средствами можно предотвратить твой тупняк?

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

Центральный оффициальный репозиторий программ

В. Янукович, проффесор.

anonymous
()

Все дружненько переводим десктопы на OS Haiku !!!

GTK3 в ней уже из каропки/из репы ставится ровненько - GIMP и Inkscape …..

Qt5 и Qt6 давно завезли. OpenJDK есть.

WINE 6 на подходе в продакшен…..

https://t.me/haiku_ru

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

В клетке по умолчанию у тебя иксы не стартанут. На счёт вялого не знаю, у меня нормальная ориентация.

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

Я имел в виду этот камент. У меня вообще ощущение, что тупорылая виндошколота, добравшись до юникса, напихала туда всякого нахрен ненужного корявого говна чисто по NIH-принципу.

Довольно верно подмечено, в принципе согласен.
Держи ящик пива.

Добавлю ещё подробнее про протоносекту и игрорадости. Идиоты.

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

Какой самый удобный формат для написания и просмотра правил контроля доступа?

Обновление Fedora в KDE Plasma 5 (комментарий)

systemd, dbus, polkitd+JS не нужны совсем:

Обновление Fedora в KDE Plasma 5 (комментарий)

Обновление Fedora в KDE Plasma 5 (комментарий)

Обновление Fedora в KDE Plasma 5 (комментарий)

Обновление Fedora в KDE Plasma 5 (комментарий)

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

Нет, в головах разрабов Haiku таки до сих пор отсутствует понимание самой необходимости DAC в OS: https://discuss.haiku-os.org/t/multi-user-support/11099/7

Не важно, что только один пользователь работает за компом. Все равно OS должна обеспечивать разделение прав с дискретностью хотя бы по пользователям (DAC):

  1. Проведении ядра

  2. Привилегии администратора

  3. Привилегии пользователя

  4. Привилегии сервисов

Еще желательно иметь возможность выделять частично привилегии некоторым программа, с дискретностью программа, процес (CAP).

  1. ping

  2. Запись CD/DVD

Чтобы не давать всего рута с помощью SUID.

Уровень безопасности в OS Haiku - никакой.

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

Отважный анонимус!

Хвала твоей гордыне не иссякнет в рядах юзверей.

Зайди в чат/на форум и вправь мозги разрабам OS Haiku - укажи верный путь товарисчам!!!

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

doas — это, конечно, лучше чем sudo, а sudo лучше чем polkit. Но можно ещё проще, и без игр с потенциально небезопасным повышением привилегий. Вот так сделано в OpenBSD:

$ ls -l /sbin/shutdown
-r-sr-x---  1 root  operator  276024 Jan 15 20:56 /sbin/shutdown

Достаточно просто добавить юзера, которому позволено делать shutdown, в группу operator:

# usermod -G operator user
aeralahthu
()

Почему-то никто не подчеркнул, что уязвимостей подобного типа в вашей системе прямо сейчас десяток-другой, но вы о них не знаете, и вопрос лишь в том. кто быстрее о них узнает — вы или хакер. Это прямое следствие упарывания сишкой. Написанная на Си система не бывает безопасной. Точка. В лине точно так же по 12 лет лежат уязвимости повышения прав, а потом «ой, у нас с 2.6.27 по 4.20.17 дыра в драйвере IPv6, советуем срочно пропатчиться».

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

вопрос лишь в том. кто быстрее о них узнает — вы или хакер

Подчёркиваю: злоумышоенник уже́ знает про эти уязвимости.

Сишка ни при чём. На любом языке можно писать глупости. У тебя, вон, даже на русском это неплохо получается xD

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

doas — это, конечно, лучше чем sudo, а sudo лучше чем polkit

Спорно. Никакого конечно тут быть не может.

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

Сишка ни при чём. На любом языке можно писать глупости. У тебя, вон, даже на русском это неплохо получается xD

Чтобы «на любом языке» написать удаленное выполнение кода, нужно сделать вполне явный eval/exec. Чтобы написать удаленное выполнение кода на сишке, не нужно делать ничего — просто пиши любой сетевой код. Java получила свою популярность не потому, что она такая замечательная, а потому что реальной альтернативой в конце 90-х/начале нулевых был только C/C++, а любой сервис на C/C++ — это одна сплошная дыра в безопасности, в то время, как ошибки логики на жаве в большинстве случаев не представляет угрозы.

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

Критическая уязвимость в Log4j позволяет выполнять произвольный код на сервере

Это тот самый случай exec/eval, когда рукожопый разраб написал запуск на выполнение рандомных строк из логов. Но это исключение, а выполнение кода в сишке — это правило.

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

Интересно, а ФСТЕК вообще

Конечно нет, что ты как маленький. У меня когда-то очень давно (ну да, лет двадцать тому, но что-то я сомневаюсь, что с тех пор что-то изменилось) они не заметили открытый TCP-порт, через который можно было с софтиной сделать что угодно. Ну, типа, одни (вот прямо-таки лично я) этот порт придумали, другие не успели его внести в документацию, а третьи, не спросивши первых двух, отправили софтину сертифицироваться на отсутствие незадекларированных возможностей. Не, ну это была не уязвимость, конечно, и не бекдор, поскольку слушался только localhost, там проверялись всякие пароли и коды и всё такое прочее, но что эта возможность была ‘‘‘незадекларирована’’’ – ну вот просто-таки факт.

Но дело даже не в этом. Тут есть кто-нибудь, кто реально верит в саму физическую возможность «проверить» софтину?

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

Тут есть кто-нибудь, кто реально верит в саму физическую возможность «проверить» софтину?

Теоретически, если очень надо, то можно наверно. Только надо проверять всё с самого начала - с самого ядра, всех библиотек, всё документировать, лишнее выкидывать. Но это долго, дорого и умных спецов наверно нет... :(

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

Java получила свою популярность не потому, что она такая замечательная, а потому что реальной альтернативой в конце 90-х/начале нулевых был только C/C++, а любой сервис на C/C++ — это одна сплошная дыра в безопасности, в то время, как ошибки логики на жаве в большинстве случаев не представляет угрозы.

Тут есть одна проблемка. Знаешь, на чём JVM написана?

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

умных спецов наверно нет… :(

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

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

Тут есть одна проблемка. Знаешь, на чём JVM написана?

Знаю, только риски на порядки ниже, по соотношению объема сишного кода. По этой же причине среднее приложение на C# менее безопасно — шарп сильно полагается на нативные либы, как тот же питон. И по этой же причине питон еще менее безопасен, чем шарп — потому что питон вообще весь слеплен из сишки, и даже то, что могло бы быть написано на питоне, все равно написано на сишке.

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

Самые умные спецы из известных мне, причём реально оказывавшие услуги security audit, всегда утверждали, что отрицательный результат аудита означает лишь то, что лично они уязвимостей не обнаружили, но вовсе не то, что их нет

Есть разная степень такой уверенности. Когда у тебя система начинается с неотключаемого аппаратного бэкдора в каждом компьютере, то о каких гарантиях безопасности может идти речь? Слишком много неизвестных, но отсюда не следует вывод, что с этим ничего нельзя сделать, мол «все равно все умрём будем взломаны».

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

Java

Ясно, сектант в треде. Притом ещё толком и не разобравшийся. «Уязвимость» в polkit — это всего лишь симптом. Настоящая уязвимость — в glibc, которая толком не подчищая переменные окружения вызывает из экзешников с suid что попало.

А жабка популярна лишь потому, что её насильно везде пиарят и пихают с самого рождения. Да и не популярнее уж сишечки-то будет. Чем ты этот факт объяснишь? А он объясняется очень просто: на жабе криворукние макаки пишут софт, который никому не упёрся, кроме заказчика, а на Си — нормальные пацаны пишут реальные программы, которые реально используются. Джова с её багами — она как неуловимый Джо из анекдота.

Но ты продолжай слепо веровать в чистоту и непорочность этого проприетарного поделия. Небось и в исходники-то даже ни разу не заглядывал? Да и где бы была твоя жаба, если бы не Си? А её не было бы! До сих пор, вон, в исходниках полно «позорного сишного» кода, ай-ай. Оригинальный Си, к твоему сведению, был написан на асме. Не на жабе. Ахах

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

Ну, и хватит, пожалуй :)

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

Да гугл явно уже сам сто раз пожалел, что связался с этими проприетастами. То-то они свой дротик сейчас везде суют.

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

Настоящая уязвимость — в glibc, которая толком не подчищая переменные окружения вызывает из экзешников с suid что попало

То есть, два раунда удаления переменных окружения (ld.so и самим pkexec) — это по-твоему «толком не подчищая», а вот тройные слои никсового наследия вплоть до 70-х годов, в которых чёрт ногу сломит — это норм? И доступ за пределами буфера — тем более норм, всегда так делаю, я же сишник.

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

Это было актуально по состоянию на конец 90-х/начало нулевых. И вообще-то этот занимательный факт на лор я притащил, с конкретными цифрами маркетинговых бюджетов Sun Microsystems.

Да и не популярнее уж сишечки-то будет

По состоянию на 2022? Да. Потому что есть Node.js и Go на серверах.

А он объясняется очень просто: на жабе криворукние макаки пишут софт, который никому не упёрся, кроме заказчика, а на Си — нормальные пацаны пишут реальные программы, которые реально используются

А на Си тоже пишут криворукие макаки софт, который никому не уперся, кроме заказчика. Прикинь.

А сколько в мире существует операционных систем, написанных на жабке? Где же вся эта её немыслимая популярность?

Пхах, 80% мировых смартфонов крутят одну сплошную JVM систему на лине.

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

это по-твоему «толком не подчищая»

Вот, полюбуйтесь, граждане, на логику смузихлёба. Конкретно этот CVE нам и говорит о том, что glibc не стоит доверять любому экзешнику, из которого её вызывают, а следует перепроверять все переменные перед каждым вызовом функции, дёргающей сторонние либы. Очевидно, тех двух раундов недостаточно.

И доступ за пределами буфера

Ой, а расскажи-ка нам как ты получаешь аргументы и переменные окружения со стека, не вылезая за пределы жабского «буфера». Что за интересная там у тебя магия? А что жаба скажет на execv("/usr/bin/java", NULL)? Сегфолтом пукнет поди только?

вообще-то этот занимательный факт на лор я притащил

Да этот факт настолько всем очевиден, что его даже не надо выискивать и притаскивать. Не корпорации бы — и эта жаба ни кому бы не упала.

80% мировых смартфонов крутят одну сплошную JVM систему на лине.

А чего не на JavaOS-то? И что полезного вы там понаписали на эти свои смартфоны? Чатики и прочая мишура, куда не ткни, — на электронах, игры — на юнити. А на жабе что? Прослойка одна только, убери её — и ничего не изменится. Если бы гугл развязал руки разработчикам и не насаждал свои анальные SDK и фреймворки, то никто бы в жизнь с этой прослойкой связываться не стал. Но это же гугл, они любят доминировать. А ты, видимо, любишь когда сзади щекочет.

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

Я даже поставил себе, чтобы проверить:

$ /usr/bin/java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12)
OpenJDK 64-Bit Server VM (build 17.0.1+12, mixed mode)

$ cat test.c
#include <unistd.h>
int main() {
   execv("/usr/bin/java", NULL);
}

$ gcc test.c && ./a.out 
71704 segmentation fault (core dumped)  ./a.out

$ sed -i 's/java/python/' test.c

$ gcc test.c && ./a.out
Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Пхаха. Эпичненько.

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

вправь мозги разрабам OS ****** - укажи верный путь товарисчам

Пусть сами ищут, документация, стандарты, разъяснения все давно есть написано.

А если не хотят? Зачем мне со своим уставом в их монастырь лазить?

ЗЫ: А кто знает название организации в США которая занимается вправлением мозгов разрабам ОС? Требуется обращение разабов ОС в эту организацию и за деньги налогоплательщиков США разрабам профессионально вправят мозги на счет необходимости DAC в ОС.

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

Вот верно все! Не хотят разрабы OS Haiku твои хотелки выполнять.

И нифига с этим делом не поделать. Не заставить. Увы…

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

Конкретно этот CVE нам и говорит о том, что glibc не стоит доверять любому экзешнику, из которого её вызывают, а следует перепроверять все переменные перед каждым вызовом функции, дёргающей сторонние либы

Конкретно этот и десятки других CVE говорят нам, что нужно запрещать setuid на тех системах, где важна безопасность. Другое дело, что если делать повышение прав доступа правильно, то есть, через отправку сообщения системной службе, то поотваливаются горы никсовых костылей, которые городились с 70-х годов и которые опираются на тот факт, что рутовый процесс является дочерним по отношению к запросившему повышение прав процессу, то есть, унаследует дескрипторы пайпов, файлов, сокетов, переменных окружения, и прочей рандомной херни, угрожающей безопасности работы рутового процесса. Это дыра в безопасности by-design, и тот факт, что большинство разрабов научились подставлять достаточное число костылей до исключения векторов атаки, катит лишь как утешение и оправдание.

А что жаба скажет на execv(«/usr/bin/java», NULL)? Сегфолтом пукнет поди только?

Это defined behaviour в жабе, если чо, там разыменование нулевого указателя. Конечно, не считая того, что жаба с setuid вообще не запускается, по крайней мере на дебиане. Если попытаться поставить в argv ненулевой указатель на любую другую недоступную в исходном процессе область памяти, то дочерний процесс вообще не запустится.

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

потому что полкит - это как раз в стиле ленни

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

предотвращается как обычно и везде - хорошими практиками

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

человек почему-то может то, чего принципиально не может

и никогда не сможет компьютер

ну как бы это так и есть. по определению.

или ты из секты швабов-трансгурманистов?

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

same shit:

C:>which java

/usr/bin/java C:>which java

/usr/bin/java

C:>java -version

openjdk version «11.0.14» 2022-01-18 OpenJDK Runtime Environment (build 11.0.14+9-post-Debian-1deb10u1) OpenJDK 64-Bit Server VM (build 11.0.14+9-post-Debian-1deb10u1, mixed mode, sharing)

C:>cat >java-test.c <<EOF

#include <unistd.h>

int main() {

execv(«/usr/bin/java», NULL);

}

C:>gcc java-test.c && ./a.out

Segmentation fault

C:>sed -i ‘s/java/python/’ java-test.c

C:>gcc java-test.c && ./a.out

Python 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0] on linux2

Type «help», «copyright», «credits» or «license» for more information.

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

если чо, там разыменование нулевого указателя

Нет. Агрументы же не по указателю передаются, а складываются на стек и указатель твой не нулевой, а очень даже валидный, указывающий на область стека. Попробуй объявить char* argv[] = {NULL}; и передать её вместо NULL: execv("/usr/bin/java", argv) — будет то же самое.

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

Написанная на Си система не бывает безопасной. Точка.

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

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

Ошибки логики всегда были и будут самой главной угрозой безопасности. Безотносительно языка.

И последний факт, который стоит признать: для Си не существует замены, он с нами навсегда, любим мы его или нет.

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

иии? это что-то поменяло бы в случае данной тестовой программы>

гонишься за Bleeding Edge?

а как насчёт «out of concern that a large body of existing code could not easily be forward-ported to Python 3»?

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

или ты из секты швабов-трансгурманистов?

Нет, я просто материалист. Ну и реалист. Алгоритмическая неразрешимость – штука довольно упрямая, а вот в экстрасенсов, ясновидящих и прочих кикимор с домовыми я не верю, это да.

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