Trumpai: PHP2Shell paveikia visus įprastus veikimo režimus, tačiau esant Apache su mod_php PHP komanda riziką vertina didžiausią. Ten išnaudojimas parodytas dar prieš pradedant vykdyti bet kokį programos kodą. Kas eksploatuoja mod_php, turėtų pirmiausia atnaujinti PHP ir visiškai paleisti iš naujo Apache.
Kas yra mod_php?
Esant mod_php, PHP yra Apache žiniatinklio serverio modulis. Kiekviename Apache procese yra pilnas PHP interpretatorius, kuris vykdo PHP kodą tiesiogiai. Šis veikimo režimas ilgai buvo standartinis ir iki šiol paplitęs senesniuose serveriuose, daugelyje distribucijų paketų ir kai kuriuose Docker atvaizduose.
Alternatyva yra PHP-FPM: ten PHP veikia kaip atskira tarnyba su savais procesais, o Apache ar Nginx tik perduoda užklausas. Abu variantai paveikti PHP2Shell, taip pat php-cgi, FrankenPHP ir LiteSpeed.
Tipinės aplinkos su mod_php: senesni root serveriai, jau metų metus veikiantys nepakitę, standartiniai Apache diegimai iš distribucijų paketų ir Docker atvaizdai su Apache ir PHP viename konteineryje. Kas tiksliai nežino, kokį veikimo režimą naudoja jo serveris, turėtų patikrinti, o ne spėti.
Kodėl mod_php saugumo spraga laikoma ypač rizikinga?
PHP komanda dėl PHP2Shell pateikė aiškų vertinimą: esant mod_php rizika didžiausia. Pagrindimas: ten parodytas išnaudojimas, kuris suveikia dar prieš pradedant vykdyti bet kokį programos kodą.
Operatoriams tai turi nemalonią pasekmę. Daug apsaugos priemonių yra programoje: saugumo įskiepiai WordPress, ugniasienės moduliai parduotuvėse, patikros nuosavame kode. Visa tai yra programos kodas. Jei išnaudojimas vyksta anksčiau, jos ateina per vėlai.
Be to, glaudus susijungimas: esant mod_php, PHP dalijasi procesu su Apache. Kas kompromituoja PHP, veikia su žiniatinklio serverio teisėmis ir jo atmintyje. Esant PHP-FPM, baseinus galima atskirti su savais naudotojais kiekvienai svetainei, o tai gali apriboti įsilaužimo pasekmes.
Prioritetų nustatymui tai reiškia: jei eksploatuojate kelis serverius, tie su mod_php eina pirmi, ir jiems vėlesnė pėdsakų patikra ypač svarbi.
Ko nežinome: kiek iš pasaulyje suskaičiuotų 22,6 milijono viešai pasiekiamų, potencialiai pažeidžiamų egzempliorių naudoja mod_php. Patikimų skaičių apie tai nepaskelbta.
Ar mano serveris naudoja mod_php?
Toliau pateiktos komandos tik skaito. Tarnybų ir komandų pavadinimai skiriasi pagal distribuciją: Debian ir Ubuntu naudoja apache2, RHEL šeima httpd.
apachectl -M 2>/dev/null | grep -i php # pvz., php_module arba php8_module
httpd -M 2>/dev/null | grep -i php # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php # Debian/Ubuntu
apt policy libapache2-mod-php8.3 # Debian/Ubuntu, modulio paketų būsena
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL šeima
Jei nepasirodo joks PHP modulis, Apache tikriausiai naudoja PHP-FPM per proxy_fcgi. Tuomet atitinkamai taikomos nuorodos puslapyje Nginx su PHP-FPM apsauga.
Ką mod_php operatoriai turėtų daryti dabar
- Atnaujinti PHP modulį iki 8.5.12, 8.4.27, 8.3.36 ar 8.2.35 arba iki jūsų distribucijos patvirtinto atgalinio perkėlimo (backport).
- Visiškai paleisti iš naujo Apache, o ne tik perkrauti. Esant mod_php senas PHP kodas yra kiekviename Apache procese.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL šeima
ps -o pid,lstart,cmd -C apache2 # patikrinti paleidimo laiką, RHEL sistemose: -C httpd
- Nustatyti pereinamąsias priemones, jei atnaujinimas dar neįmanomas. php.net be kita ko nurodo fiksuotas ribas, kurių programos negali perrašyti:
# Serverio konfigūracija arba VirtualHost, ne .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Su memory_limit=-1 priklauso atminties riba per cgroup, o ne per RLIMIT_AS ar RLIMIT_DATA. Šios priemonės nėra visiška apsauga; detalės pateiktos puslapyje Skubios priemonės, kai dar negalite pataisyti. Jei nė viena iš jų iš karto neįmanoma, BSI rekomenduoja žiniatinklio serverį laikinai atjungti nuo tinklo.
Jei jūsų Apache su mod_php nuo spalio 17 d. iki pataisos veikė internete neapsaugotas, išsaugokite žurnalus nuo spalio 20 d. ir patikrinkite serverį dėl pėdsakų. Vien pataisa neįrodo, kad nieko neįvyko.
Vidutinės trukmės: atsisakyti mod_php
Po pataisos verta pažvelgti į architektūrą. Perėjimas prie PHP-FPM su Apache mpm_event ir proxy_fcgi arba su Nginx atskiria PHP nuo žiniatinklio serverio, leidžia turėti savus baseinus ir naudotojus kiekvienai svetainei bei palengvina paleidimus iš naujo ir versijų keitimus. PHP2Shell jis neuždaro, bet sumažina būsimų spragų atakos paviršių.
Perjungimui reikia planavimo. Nustatymai, kurie iki šiol buvo nustatomi per php_value faile .htaccess, esant PHP-FPM nebeveikia ir turi persikelti į baseiną. Pasikeičia naudotojai ir teisės, įkėlimų ir talpyklos katalogams gali reikėti naujų leidimų. Bandomojoje aplinkoje tai gerai valdoma, veikiančioje sistemoje skubant ne. Perjungimo nurodymų rasite puslapyje Apache su mod_php apsauga.
Kaip PHP SOS padeda konkrečiai?
- Atpažinti: Tikriname, kurie serveriai naudoja mod_php ir iš kurio paketų šaltinio modulis.
- Pataisyti ir paleisti iš naujo: Per PHP pataisų paslaugą įdiegiame atnaujinimą ir kontroliuojame, kad nebeveikia joks senas Apache procesas.
- Apsaugoti pereinamuoju laikotarpiu: Kur atnaujinimas užblokuotas, serverio konfigūracijoje nustatome php.net priemones.
- Perjungti: Vykdydami serverio sustiprinimą planuojame ir bandome perėjimą prie PHP-FPM su atskirtais baseinais.
Dažni klausimai
Kaip suprasti, ar mano Apache naudoja mod_php?
Su apachectl -M ar httpd -M matote įkeltus modulius. Jei ten yra modulis, pavyzdžiui, php_module ar php8_module, PHP veikia tiesiogiai Apache. Debian ir Ubuntu sistemose tai rodo ir a2query -m, ar php modulis aktyvus.
Ar saugumo įskiepis WordPress mane saugo esant mod_php?
Šios spragos atveju ne. Pasak PHP komandos, esant mod_php išnaudojimas parodytas dar prieš pradedant vykdyti bet kokį programos kodą. Įskiepis yra programos kodas, todėl ateina per vėlai. Apsaugo tik PHP atnaujinimas su Apache paleidimu iš naujo.
Ar dabar turėčiau pereiti nuo mod_php prie PHP-FPM?
Pirmiausia pataisyti, tada perjungti. Perėjimas prie PHP-FPM daugumai sąrankų vidutinės trukmės laikotarpiu prasmingas, nes PHP tada veikia atskirai nuo žiniatinklio serverio. Tačiau PHP2Shell jis neuždaro, nes PHP-FPM taip pat paveiktas.