Не можете напълно да блокирате двете критични уязвимости в PHP, наречени PHP2Shell, преди днешната корекция, а единствената настройка, разпространявана като временно решение, не е достатъчна сама по себе си, заявява сега компанията за сигурност, която я предложи.

PHP ще пусне корекцията за сигурност в 14:00 UTC на 21 октомври за две уязвимости с оценка 9.2 от 10, като не е предоставила свое собствено временно решение. Докато успеете да я инсталирате, това, което намалява риска за вас, е спирането на достъпа от интернет до откритите PHP системи или поставянето им зад контрол на достъпа, ограничаването на ресурсите, до които компрометиран сървър има достъп, и готовността да приложите обновяването в момента, в който се появи.

Cloudflare заявява, че наблюдава ранни опити за експлоатиране на уязвимостите, и е въвела извънредни правила за сайтовете зад своята защита, които определя като временно решение, докато инсталирате корекциите за сигурност. Не е потвърден успешен пробив, публичният зловреден код за експлоатация, който се разпространява, не е доказано работещ, и нито една от двете уязвимости не е в каталога на CISA за известни експлоатирани уязвимости. От PHP не са съобщили кои версии са засегнати, коя част от PHP е замесена или дали дадена настройка променя риска; посочва се, че пълните подробности и коригираните версии ще бъдат обявени при официалното пускане.

Към момента на писане на тази статия въпросното издание все още не беше публикувано. Така че никой извън групата, открила уязвимостите, не може да тества дали дадена защита работи, поради което съветите по-долу целят намаляване на риска, а не гарантиране на пълна безопасност.

Настройката, която ви беше препоръчано да промените, не представлява защита

Временното решение, разпространяващо се в социалните мрежи и блоговете за сигурност, представлява един ред в конфигурационния файл на PHP: session.upload_progress.enabled=0. Той изключва Session Upload Progress – функционалност в PHP, включена по подразбиране, която записва докъде е стигнало качването на даден файл, така че друга заявка да може да провери напредъка.

GMO Flatt Security, базирана в Токио компания за сигурност, предложи промяната на тази настройка в началото на 21 октомври, като заяви, че не може да бъде сигурна дали промяната адресира напълно уязвимостите, но смята, че тя би помогнала с определена вероятност.

По-късно същия ден компанията оттегли това твърдение. В актуализация с времево клеймо 14:00 часа по японско време (05:00 UTC) тя заяви, че самата настройка не е цялостно решение и че се очакват атаки, които я заобикалят. Тя посъветва администраторите да подготвят обновяването си, да следят за трафик от атаки преди пускането и да приложат корекцията веднага след появата ѝ.

Двама души от проекта PHP изразиха същото мнение още по-категорично. В отговор на потребител, предложил, че настройката за напредъка при качване може да отстрани уязвимостта, Джина Питър Банярд (Gina Peter Banyard), основен разработчик на PHP и автор на документация, финансиран от PHP Foundation, написа: „Единственото нещо, което мога да кажа, е, че единствената мярка за смекчаване е инсталирането на корекции за сигурност / надграждането на PHP. За съжаление знам твърде много.“ Джо Фъргюсън (Joe Ferguson), мениджър по пускането на предстоящия PHP 8.6, го формулира още по-кратко: „ini настройките няма да ви спасят.“

На настройката не може да се разчита поради две причини. GMO Flatt очаква начин за нейното заобикаляне, но не е съобщила какъв е той. А и самата идея, че уязвимостта се намира в Session Upload Progress, е предположение: от PHP не са я потвърдили, самата компания заяви, че това е вярно само доколкото собствените ѝ проучвания съвпадат с PHP2Shell, а независим одит на кода твърди, че конкретната грешка, описвана от други в тази функционалност, не съществува в публикуваните версии на PHP. Този одит е от анонимен профил и собственият код на PHP ще даде окончателен отговор, но това е още една причина да не разглеждате настройката като щит.

Не всички са съгласни. Един от доставчиците, Upwind, все още посочва настройката като незабавна мярка за смекчаване, предавайки анализа на друг изследовател, вместо свои собствени тестове. watchTowr, която възпроизведе една от уязвимостите, заявява, че „към момента няма потвърдена корекция за сигурност или временно решение“.

Ако вече сте я настроили

Никой не ви кара да отменяте промяната. Указанието е само да не я считате за защита. Самото ръководство на PHP вече препоръчва изключването на тази функция, когато дадено приложение не използва ленти за напредък при качване, тъй като съхраняваните имена на файлове и имена на полета „не се валидират и могат да съдържат PHP код“. Ако сте я включили по погрешка на място, където тя е необходима, единственият негативен ефект е, че лентите за напредък на качването ще спрат да работят.

Уверете се, че промяната действително е влязла в сила за процеса, който обслужва уеб трафика, а не само за командния ред. Настройката е от тип INI_PERDIR, така че може да бъде зададена в php.ini, .htaccess или .user.ini.

Файлът .user.ini се чете само от CGI и FastCGI версиите на PHP, но не и от модула на Apache, като PHP го препрочита само на всеки 300 секунди по подразбиране, така че прилагането на промяна там може да отнеме пет минути.

