LINUX.ORG.RU

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

 ,


0

1

В плагине-приложении graphapi обнаружена уязвимость: становится доступен URL: «owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php»

По этому адресу вызывается функция phpinfo, которая раскрывает детали конфигурации PHP. Эта информация включает в себя все переменные окружения веб-сервера. В случае установки в контейнере эти переменные могут содержать конфиденциальные данные, такие как пароль администратора ownCloud, учетные данные почтового сервера и другую информацию.

Всем системным администраторам рекомендовано удалить файл «owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php», а также обновиться и поменять пароли.

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

★★★★★

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

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

🤡

token_polyak ★★★★
()

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

ergo ★★★
()

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

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

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

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

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

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

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

Я и говорю - 🤡.

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

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

ergo ★★★
()

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

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

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

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

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

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

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

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

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

GET /parol_admina HTTP/1.1

200 OK
Четыре сбоку - ваших нет!
token_polyak ★★★★
()
Последнее исправление: token_polyak (всего исправлений: 1)
Ответ на: комментарий от ergo

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

firkax ★★★★★
()

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

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

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

ergo ★★★
()

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

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

cat /proc/<pid>/environ

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

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

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

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

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

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

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

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

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

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

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

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

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

я не знаю что такое «нормальная система» и мы говорим про линукс ))). в линуксе отрезание инфы в 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. так что в «нормальных системах» те же яйца, вид с боку.

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

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

firkax ★★★★★
()

PHP

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

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

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

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

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

Бро

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

cat /proc//environ

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

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

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

cobold ★★★★★
()

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

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

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

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

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

rtxtxtrx
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)

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

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

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

mogwai ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.