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

/vendor/microsoft/

Дело раскрыто.

В случае установки в контейнере эти переменные могут содержать конфиденциальные данные, такие как пароль администратора ownCloud, учетные данные почтового сервера и другую информацию.

🤡

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

Держи нас в курсе этой очень важной проблемы

«И всё бы мне сошло с рук, если бы не вы, назойливые линуксоиды!»

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

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

Я и говорю - 🤡.

microsoft/microsoft-graph

.php

#

такой подход вполне нормальный с точки зрения секурности (переменные окружения доступны только самому процессу). через аргументы - вот это не секурно, ибо любой ps может прочитать их. через конфиг - геморно. посему и адресую свой риторический вопрос авторам пхп.

Сначала взволновался и полез проверять, а потом вспомнил, что давно переехал на nextcoud. Ну и ладно, и хрен с ним.

переменные окружения доступны только самому процессу

Вот тут спорно. Я знаю, что сервисы CI обычно имеют функцию скрывать «чувствительную информацию» из переменных окружения, когда она содержится в выводе.

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

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

Основываясь на запросе, подписанном ещё одной парой ключей, которая хранится внутри контейнера, контейнер в утке, утка в зайце, заяц в железном сундуке, сундук на крепкий замок закрыт и закопан под серверной.

Сосурити-театр как он есть. А в итоге имеем

GET /parol_admina HTTP/1.1

200 OK
Четыре сбоку - ваших нет!

phpinfo это отладочная функция, для использования в проде она не предназначена. Выдавать она может что угодно, в т.ч. пароли от базы если они в php.ini прописаны.

Переменные окружения видны не сильно меньше чем командная строка.

Им еще кто-то пользуется? Сейчас nextcloud актуален же.

Можно подробнее? Как получить доступ к переменным окружения стороннего процесса не имея рута?

(переменные окружения доступны только самому процессу).

…и (обычно) всем его детям.

в некстклауде такого нет, ща проверил. Хотя вроде то ли одно форк другого, то ли наоборот.

тут правильнее сказать - всем процессам этого пользователя, а не детям.

• https://apps.nextcloud.com/?search=graphapi
• https://marketplace.owncloud.com/apps/graphapi

Это всё, что нужно знать о разнице между nextcloud и owncloud.

Так это стороннее приложение.

Тесты вообще в отдельной репе надо хранить

cat /proc/<pid>/environ

Да и в целом оно же в памяти процесса лежит в незащищенном виде. Нашел RCE считай все секреты утекли

cat /proc/<pid>/environ

свои процессы, да, можешь прочитать.

Нашел RCE считай все секреты утекли

боюсь, в этом случае уже без разницы где и как хранить чувствительную информацию )))

Так и список выдаваемый ps обрезается до процессов, которыми владеет пользователь. Смысл тогда прятать командную строку?

Так и список выдаваемый ps обрезается до процессов, которыми владеет пользователь.

ты троллишь или реально не знаешь? ps ax выводит все процессы с аргументами. по этой причине нельзя использовать чувствительную информацию в аргументах и зачастую ее размещают в переменных окружения.

mount -o remount,hidepid=2 /proc

И не показывает

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

В нормальных системах стоит security.bsd.see_other_uids=0 и командную строку не своих процессов тоже не увидеть.

я не знаю что такое «нормальная система» и мы говорим про линукс ))). в линуксе отрезание инфы в procfs приводит к нежелательным последствиям. судя по манам «нормальной системы» установка security.bsd.see_other_uids=0 приводит к…

Now normal users cannot see what other people or groups are running on the system by using the ps command, top command, and other FreeBSD commands.

это такой же костыль как и с опцией монтирования procfs. так что в «нормальных системах» те же яйца, вид с боку.

А, я думал что hidepid вообще все процессовые директории прячет. Почитал ман, оказывается там всё норм и прячутся только те куда не должно быть доступа. Тогда непонятен твой наезд на него.

PHP

Ясно, понятно.

oudClown 🤡

просто принять

Бро, тут технический сайт, а не семинария

там не все норм. с hidepid=2 поплохеет тулзам типа ps/htop и тд, мониторинговым тулзам, системным типа dbus/systemd. это тем, что наверняка. думаю список будет достаточный, чтобы забыть про эту опцию монтирования.

