Zašto mod_php nosi najviši rizik

Ukratko: PHP2Shellom su pogođeni svi uobičajeni načini rada, ali kod Apachea s mod_php PHP tim rizik ocjenjuje najvišim. Tamo je prikazan exploit prije nego što se uopće izvrši kod aplikacije. Tko koristi mod_php, trebao bi prvo ažurirati PHP i potpuno ponovno pokrenuti Apache.

Što je mod_php?

Kod mod_php PHP je modul unutar Apache web-poslužitelja. Svaki Apache proces sadrži potpuni PHP interpreter i izravno izvršava PHP kod. Taj je način rada dugo bio standard i do danas je raširen na starijim poslužiteljima, u mnogim paketima distribucija i u nekim Docker image-ima.

Alternativa je PHP-FPM: tamo PHP radi kao zasebna usluga sa zasebnim procesima, a Apache ili Nginx samo prosljeđuju zahtjeve. Obje su varijante pogođene PHP2Shellom, kao i php-cgi, FrankenPHP i LiteSpeed.

Tipična okruženja s mod_php su stariji root poslužitelji koji godinama rade nepromijenjeni, standardne instalacije Apachea iz paketa distribucija i Docker image-i s Apacheom i PHP-om u jednom kontejneru. Tko nije siguran koji način rada njegov poslužitelj koristi, trebao bi to provjeriti umjesto pretpostaviti.

Zašto se mod_php sigurnosna ranjivost smatra osobito rizičnom?

PHP tim je za PHP2Shell dao jasnu procjenu: kod mod_php rizik je najviši. Obrazloženje: tamo je prikazan exploit koji djeluje prije nego što se uopće izvrši kod aplikacije.

Za operatere to ima neugodnu posljedicu. Mnoge zaštitne mjere nalaze se u aplikaciji: sigurnosni dodaci u WordPressu, vatrozidni moduli u shopovima, provjere u vlastitom kodu. Sve su to kod aplikacije. Ako se iskorištavanje događa prije toga, dolaze prekasno.

Tome se pridodaje uska povezanost: kod mod_php PHP dijeli proces s Apacheom. Što PHP kompromitira, radi s pravima web-poslužitelja i u njegovoj memoriji. Kod PHP-FPM-a poolovi se mogu odvojiti zasebnim korisnicima po web-stranici, što može ograničiti posljedice provale.

Za određivanje prioriteta to znači: ako upravljate s više poslužitelja, oni s mod_php dolaze prvi na red, a kod njih je naknadna provjera tragova osobito važna.

Što ne znamo: koliko od 22,6 milijuna izloženih, potencijalno ranjivih instanci izbrojenih u svijetu koristi mod_php. Pouzdani podaci o tome nisu objavljeni.

Koristi li moj poslužitelj mod_php?

Sljedeće naredbe su isključivo čitajuće. Nazivi usluga i naredbi razlikuju se po distribuciji: Debian i Ubuntu koriste apache2, obitelj RHEL httpd.

apachectl -M 2>/dev/null | grep -i php     # npr. php_module ili 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, stanje paketa modula
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # obitelj RHEL

Ako se ne pojavi nijedan PHP modul, Apache vjerojatno koristi PHP-FPM putem proxy_fcgi. Tada napomene na stranici Osiguravanje Nginxa s PHP-FPM-om vrijede analogno.

Što bi operateri mod_php sada trebali učiniti

1. Ažurirati PHP modul na 8.5.12, 8.4.27, 8.3.36 ili 8.2.35 ili potvrđeni backport Vaše distribucije.
2. Potpuno ponovno pokrenuti Apache, a ne samo ponovno učitati. Kod mod_php stari PHP kod nalazi se u svakom Apache procesu.

sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # obitelj RHEL
ps -o pid,lstart,cmd -C apache2    # provjeriti vrijeme pokretanja, u RHEL-u: -C httpd

3. Postaviti privremene mjere ako ažuriranje još nije moguće. php.net među ostalim navodi čvrsta ograničenja koja aplikacije ne mogu nadjačati:

# Konfiguracija poslužitelja ili 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

Uz memory_limit=-1 pripada ograničenje memorije putem cgroupa, a ne putem RLIMIT_AS ili RLIMIT_DATA. Te mjere nisu potpuna zaštita; pojedinosti su na stranici Hitne mjere ako još ne možete zakrpati. Ako ni jedno ni drugo nije odmah moguće, BSI (njemački Savezni ured za sigurnost informacijske tehnologije) preporučuje privremeno isključiti web-poslužitelj s mreže.

Srednjoročno: odmak od mod_php

Nakon zakrpe isplati se pogledati arhitekturu. Prelazak na PHP-FPM s Apacheom mpm_event i proxy_fcgi ili s Nginxom odvaja PHP od web-poslužitelja, omogućuje zasebne poolove i korisnike po web-stranici te olakšava ponovna pokretanja i promjene verzije. PHP2Shell ne zatvara, ali smanjuje površinu napada budućih ranjivosti.

Prelazak traži planiranje. Postavke koje su dosad postavljane putem php_value u .htaccess ne djeluju pod PHP-FPM-om i moraju se preseliti u pool. Korisnici i prava se mijenjaju, mape za prijenos i predmemoriju možda trebaju nova dopuštenja. U testnom okruženju to je dobro izvedivo, u živom radu pod vremenskim pritiskom nije. Napomene o prelasku pronaći ćete na stranici Osiguravanje Apachea s mod_php.

Kako PHP SOS konkretno pomaže?

• Prepoznati: Provjeravamo koji poslužitelji koriste mod_php i iz kojeg izvora paketa modul potječe.
• Zakrpati i ponovno pokrenuti: Putem usluge PHP zakrpe instaliramo ažuriranje i kontroliramo da više ne radi nijedan stari Apache proces.
• Osigurati prijelaz: Gdje je ažuriranje blokirano, mjere php.net-a postavljamo u konfiguraciju poslužitelja.
• Prijeći: U sklopu ojačavanja poslužitelja planiramo i testiramo prelazak na PHP-FPM sa zasebnim poolovima.

Česta pitanja

Izvori

• php.net: sigurnosne objave
• PHP 8 ChangeLog
• BSI: Savezni ured za sigurnost informacijske tehnologije