При модула за Apache използвайте .htaccess или конфигурацията на сървъра. Потвърдете стойността в PHP-FPM или mod_php – което от двете обслужва вашия сайт, а не чрез php -i в шела.

Ако можете да инсталирате корекциите за сигурност в 14:00 UTC

Подгответе се сега. Съветът на GMO Flatt е да потвърдите стъпките за обновяване и проверките, които извършвате след това, да тествате предварително всяка промяна в конфигурацията и да осигурите необходимите хора и одобрения за евентуално извънредно рестартиране. Когато корекцията за сигурност бъде пусната, обновете средата за изпълнение, която обслужва уеб заявките – тоест PHP-FPM, mod_php или CGI, а не самото приложение над нея.

PHP пуска корекции само за своите четири поддържани клона – от 8.2 до 8.5. Кои точни версии съдържат корекцията и колко назад обхващат уязвимостите ще бъде обявено с пускането на официалната версия.

The Hacker News съобщи за поддръжката на клоновете и по-широкия контекст в по-ранното си отразяване на разкриването на уязвимостта.

Ако не можете да инсталирате корекциите веднага или използвате неподдържана версия

В случаите, когато незабавно обновяване не е възможно, CERT-EU съветва организациите „да обмислят изолирането на приложенията с достъп до интернет от публични мрежи, докато не бъде приложена корекция за сигурност“. Банярд изрази същата гледна точка от позицията на човек от проекта: изключването на сървър за един ден „може да е най-разумното нещо, което да направите. Но това далеч не е разумно изискване за повечето хора.“ Ако изключването не е вариант, ограничете обхвата на достъп: поставете сайта зад VPN, списъци с разрешени клиенти (allowlist) или автентикиран достъп на ниво периметър (edge) и се уверете, че трафикът не може да достигне изходния сървър директно, заобикаляйки тези контроли.

Сведете до минимум това, до което атакуващият би получил достъп при превземане на сървъра. Другите стъпки на GMO Flatt са да намалите обема на данните, съхранявани на сървъра, да ограничите неговите привилегии, да премахнете запазените идентификационни данни, включително облачни роли, и да се уверите, че воденето на логове е активно и се съхранява на защитено място, за да можете да извършите разследване по-късно.

Клонове, по-стари от 8.2, включително 8.1, 7.x и 5.x, са с прекратена поддръжка (end-of-life) и не получават официални корекции за сигурност от PHP. За тях надградете версията, изключете системата от мрежата или я изолирайте; съответната Linux дистрибуция или хостинг доставчик може да адаптира и пренесе корекцията (backport) по собствен график.

Защитната стена за уеб приложения (WAF) в случая е само временно решение, а не поправка, и самите Cloudflare го признават. Компанията е въвела извънредни правила за известните пътища за експлоатация, включително за безплатния си план, които нейният технически директор (CTO) определя единствено като „ВРЕМЕННО РЕШЕНИЕ“ преди инсталирането на корекциите за сигурност. Подобни правила следят само трафика, който преминава през Cloudflare, и могат да пропуснат нови вектори на атака при появата им.

Ако някой друг управлява вашата PHP среда

Актуализирането на WordPress, Laravel или друго приложение не обновява средата за изпълнение на PHP (runtime) под него – тя се предоставя от сървърния пакет, хостинг доставчика или контейнерното изображение. При управляван (managed) или споделен хостинг попитайте вашия доставчик кога ще бъде налична коригираната версия на PHP и поискайте да следят ситуацията.

Хостинг доставчиците компилират своите пакети едва след като от PHP пуснат корекцията за сигурност: от CloudLinux например заявяват, че техните обновени пакети зависят от официалното upstream издание и ще бъдат публикувани веднага щом са готови.

Какво да проверите, когато излезе официалното издание

Експлоатацията е в начален етап и все още е непотвърдена. Cloudflare съобщава за появяващи се опити; watchTowr посочва, че успешно е възпроизвел един от дефектите, но не съобщава за атаки; публично циркулиращият код за експлоатация все още не е доказал ефективността си; и нито една от двете уязвимости не фигурираше в каталога на CISA за известни експлоатирани уязвимости при последната проверка на 21 октомври.

Изследовател публикува видеоклип, за който се твърди, че демонстрира веригата от уязвимости (exploit chain), а одитен доклад посочва, че разпространяваният концептуален код (proof-of-concept) не сработва срещу официално издадените версии на PHP. Приемайте всичко това като моментно състояние, което може да се промени всеки час.

Когато корекцията бъде публикувана, проверете коригираната версия за вашия клон, кои версии се посочват от PHP като засегнати, дали екипът на PHP потвърждава или отхвърля определена настройка като временна мярка за защита и дали кодът за сесиите е бил променен, което също ще разреши спора за това къде точно се намира уязвимостта.

Коригираните версии и бюлетинът за сигурност ще се появят на php.net и в бюлетините за сигурност на PHP в GitHub, където проектът присвоява свои собствени идентификатори. След актуализирането прегледайте системните си журнали (logs) за всякакви съмнителни действия, случили се преди да инсталирате корекциите за сигурност.