Comments 35
Напоминает открытие пивной бутылки об любой угол, даже об глаз.
А мне вот пример
preg_replace('/.*/e', 'print("Test")', ''); понравился. Не зная всех ключей, интуитивно можно не догадаться что этот код исполняемый.
в документации к этому модификатору куча предупреждений, одно из которых советует вообще не использовать оный.
Особенно, если зашифровать второй аргумент, к примеру, base64.
Этот ключ Deprecated в PHP 5.5
UFO just landed and posted this here
Сталкивался с тем, что многие хостеры такие штуки начали запрещать фильтрами mod_security на уровне Апача (комменты в assert(), eval(), всякое подобное).
Наткнулся случайно, когда вдруг внезапно у клиента стал помирать рабочий скрипт с дебаг-кодом с assert()'ами. Хостеры (godaddy кстати) потом раскололись и рассказали.
Наткнулся случайно, когда вдруг внезапно у клиента стал помирать рабочий скрипт с дебаг-кодом с assert()'ами. Хостеры (godaddy кстати) потом раскололись и рассказали.
Сейчас функции запрещают в настройках suhosin (настройки suhosin.executor.func.blacklist, suhosin.executor.eval.blacklist), можно даже мофификатор /e запретить (http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.disable_emodifier). Ну либо отключать функции через disable_functions в php.ini, лишь бы доступ к нему был на хостинге.
А suhosin разве еще жив?
Не то что жив, во многих дистрибах по умолчанию с php ставится.
Там же последняя версия подо что-то из раннего PHP 5.3, которое уже все, емнип, в этом году.
Ну дык и дистрибы на серверах (не говоря уже о ленивых хостерах) не всегда самые модные и последние. Как говориться пока работает — лучше не трогать.
Дело не в модности а в уязвимостях. Для 5.3 уже и так почти ничего не коммитят, а скоро даже секурити-фиксов не будет.
Когда не будет фиксов и если админам не всеравно, тогда и буду обновляться. Только вот на каком нибудь shared hosting страшно наверное это делать. У юзеров че нить поломается и разгребай потом кучу негатива в саппорте. Да и вообще разные ситуации бывают.
зы: глянул у себя интереса ради, по дефолту ниже 5.4.4 нет, если не считать старой VPS-ки, где 5.2 еще.
зы: глянул у себя интереса ради, по дефолту ниже 5.4.4 нет, если не считать старой VPS-ки, где 5.2 еще.
На shared'ах нормальные хостеры обычно за несколько месяцев рассылку клиентам делают.
Не в курсе, давно не пользуюсь, но N лет назад было так: хостер поменяет конфиг/версию и сиди ковыряй клиентские сайты с горой варнингов и фатал ерроров. Даже если предупреждает — хрен знает кто что кому и как накодил и CMS-ки мало кто обновляет, как и фреймворки и прочее. Короче непредсказуемая это штука — поменять версию и настройки так, чтоб ни у кого и ничего не поломалось.
RHEL? Centos?
Для них секьюрити-фиксы будут.
Для них секьюрити-фиксы будут.
Прочитал статью, понял, что ещё час придётся от последнего «защищать» проект…
По моему когда залили шелл — не надо сидеть и изучать сам шелл. Надо узнать как его собственно залили и исправить дырку в безопасности. А убрать шелл —
git reset --hard
Однажды видел на сервере PHP-шелл, подключенный через .htaccess:
php_value auto_append_file "/path/to/shell.php"
Еще в копилку, хоть это и вызов shell_exec, а не php-кода, но оператор backticks тоже надо иметь ввиду:
`$_GET['c']`;
Вы бы все функции, которые с коллбеками работают в один пример объединили бы. Во-первых, это по сути один приём, во-вторых, вы всё равно далеко не все перечислили.
Красивое решение под номером 8.
Sign up to leave a comment.
Приемы неявного вызова php кода, применяемые во вредоносных скриптах