PHP2Shell: két kritikus PHP hiba, egy kiszivárgott embargó és ami valójában ismert a kihasználásról

Amit ez a videó tartalmaz

• Mindkét hibát 9.2-es CVSS v4.0 értékeléssel látta el a PHP csapat. A javított kiadások a PHP 8.2.35, 8.3.36, 8.4.27 és 8.5.12; a PHP 7.4, 8.0 és 8.1 csak forráskód-javításokat kapott. A PHP szerint a frissítés az egyetlen teljes körű enyhítés.
• Az első hiba abból adódik, hogy a PHP félig elkészült állapotban hagy egy kérést, amikor rossz pillanatban kifogy a memóriából. A második hiba egy megmaradt mutatóból adódik, amely egy korábbi kérés memóriájára mutat, és amelyet ugyanabban a munkafolyamatban egy későbbi kérés felhasználhat. Apache mod_php esetén az első útvonal az alkalmazás kódja előtt fut.
• Egy PHP alapfejlesztő 2024-es audit során találta meg a memóriaprobléma első jeleit. A PHP Alapítvány szerint a versengő javítások kompromisszumokkal jártak, és a konszenzuson alapuló biztonsági csapat nehezen tudott választani, amit strukturális hibának nevez.
• Az Alapítvány szerint a CVE azonosítók október 20-án kiszivárogtak, a Calif tévedésből közzétett egy proof-of-concept videót, és a Chainguard több mint hat órával a kiadás előtt közzétette a javítást tartalmazó összeállított képeket. A Chainguard vezérigazgatója szerint az embereket már érintették, és ő maga is függetlenül találta meg a hibákat.
• A források eltérően vélekednek a kihasználásról. Az Amazon október 17-én naplózott egy kísérletet, majd később azt mondta, hogy a PHP2Shell széles körben kihasznált. A watchTowr jelentett kihasználást "in the wild" (a való életben). A CISA a közzétételkor nem észlelt kihasználást, és a PHP csapat a kiadáskor nem talált működő exploitot. Sok nyilvános proof-of-concept szkriptről számoltak be, hogy nem működnek.
• Ellenőrizze az összes helyet, ahol a PHP fut, beleértve a más szoftverekben rejtőző másolatokat is, frissítsen, indítsa újra a munkafolyamatokat, és tekintse át a naplókat egészen október 17-ig.

Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

Ki próbálta ki a PHP2Shell-t négy nappal korábban?

0:00 Egy biztonsági embargónak elvileg csendben kell tartania egy hibát, amíg a javítás meg nem jelenik. Az Amazon négy nappal korábban naplózott egy kísérletet a PHP kritikus hibája ellen. Ebben a videóban ki találta meg? Hogyan szivárgott ki az embargó? És valójában mennyire rossz a helyzet? És a kiszivárgásért felelős vállalatnak van egy olyan védekezése, amire nem számítottam. Rátérek. Csütörtök van, október huszonkettedike, és ez a The Daily Diff.

0:21 A PHP egy szkriptnyelv, amely webszájtoldalakat épít a szerveren, közvetlenül mielőtt elérnek önhöz. Több mint harminc éves, és az egyik becslés szerint a weboldalak mintegy hetven százalékát futtatja, beleértve a WordPress-t és a Wikipédia mögötti szoftvert. A fejlesztők szeretik kigúnyolni, általában egy olyan oldalról, amit a PHP szolgáltat nekik. Karbantartását egy nonprofit szervezet végzi, mintegy tizenhárom mérnökkel.

Mik a két PHP2Shell hiba?

0:41 Szerdán a PHP sürgősségi javításokat adott ki két kritikus hibára, amelyek lehetővé teszik egy idegen számára, hogy bejelentkezés nélkül kódot futtasson egy szerveren. Ezeket együtt PHP2Shell-nek hívják, és egészen a PHP öt pont négyes verziójáig nyúlnak vissza. Íme az első hiba közérthetően. A PHP minden kérésnek ad egy memóriakeretet. Ha egy kérés pontosan rossz pillanatban éri el ezt a határt, a PHP sietve leáll, és félig elkészült állapotban hagyja a kérést. Ezután a takarítási lépés megbízik a félig elkészült dologban.

