PHP2Shell patch është i vetmi korrigjim i besueshëm për dobësitë e PHP
PHP2Shell përfshin dy dobësi kritike remote code execution (RCE) në PHP, domethënë dobësi që mund t’i lejojnë një sulmuesi të ekzekutojë nga larg komanda në një web server të cenueshëm. PHP i vlerëson të dyja dobësitë me 9,2 nga 10 dhe planifikoi publikimin e korrigjimeve për në orën 14:00 UTC më 21 tetor. Në periudhën e raportimit, këto korrigjime nuk ishin publikuar ende dhe PHP nuk kishte bërë të ditura versionet e prekura, komponentin e cenueshëm apo ndonjë workaround të bazuar në konfigurim.
Kjo mungesë hollësish teknike do të thotë se administratorët nuk mund të provojnë ende se një cilësim i caktuar mbrojtës e bllokon PHP2Shell. Cloudflare raportoi përpjekje të hershme shfrytëzimi dhe vendosi rregulla emergjente filtrimi, përfshirë edhe për planin e vet falas, por i përshkroi këto rregulla si mbrojtje të përkohshme derisa sistemet të mund të marrin patch. Nuk ishte konfirmuar asnjë komprometim i suksesshëm, kodi publik exploit që qarkullonte nuk ishte demonstruar se funksiononte dhe, kur u kontrollua më 21 tetor, asnjëra nga dobësitë nuk gjendej në katalogun e dobësive të njohura si të shfrytëzuara të Agjencisë së SHBA-së për Sigurinë Kibernetike dhe Sigurinë e Infrastrukturës. Veçmas, watchTowr tha se kishte riprodhuar njërën dobësi, por nuk kishte raportuar sulme.
Mitigation i propozuar që është shpërndarë më gjerësisht është session.upload_progress.enabled=0, i cili çaktivizon funksionin Session Upload Progress të PHP. Ky funksion është aktivizuar si parazgjedhje dhe regjistron ecurinë e një file upload, në mënyrë që një request tjetër ta kontrollojë atë. GMO Flatt Security sugjeroi fillimisht se çaktivizimi mund të ndihmonte, duke paralajmëruar se nuk mund të konfirmonte mbrojtje të plotë. Në një përditësim me timestamp 14:00 sipas orës së Japonisë, ose 05:00 UTC, kompania sqaroi se vetëm ky cilësim ishte i pamjaftueshëm dhe tha se pritej që sulmuesit të mund ta anashkalonin. Edhe anëtarë të projektit PHP deklaruan se ndryshimi i cilësimeve të konfigurimit INI nuk mund të zëvendësojë patching ose përditësimin e PHP.
Gjithashtu, nuk ka konfirmim publik se ndonjëra nga dobësitë ndodhet te Session Upload Progress. GMO Flatt Security e lidhi këshillën e vet me vlerësimin e saj për atë që mund të përfshijë PHP2Shell. Një audit anonim i kodit e kundërshtoi dobësinë e pretenduar në këtë funksion dhe tha se proof-of-concept që qarkullonte nuk funksiononte kundër versioneve të publikuara të PHP. Upwind vazhdoi ta rendiste këtë cilësim si mitigation të menjëhershëm, bazuar në analizën e një studiuesi tjetër, ndërsa watchTowr tha se nuk kishte workaround të konfirmuar. Advisory përfundimtar i PHP dhe ndryshimet në kod nevojiten për ta zgjidhur këtë mosmarrëveshje.
Administratorët që e kanë çaktivizuar tashmë upload progress nuk kanë nevojë ta zhbëjnë ndryshimin, por nuk duhet ta trajtojnë atë si korrigjim sigurie. Manuali i PHP rekomandon tashmë çaktivizimin e funksionit kur një aplikacion nuk ka nevojë për shirita të ecurisë së ngarkimit, sepse emrat e ruajtur të file dhe të fushave të formularit nuk validohen dhe mund të përmbajnë kod PHP. Çaktivizimi i tij në një faqe që e kërkon këtë funksion do të bëjë që shiritat e ecurisë së ngarkimit të mos funksionojnë.
Cilësimi duhet të ndryshohet gjithashtu në procesin PHP që përpunon realisht request e faqes. Ai është një opsion INI_PERDIR dhe mund të konfigurohet përmes php.ini, .htaccess ose .user.ini. Metoda .user.ini zbatohet vetëm për deployment CGI dhe FastCGI, jo për modulin Apache, dhe PHP e kontrollon këtë file çdo 300 sekonda si parazgjedhje, ndaj aktivizimi i një ndryshimi mund të kërkojë pesë minuta. Faqet që përdorin modulin Apache kanë nevojë për .htaccess ose konfigurim të serverit. Kontrollimi i php -i në command line nuk konfirmon vlerën që PHP-FPM ose mod_php përdor për web traffic.
Administratorët që mund ta kryejnë shpejt përditësimin duhet të përgatitin procedurën e deployment, kontrollet pas përditësimit, miratimet dhe çdo restart të nevojshëm përpara publikimit. Komponenti që duhet përditësuar është PHP runtime që u shërben web request, si PHP-FPM, mod_php ose CGI, dhe jo WordPress, Laravel apo ndonjë aplikacion tjetër që funksionon mbi të. PHP aktualisht ofron korrigjime për katër branches të mbështetura, nga 8.2 deri në 8.5. Versionet e sakta të korrigjuara dhe diapazoni i plotë i versioneve të prekura pritej të publikoheshin bashkë me advisory.
Faqet që nuk mund ta instalojnë menjëherë patch duhet ta zvogëlojnë ekspozimin e tyre. CERT-EU këshillon të merret në konsideratë izolimi nga rrjetet publike i aplikacioneve të ekspozuara në internet, derisa të jetë i disponueshëm një korrigjim. Opsionet praktike përfshijnë nxjerrjen e përkohshme të një faqeje offline ose vendosjen e saj pas aksesit me autentikim, një VPN ose një allowlist klientësh të miratuar. Administratorët duhet gjithashtu të pengojnë vizitorët që t’i anashkalojnë këto kontrolle dhe të arrijnë drejtpërdrejt origin server. GMO Flatt Security rekomandon gjithashtu zvogëlimin e të dhënave të ruajtura dhe të privilegjeve të serverit, heqjen e kredencialeve të ruajtura dhe të roleve cloud, si dhe ruajtjen e logs në një vend të sigurt për hetim të mëvonshëm.
Branches të pambështetura të PHP më të vjetra se 8.2, përfshirë 8.1, 7.x dhe 5.x, nuk marrin korrigjime drejtpërdrejt nga PHP. Këto sisteme kanë nevojë për përditësim, izolim ose heqje nga interneti, megjithëse një Linux distribution ose ofrues hosting mund të nxjerrë një backport, i cili zbaton një korrigjim sigurie pa kaluar në një version të ri madhor. CloudLinux tha se paketat e veta vareshin nga publikimi i upstream release prej PHP dhe se do të pasonin kur të ishin gati.
Një tjetër masë e përkohshme e propozuar është refuzimi në web server i request që përmbajnë një body multipart/form-data, përpara se PHP t’i përpunojë. Kjo synon formatin e dyshuar të request të përfshirë në dobësitë, por mbetet e pakonfirmuar. Bllokimi vetëm i request POST është i pamjaftueshëm, sepse PHP 8.4 prezantoi request_parse_body(), i cili mund të përpunojë multipart bodies të dërguar me metoda të tjera. Një bllokim më i gjerë do të ndërpresë file uploads dhe formularët që përdorin multipart data, edhe kur nuk është bashkëngjitur asnjë file.
Një web application firewall mund të filtrojë modele të njohura të request keqdashëse, por nuk zëvendëson PHP2Shell patch. Rregullat e Cloudflare inspektojnë vetëm request që kalojnë përmes shërbimit të tij, nuk mund të mbrojnë një origin që mbetet drejtpërdrejt i arritshëm dhe mund të mos dallojnë rrugë të reja sulmi. Për pronarët e faqeve WordPress që po rishikojnë konfigurimet e tyre të hosting, AEU Hosting ofron managed WordPress hosting, të siguruar nga fillimi në fund.
Klientët e managed hosting dhe shared hosting duhet ta pyesin ofruesin e tyre se kur do të instalohet paketa e korrigjuar PHP. Linux distributions si Debian dhe Ubuntu mund të mbajnë një version PHP që duket i vjetër, ndërkohë që zbatojnë korrigjimin përmes backport, ndaj vetëm version string i dukshëm mund të mos përcaktojë nëse një server është i mbrojtur. Administratorët duhet ta krahasojnë versionin e plotë të paketës me advisory të distribution ose të kontrollojnë changelog e saj. Pas përditësimit, ata duhet të konfirmojnë release e korrigjuar për branch e tyre përmes php.net ose GitHub security advisories të PHP, të verifikojnë se cilat versione PHP i identifikon si të prekura dhe të shqyrtojnë logs për veprimtari të dyshimta që ka ndodhur përpara patching.