Бро, тут технический сайт, а не семинария

Бро

Юноша, это технический сайт, а не подворотня.

Что значит поплохеет? Ты настроил чтоб юзеру показывались только его процессы - ps их показывать и будет. Всё как задумано. Если нужно увидеть всё - для этого, строго для тех кому можно, и рандомное ps запущеное непонятно кем к таковым не относятся, есть рут и suid-обёртки. systemd тут вообще ни при чём, он работает от рута и его это не касается никаким боком (но я всё-таки не забуду наоффтопить что он ненужен).

Почитай внимательно, о чем пишут ребята с более глубоким пониманием предмета:

RHEL systemd Engineering considers that using hidepid=2 is not recommended at all on RHEL7 and later due to many reasons exposed below.

The main purpose of the hidepid= mount option is the ability to not disclose information (to the given user) about processes of other users running on the same system.

There are at least three problems that arise when this option is used.

First, the proc filesystem mount is a global entity that exists inside a given mount namespace. Hence, if any mount option is used on proc filesystem mount then it affects every process which runs in the same filesystem namespace. In many cases this is not desirable and causes further issues.

Previous issue leads to the second problem. If hidepid= option is used then some system services like (PolicyKit or D-Bus) are not able to query information about the clients which are connecting to them. This is because all these services run as non-privileged (i.e. euid != 0) and hence don’t see needed information in /proc/[pid] directory of the client, unless the client runs under the same uid which is never the case (at least for PolicyKit and D-Bus).

Last problem, that we would like to highlight is potential information leak and false sense of security that hidepid= provides. Information (PID numbers, command line arguments, UID and GID) about system services are tracked by systemd. By default this information is available to everyone to read via systemd’s D-Bus interface. When hidepid= option is used systemd doesn’t take it into consideration and still exposes all this information at the API level.

Because of these issues we don’t recommend at this time using hidepid= option on RHEL7 and later.

This guidance may change in future as we work on improvements to kernel’s proc filesystem implementation as well as on systemd and other system services (e.g. PolicyKit and D-Bus) that are negatively affected by enabling hidepid= mount option.

ребята с более глубоким пониманием предмета

Я рад за них, что у них есть такой преданный фанат как ты. Но твоё восхищение их глубоким пониманием разделить не могу. «Ребята с глубоким пониманием» не стали бы ненужнод внедрять например.

И ты сам то читал свою простыню?

Пересказываю:

1) Всё это написано только про шапку7

2) Общая боязнь того что вдруг что-нить сломается

3) Ненужный policykit и кривой dbus (впрочем нужность тоже сомнительна) что-то там не смогут узнать. Ну про первое и говорить нечего, а насчёт второго - они видимо не осилили нормальное управление доступами и поэтому давайте откроем их всем (прям как chmod 777).

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

5) «мы работаем над этим»

OddClown

cat /proc//environ

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

оно то да, но аргументация что env секурнее чем параметры командной строки вызывает недоумение. Типа не мозолит глаза в выводе top и ps и ок. Это профанация, а не безопасность

Это такая себе уязвимость. У многих .git наружу торчит и всякие .env и docker-compose.yml, не говоря уже, что есть миллионы сайтов, где пхпмакаки по традиции размещают в корне файл phpinfo.php. Зачем? - Не знаю! Я сам одно время баловался пиэйчпи, но слава богу пересел на метад… программирование и теперь радуюс жизни (шютка)

Чаще заглядывай в /robots.txt там за каким-то указывают адреса админок для брута и места, где хранятся бекапы, иногда их имена 🤡

Да в докер-контейнеры… Проблема только в том, что для пхп скриптов конфиги прописывают в config.php + никто этот клоунклауд сам упаковывать не будет, есть готовый образ и там через переменные окружения не передается НИЧЕГО. «Критическая» уязвимость, которой бы я присвоил 0/10. Создатель курла вроде жаловался на дебилоцвешников, которые нашли такую же 9/10 мегакрЕтиНИческую уязвимость

В случае установки в контейнере эти переменные могут содержать конфиденциальные данные

«Микроинстансы, масштабируемость, изоляция, безопасность», — говорили они…

С безопасностью всё понятно. Ждём разоблачения более лучшей масштабируемости софта в доцкере от самих же докерофилов.

Тоже на nextcloud уже не помню сколько лет.