1:07 A második hiba egy maradék. Egy végzetes hiba hagyhat egy jegyzetet, ami az utolsó kéréshez tartozó memóriára mutat. Ugyanez a dolgozó kezeli a következő kérést, és követi a jegyzetet. Addigra már valaki más lakik azon a címen. Apache mod PHP-vel a kár azelőtt megtörténik, hogy a saját kódja futna, így a bejelentkezési oldala soha nem kap szavazati jogot. A Wiz szerint még egy hello world szkript is ki van téve a támadásnak. A javítás eltávolítja a PHP sürgősségi kilépési pontját a memóriahiány esetén.

1:32 A kérés közbeni leállás helyett a PHP most udvariasan leáll a következő biztonságos pontnál. A furcsa rész az, hogy milyen régi az első nyom.

Miért várt egy ismert hiba két évet a javításra?

1:39 2024-ben egy külső biztonsági audit vezetett egy PHP alapfejlesztőt a memóriaprobléma első jeleihez. Nem volt ismert exploit, és minden javítás elrontott valamit. Egy konszenzussal döntő csapat nem tudott választani, így a hiba várt. Aztán augusztusban, napokon belül megérkeztek a felfedezők.

Ki találta meg a PHP2Shell-t, és hogyan?

1:56 A Calif kutatója, Ryan Austin augusztus elsején találta meg, az OpenAI Patch the Planet programján keresztül dolgozva. Az OpenAI függetlenül jelentette ugyanazt a kiváltó okot. A Wiz néhány héttel később a Gemini és GPT modellekkel talált variánsokat. Austin szerint olyan modelleket használt, amelyek mindenki számára elérhetők, plusz egy elméletet arról, hogy hol rejtőznek a PHP régi hibái. Az OpenAI szerint a "frontier AI" volt a kulcs. A hiba több mint egy évtizedig rejtőzött. A kiadást csütörtökre tervezték.

Hogyan szivárgott ki a PHP2Shell embargó?

2:21 Kedden a két CVE szám elkezdett terjedni online, rossz megjelenési idővel és téves tízes pontszámmal. A PHP egy nappal előrébb hozta a kiadást. Azon az estén a Calif véletlenül közzétette proof of concept videóját működés közben, és a másolatok túlélték a törlést. Szerda reggel, több mint hat órával a kiadás előtt, a Chainguard kiadta a javítást tartalmazó összeállított képeket. A PHP szerint bármely támadó tanulmányozhatta volna ezt a javítást, amíg mindenki más várt.

2:46 Egy patch egyben diff is, és a támadók olvassák a diffeket.

Kihasználják-e a PHP2Shell-t, és kik?

2:50 Tehát kiket is érint valójában a támadás? Az Amazon honeypotja október tizenhetedikén naplózott egy kísérletet, majd később azt mondta, hogy a PHP2Shell széles körben ki van használva. A watchTowr jelentett kihasználást "in the wild" (a való életben). A Cisa szerint a közzétételkor nem észleltek ilyet, és a PHP csapata nem látott működő exploitot a kiadáskor. A Cloudflare vezérigazgatója szerint több ezer kísérletet láttak a bejelentés előtti tíz órában, és több milliót csütörtök reggelre.

3:13 Az Amazon egy ponton óvatos. Nem tudja, hogy a legkorábbi kísérletei működtek volna-e egy valódi rendszeren. Egy kísérlet csak egy kopogtatás az ajtón. Szóval mennyire rossz a helyzet valójában? A watchTowr szerint a nyilvánosan keringő exploitok többnyire összeomlanak vagy nem csinálnak semmit. A VulnCheck szerint a kódvégrehajtás bizonyos beállításokban működik, és a nyilvánosak közül egyik sem győzi le a memóriavéletlenszerűsítést a standard x86 szervereken. Elias Taylor kutató szerint közel sem olyan könnyű, mint a Log4Shell.

3:40 Mindenki továbbra is azt mondja, hogy javítani kell. A kormányok nem vártak az ítéletre.

Mit kapcsoltak le a kormányok?

3:44 Az NSA azt mondta azoknak a szervezeteknek, amelyek nem tudtak javítani, hogy vegyék le a PHP rendszereket offline állapotba, és az Egyesült Királyság Nemzeti Kiberbiztonsági Központja hasonló tanácsot adott. Holland oldalak, beleértve a nemzeti digitális identitásszolgáltatást is, sötétségbe borultak, valamint egy párizsi rendőrségi oldal. A Wikimedia óvintézkedésként több rendszert is leállított. A Palo Alto Networks több mint huszonkét millió sebezhető példányt számolt össze. És egy ausztrál professzor tette a legélesebb megjegyzést. Azok az oldalak aggasztóak, amelyek ma nincsenek leállítva.

