Lühidalt: PHP2Shelli poolt on mõjutatud kõik tavalised töörežiimid, kuid Apache'i ja mod_php puhul hindab PHP meeskond riski kõige suuremaks. Seal näidati ekspluateerimist enne, kui rakenduse kood üldse käivitub. Kes kasutab mod_php-d, peaks kõigepealt PHP uuendama ja Apache'i täielikult uuesti käivitama.
Mis on mod_php?
mod_php puhul on PHP moodul Apache'i veebiserveri sees. Iga Apache'i protsess sisaldab täielikku PHP interpretaatorit ja käivitab PHP koodi otse. See töörežiim oli pikka aega standard ning on vanemates serverites, paljudes distributsioonide pakettides ja mõnedes Dockeri tõmmistes tänaseni levinud.
Alternatiiv on PHP-FPM: seal töötab PHP omaette teenusena oma protsessidega ning Apache või Nginx annab päringuid ainult edasi. Mõlemad variandid on PHP2Shelli poolt mõjutatud, samuti php-cgi, FrankenPHP ja LiteSpeed.
Tüüpilised mod_php keskkonnad on vanemad root-serverid, mis töötavad aastaid muutmata, Apache'i standardpaigaldused distributsioonide pakettidest ja Dockeri tõmmised Apache'i ja PHP-ga ühes konteineris. Kes ei tea kindlalt, millist töörežiimi tema server kasutab, peaks seda kontrollima, mitte oletama.
Miks loetakse mod_php turvaauku eriti riskantseks?
PHP meeskond on PHP2Shelli kohta andnud selge hinnangu: mod_php puhul on risk kõige suurem. Põhjendus: seal näidati ekspluateerimist, mis rakendub enne, kui rakenduse kood üldse käivitub.
Haldajatele on sellel ebamugav tagajärg. Paljud kaitsemeetmed asuvad rakenduses: turvapluginad WordPressis, tulemüürimoodulid poodides, kontrollid oma koodis. Need kõik on rakenduse kood. Kui ärakasutamine toimub enne seda, jõuavad need liiga hilja.
Lisaks tuleb tihe põimumine: mod_php puhul jagab PHP protsessi Apache'iga. Mida PHP kompromiteerib, töötab veebiserveri õigustega ja selle mälus. PHP-FPM-i puhul saab poole seevastu eraldada oma kasutajatega veebisaidi kaupa, mis võib sissemurdmise tagajärgi piirata.
Prioriseerimiseks tähendab see: kui haldate mitut serverit, tulevad mod_php-ga serverid esimesena järjekorda ja nende puhul on järgnev jälgede kontroll eriti oluline.
Mida me ei tea: kui paljud kogu maailmas loetud 22,6 miljonist avalikult ligipääsetavast, potentsiaalselt haavatavast instantsist kasutavad mod_php-d. Töökindlaid arve selle kohta avaldatud ei ole.
Kas minu server kasutab mod_php-d?
Järgmised käsud on puhtalt lugevad. Teenuse- ja käskude nimed erinevad distributsiooniti: Debian ja Ubuntu kasutavad apache2, RHEL-i perekond httpd.
apachectl -M 2>/dev/null | grep -i php # nt php_module või 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, mooduli paketi seis
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-i perekond
Kui ühtegi PHP moodulit ei ilmu, kasutab Apache tõenäoliselt PHP-FPM-i proxy_fcgi kaudu. Siis kehtivad lehel Nginxi ja PHP-FPM-i kaitsmine toodud märkused vastavalt.
Mida mod_php haldajad nüüd tegema peaksid
- Uuendada PHP moodul versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35 või teie distributsiooni kinnitatud tagasiportimisele.
- Käivitada Apache täielikult uuesti, mitte ainult uuesti laadida. mod_php puhul asub vana PHP kood igas Apache'i protsessis.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL-i perekond
ps -o pid,lstart,cmd -C apache2 # algusaja kontroll, RHEL-is: -C httpd
- Rakendada ajutised meetmed, kui uuendus veel ei õnnestu. php.net nimetab muu hulgas kindlaid piire, mida rakendused üle kirjutada ei saa:
# Serveri seadistus või VirtualHost, mitte .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
Seadega memory_limit=-1 kuulub juurde mälupiirang cgroupi kaudu, mitte RLIMIT_AS või RLIMIT_DATA kaudu. Need meetmed ei ole täielik kaitse; üksikasjad on lehel Kohesed meetmed, kui te veel paigata ei saa. Kui kumbki kohe ei õnnestu, soovitab BSI veebiserveri ajutiselt võrgust maha võtta.
Kui teie Apache koos mod_php-ga töötas 17. oktoobri ja paiga vahel kaitsmata internetis, kindlustage logid alates 20. oktoobrist ja laske serveril jälgi kontrollida. Paik üksi ei tõesta, et midagi ei juhtunud.
Keskpikas perspektiivis: mod_php-st eemale
Pärast paika tasub vaadata arhitektuuri. Üleminek PHP-FPM-ile koos Apache'i mpm_event ja proxy_fcgi või Nginxiga eraldab PHP veebiserverist, võimaldab oma poole ja kasutajaid veebisaidi kohta ning teeb taaskäivitused ja versioonivahetused lihtsamaks. See ei sulge PHP2Shelli, kuid vähendab tulevaste turvaaukude ründepinda.
Üleminek vajab planeerimist. Sätted, mis seni määrati .htaccess-is php_value abil, ei mõju PHP-FPM-i all enam ja peavad kolima pooli. Kasutajad ja õigused muutuvad, üleslaadimis- ja vahemälukataloogid võivad vajada uusi õigusi. Testkeskkonnas on see hästi hallatav, töökeskkonnas ajapinge all mitte. Märkusi ülemineku kohta leiate lehelt Apache'i kaitsmine mod_php-ga.
Kuidas PHP SOS konkreetselt aitab?
- Tuvastamine: Kontrollime, millised serverid kasutavad mod_php-d ja millisest paketiallikast moodul pärineb.
- Paikamine ja taaskäivitus: PHP paikamisteenuse kaudu paigaldame uuenduse ja kontrollime, et ükski vana Apache'i protsess enam ei tööta.
- Ülemineku kindlustamine: Kus uuendus on blokeeritud, seame php.net-i meetmed serveri seadistuses.
- Ümberlülitamine: Serveri karastamise raames planeerime ja testime üleminekut PHP-FPM-ile eraldatud poolidega.
Korduma kippuvad küsimused
Kuidas ma tean, kas mu Apache kasutab mod_php-d?
Käsuga apachectl -M või httpd -M näete laaditud mooduleid. Kui seal on moodul nagu php_module või php8_module, töötab PHP otse Apache'is. Debianis ja Ubuntus näitab ka a2query -m, kas php-moodul on aktiivne.
Kas WordPressi turvaplugin kaitseb mind mod_php puhul?
Selle turvaaugu puhul mitte. PHP meeskonna järgi näidati mod_php puhul ekspluateerimist enne, kui rakenduse kood üldse käivitub. Plugin on rakenduse kood ja jõuab seega liiga hilja. Kaitse annab ainult PHP uuendus koos Apache'i taaskäivitusega.
Kas peaksin nüüd mod_php-lt PHP-FPM-ile üle minema?
Kõigepealt paikige, siis lülitage ümber. Üleminek PHP-FPM-ile on enamiku seadistuste puhul keskpikas perspektiivis mõistlik, sest PHP töötab siis veebiserverist eraldi. PHP2Shelli see aga ei sulge, sest PHP-FPM on samuti mõjutatud.