Накратко: Актуализацията на WordPress не помага срещу PHP уязвимостта PHP2Shell, защото грешката не е в WordPress, а в PHP, софтуера на сървъра, който изпълнява WordPress. Според Dr. Web затова WordPress.org не планира и собствена актуализация. Защитава само PHP актуализация на сървъра с рестарт на всички PHP процеси. Тя по правило се инсталира от Вашия хостинг доставчик или оператор на сървъра.
Поводът: „Нали актуализирахме всичко“
След първите заглавия за PHP2Shell много оператори направиха очевидното: отвориха таблото на WordPress, натиснаха „Актуализирай сега“, а заедно с това и добавките и темите. След това всичко е зелено и усещането казва: готово.
При тази уязвимост усещането лъже. Това не е заради WordPress, а заради мястото, където е грешката. И Cloudflare в съобщението си посочва, че актуализация на кода на приложението или на добавките не отстранява уязвимостите.
Актуализация на WordPress и PHP уязвимост: моделът на слоевете
Един уебсайт на WordPress се състои от няколко слоя, които се надграждат един върху друг. Всеки слой има собствени актуализации и често собствени отговорници:
| Слой | Пример | Кой типично актуализира | Засегнат ли е от PHP2Shell? |
|---|---|---|---|
| Операционна система | Debian, Ubuntu, AlmaLinux | хостинг доставчик или администратор на сървъра | не, но често доставя PHP пакета |
| Уеб сървър | Apache, Nginx, LiteSpeed | хостинг доставчик или администратор на сървъра | режимът на работа влияе на риска |
| PHP среда за изпълнение | PHP-FPM, mod_php | хостинг доставчик или администратор на сървъра | да, тук е уязвимостта |
| Ядро на WordPress | WordPress | оператор или агенция | не |
| Добавки и теми | WooCommerce, Page-Builder | оператор или агенция | не |
Бутонът за актуализация в таблото достига само долните два реда. PHP средата за изпълнение е под тях и за WordPress е невидима. Как други системи се надграждат върху PHP, описва статията CMS и магазини върху PHP.
Защо WordPress не може да затвори уязвимостта
Може да се помисли, че WordPress може да „програмира около проблема“. При PHP2Shell това не работи по две причини.
Първо, и двете грешки са в начина, по който PHP обработва заявките и след това почиства. Това се случва независимо коя програма работи в PHP. Второ, PHP екипът е показал за Apache с mod_php експлойт, който действа, преди изобщо да се изпълни код на приложението. WordPress, добавките му и всяка добавка за сигурност тогава изобщо не стигат до изпълнение.
По същата причина не помага и никаква „добавка за заздравяване“, която променя настройки чрез ini_set(). php.net изрично съветва временните мерки да не се задават по този начин.
А при управляван WordPress?
При предложения за управляван WordPress доставчикът често се грижи не само за актуализациите на WordPress, но и за сървъра под него. За PHP2Shell това е предимство, но не автоматизъм. Питайте конкретно дали PHP актуализацията е инсталирана и всички PHP процеси са рестартирани. Твърдението „Поддържаме Вашия WordPress актуален“ не отговаря на този въпрос.
Много уебсайтове, една PHP инсталация
Агенциите и фирмите с няколко уебсайта трябва да знаят една особеност: на един сървър често много инсталации на WordPress споделят една и съща PHP версия. Ако тя е непачната, всички са засегнати, независимо колко добре е поддържан всеки отделен уебсайт. Обратно, една PHP актуализация защитава всички инсталации наведнъж, при условие че след това всички принадлежащи PHP процеси са рестартирани. Който работи с няколко PHP версии паралелно, трябва да актуализира всяка поотделно.
Зелено табло на WordPress не казва нищо за PHP2Shell. Решаващо е състоянието на пача на PHP на сървъра и рестартът на всички PHP процеси.
Как да прочетете правилно PHP версията в WordPress
WordPress показва PHP версията: в таблото под Инструменти, Състояние на сайта, в раздела Информация при секцията Сървър. Това е добра първа индикация, но не е доказателство.
Ако там стои клон като 8.1 или по-стар, това е ясен предупредителен сигнал, защото за него вече няма официални актуализации. Ако там стои 8.2.35, 8.3.36, 8.4.27 или 8.5.12, поправеното състояние е инсталирано. Ако там стои по-стар номер на поддържан клон, въпреки това може да е инсталиран backport. Дистрибуциите и хостинг доставчиците при това често не променят номера. Яснота дава само потвърждението на хостинг доставчика или поглед в changelog-а на пакета. Как се прави това, пише в Проверка на PHP версията и състоянието на пача.
Какво да направят вместо това операторите на WordPress
- Питайте хостинг доставчика или оператора на сървъра: PHP пачнат ли е, кога и рестартирани ли са всички PHP процеси? Отговор писмено.
- Проверете PHP клона: Ако уебсайтът работи на 8.1 или по-стар, планирайте преминаване към поддържан клон. Коя версия поддържа Вашата версия на WordPress, пише в системните изисквания на wordpress.org. Смяната в клиентското меню описва Смяна на PHP версията в клиентската зона на хостинга.
- Проверете за следи: нови PHP файлове в
wp-content/uploads, непознати администраторски акаунти, чужди записи вmu-plugins. Типичните скривалища описва страницата WordPress и PHP2Shell. - Въпреки това поддържайте WordPress актуален: Ядрото, добавките и темите затварят други уязвимости. Това остава задължение, само че друго.
- Изяснете отговорността: Ако агенция поддържа уебсайта, запишете дали тя отговаря и за PHP, или само за WordPress.
Именно последната точка често създава пролуки. Агенцията поддържа WordPress, хостинг доставчикът сървъра, и всеки вярва, че другият следи PHP2Shell.
Как помага PHP SOS конкретно?
- Изясняване на слоевете: Установяваме кой при Вашия уебсайт на WordPress за кой слой отговаря.
- Актуализиране на PHP: На собствени или управлявани сървъри инсталираме PHP актуализацията и рестартираме всички процеси.
- Проверка на WordPress: Търсим следи от атака във файловете, базата данни и акаунтите.
- Доказателство: Получавате състоянието на пача писмено, също и за предаване на агенция или клиенти.
Процесът описва услугата за пач на PHP.
Заключение
Актуализацията на WordPress е добра поддръжка, но срещу PHP2Shell е грешният слой. Уязвимостта е един етаж по-надолу, в PHP на сървъра. Който разбира това, задава правилния въпрос на правилното място: PHP пачнат ли е, рестартиран ли е и доказано ли е?
Често задавани въпроси
Излиза ли актуализация на WordPress за сигурност срещу PHP2Shell?
Според Dr. Web WordPress.org не планира актуализация срещу PHP2Shell, защото уязвимостта е в PHP интерпретатора на сървъра. Помага само PHP актуализация от хостинг доставчика или оператора на сървъра.
Къде виждам PHP версията в WordPress?
В таблото под Инструменти, Състояние на сайта, в раздела Информация при секцията Сървър. Показаният номер обаче не казва със сигурност дали пачът е инсталиран, защото хостинг доставчиците често вграждат поправките като backport без нов номер на версията.
Защитава ли добавка за сигурност от PHP2Shell?
Само много ограничено. Една добавка сама работи в PHP и става активна едва след като WordPress е зареден. При Apache с mod_php според PHP екипа е показан експлойт още преди изобщо да се изпълни кодът на приложението. Там добавката не може да се намеси.
Да актуализирам ли WordPress въпреки това?
Да. Актуалните версии на WordPress, темите и добавките затварят други уязвимости и са част от добрата поддръжка. Те просто не решават проблема PHP2Shell.