Mely PHP verziók kapnak javítást?

4:11 Javítások léteznek a PHP nyolc pont kettő és nyolc pont ötös verzióihoz. A hét pont négyes, nyolc pont nullás és nyolc pont egyes verziókhoz a PHP csak forráskód-javításokat tett közzé. A régebbi verziók semmit sem kapnak a PHP projekttől, ezért kérdezze meg a disztribútorát. A kerülőutak csökkentik az esélyeket, de a PHP szerint a frissítés az egyetlen teljes javítás. Ez ugyanaz a lecke, mint a tegnapi eMudhra epizódban,

Mit tegyen ma este a PHP2Shell ellen?

4:32 mert egy létező javítás nem ugyanaz, mint ha a futó folyamat rendelkezne vele. Keresse meg az összes PHP-t a veremben, még a más szoftverekben rejtőző másolatokat is. Frissítsen, indítsa újra a munkafolyamatokat, és ellenőrizze a naplókat egészen október tizenhetedikéig. Ugyanezen a napon a GitLab kiadott egy kritikus javítást,

Mi más adott ki ma kritikus RCE javítást?

4:47 tizenkilenc pont öt pont egyest. Egy egész túlcsordulás a reguláris kifejezés fordítójában lehetővé teszi egy nem hitelesített felhasználó számára, hogy kódot futtasson a szerveren, és tízes pontszámot kapott. A GitLab.com már javítva van. Az önállóan kezelt telepítéseknek szükségük van a frissítésre.

Miért kapott a Meta 25 milliárd dolláros büntetést?

5:01 Eközben Új-Mexikóban egy bíró elrendelte, hogy a Meta fizessen huszonöt milliárd dollárt büntetésként a Cambridge Analytica ügyében. Az esküdtszék több mint negyvenhárom millió jogsértést számolt, akár ötezer dolláros tételeket, ami körülbelül kétszázhúsz milliárd dollárt tett ki, mielőtt a bíró csökkentette. A Meta azt mondja, fellebbezésben nyer majd. Most az ígért védekezés.

Mi a Chainguard védelme a korai javításra?

5:19 A Chainguard vezérigazgatója azt mondta a The Registernek, hogy ő maga is megtalálta ugyanazokat a hibákat egy péntek esten, miután megtudta, hogy valami jön a PHP-ban, egy alapvető felszólítással a rossz sebezhetőségek megtalálására. Azt mondja, azért adta ki korán, mert az embereket már támadták. Ha inkább olvasná ezt, mint hallaná tőlem, a "diff" minden reggel ingyen érkezik a postaládájába a thedailydiff.dev címen, link lent. Szóval a mai ítélet: SHIP IT.

Mi kapja a SHIP IT pecsétet?

5:39 Adja ki a PHP frissítést ma este, mert az új verziószám az egyetlen teljes javítás. És ez a mai "diff". Én Niko vagyok az Axrisiből. Felelősségteljesen egyesítse.

Források

1. Today's PHP Security Release, and How We're Strengthening PHP SecurityThe PHP Foundation
2. RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)PHP security advisory
3. RCE via stale global state (GHSA-6wmf-4rv5-p3rp)PHP security advisory
4. Upcoming Critical PHP Security Releasephp.net
5. php2shellCalif
6. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the InternetWiz Research
7. Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPotAWS Security Blog
8. Critical Vulnerabilities in PHP Require Immediate PatchingCISA
9. Flaw in PHP computer language leads to shutdown of websites around worldThe Guardian
10. What is PHP, and how bad is the computer language flaw causing website shutdowns globally?The Guardian
11. PHP2Shell Exploitation Started Days Before PatchesSecurityWeek
12. PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619Tanium
13. There isn't an easy exploit for this PHP vulnerabilityElias Taylor
14. PHP blames supply chain security biz Chainguard for putting entire web at riskThe Register
15. PHP2Shell: 22M exposed servers at risk as emergency patches releasedTechTarget
16. PHP ships emergency patches for critical PHP2Shell flawsBleepingComputer
17. GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13GitLab
18. Meta ordered to pay $25 billion penalty in New Mexico Cambridge Analytica caseCNBC
19. Tell HN: 2x PHP RCE CVEs with CVSS 10.0 IncomingHacker News