The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в PHP, позволяющая обойти ограничения, заданные в php.ini, opennews (??), 07-Окт-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


11. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +2 +/
Сообщение от Аноним (11), 07-Окт-21, 11:29 
Это бессмысленно, есть миллион способов обойти такие запреты.
Надо запускать от изолированного пользователя в чруте (php-fpm умеет).
От взлома же макакокода типа вордпресс-плагинов не обезопасит ничто, вопрос в том чтобы ущерб был изолирован.
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  –1 +/
Сообщение от привет (ok), 07-Окт-21, 13:03 
пару скиньте способов обойти запрещеные функции (из миллиона) не используя
уязвимостей. Я запишу и буду иметь их ввиду (условие - я могу загрузить свой код на шаред, допустим), open_basedir естественно задействован.

Мне реально интересно тк есть шареды.


Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Аноним (35), 07-Окт-21, 14:59 
Открыть файл в tmpdir, sessiondir или вообще в php://memory, записать туда код, проинклюдить.
Ответить | Правка | Наверх | Cообщить модератору

36. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Аноним (35), 07-Окт-21, 15:00 
Для shared единственное решение с учетом необходимости поддержки htaccess - mpm itk.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

37. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Аноним (35), 07-Окт-21, 15:04 
Ещё можно просто записать в сессию и проинклюдить session file, полный путь к нему вычисляется легко.

Ограничения типа openbasedir обходятся разными стримами, тем же imap+file:/

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

40. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  –2 +/
Сообщение от привет (ok), 07-Окт-21, 15:21 
> Ещё можно просто записать в сессию и проинклюдить session file, полный путь
> к нему вычисляется легко.
> Ограничения типа openbasedir обходятся разными стримами, тем же imap+file:/

долгоже вы гуглили.

сессии на шаредах никто не хранит в файлах, для этого есть специальные обработчики.
tmpdir на шаредах тоже у каждого свой.

imap ? Речь полагаю о CVE-2018-19518 ?

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

Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +2 +/
Сообщение от Аноним (35), 07-Окт-21, 15:54 
Я ничего не минусовал.
Какая разница, свой или чужой tmpdir? Главное чтобы было куда записать. На большинстве хостов вообще всегда можно найти куда, какой-нибудь upload dir с выставленными туда 777, потому что в наркоманской схеме с modphp под юзером капча иначе никак.
Шареды, где сессии не в файлах, можно пересчитать по пальцам.
CVE тот, а сколько ещё стрим врапперов в php? Вы лично все проверили?

Подход с modphp под апачевым юзером и попытки заткнуть дыру фиговым листком в виде open basedir и disabled functions - это как пытаться перечислить места, где в общаге могут спрятать незаконные вещества. Да везде могут.

Либо itk, либо fpm с отдельными пулами, чрутом и каким-нибудь эмулятором htaccess. Все остальное - дыра по определению.

Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 09-Окт-21, 22:54 
itk, да. Лучше пока не придумано.
fpm можно, но в рамках шареда это обречено :D
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Аноним (35), 07-Окт-21, 16:04 
Гуглить мне нафиг не надо, это такие школохостеры гуглят идиотские списки для disabled functions, выпиливая безобидные функции типа parse_ini_file, но оставляя create_function или proc_open. А задизейблить reflection вообще никому в голову не придёт, потому что все di-контейнеры поотваливаются типа ларавела, но через ReflectionFunction прекрасно делается eval.

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

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

96. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 09-Окт-21, 22:52 
Самое поганое - это выпиливание set_time_limit().
Пара новых клиентов таки нарвалась и ноет, но раз давно собирался - на днях буду все версии движка на шаредах патчить, чтобы функция не выпиливалась, но и лимит не меняла.
Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 09-Окт-21, 22:53 
(preload с эмуляцией не предлагать - это отдельные грабли)
Ответить | Правка | Наверх | Cообщить модератору

111. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 11-Окт-21, 23:00 
Слепил мелкопатч, добавляющий опцию strict_time_limit, в три строчки, не считая пустой.

Для 8.0 тут: https://pastebin.com/t8DszAH2
Для остальных лепится по образу и подобию.

Не забываем заодно патчить флаги переменных для ini_set, иначе можно будет объехать через ini_set('max_execution_time'), а отключать ini_set - ну так себе затея, его каждый второй для display_errors использует.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

113. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 11-Окт-21, 23:09 
С другой стороны флаги можно не патчить, а просто забить как admin_value, но я предпочитаю на хостингах оба действия сразу, для надёжности.
Ответить | Правка | Наверх | Cообщить модератору

99. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 09-Окт-21, 22:57 
Сессии на шаредах как раз и хранят в файлах в основном. Потому что это единственный вариант с предсказуемой совместимостью.

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

Как вариант ещё хранить в каком-нибудь KV (memcached например), а блокировать продолжать пустыми файлами, но пока лень возиться с доработкой, всё и так работает.

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

104. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от привет (ok), 11-Окт-21, 10:52 
использую как раз memcached, где это возможно, с проблемами вроде не сталкивался (форумы, разного рода шареды, просто хостинги)
тут, конечно, мильон экспертов локалхоста, но у меня еще и винты шифрованы, потому
иметь большое кол-во мелких и вообщем то ненужных файлов не слишком эффективно для io (на мой, конечно, взгляд), зачем, когда можно иначе.
Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 11-Окт-21, 14:08 
Большинство типового софта на PHP ожидает, что сессия будет блокирующая, и пишет состояние по ходу всего выполнения, получается транзакция. Где не надо - выдаётся session_write_close() эксплицитно. Если сессия неблокирующая - два параллельных сеанса запишут сериализованные данные сессии в неизвестном порядке, более поздняя сессия может отписать данные раньше более ранней, и данные от поздней сессии будут потеряны. Слишком явного проявления у данной фигни может не быть, но более свежие данные от последнего запроса могут теряться.
Ответить | Правка | Наверх | Cообщить модератору

107. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от привет (ok), 11-Окт-21, 15:06 
тут Вы правы, такое действительно может случится, особенно если в сессии счетчики всякие и тп, я как то не сталкивался с подобной проблемой, но информация очень полезна - спасибо,
вообще идеально конечно поюзать редис для этих дел (там есть своя блокировка)
Ответить | Правка | Наверх | Cообщить модератору

108. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 11-Окт-21, 18:27 
С редисом то же самое, что с мускулем - придётся коннект удерживать всё время выполнения скрипта, до session_write_close() или завершения. Короче либо файл, либо пара сокетов к RDBMS/DDBMS/KVDBMS, хрен редьки не слаще. Всё зависит от того, где узкое место.
Ответить | Правка | Наверх | Cообщить модератору

109. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 11-Окт-21, 18:27 
(пара сокетов - в смысле один на запрос на клиенте, один на запрос на сервере)
Ответить | Правка | Наверх | Cообщить модератору

110. "Уязвимость в PHP, позволяющая обойти ограничения, заданные в..."  +/
Сообщение от Онаним (?), 11-Окт-21, 18:31 
Ну и с DBMS обычно выходит неприятно, если они кластерные - нетранзакционные блокировки типа мускульного GET_LOCK() как правило действительны только в пределах ноды, а транзакционные блокировки в кластерных RDBMS как правило разрешаются через lock timeout на коммите, что в случае сессий уже слегка поздновато.
Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру