PHP2Shell: AI abil uuritud kriitilised vead panevad proovile paranduste katvuse

Mis muutus 21. oktoobril?

PHP ametlikud turvateated liigitavad mõlemad probleemid kriitiliseks. Toetatud harude parandused jõudsid versioonidesse 8.2.35, 8.3.36, 8.4.27 ja 8.5.12. PHP allalaadimisleht märgib nende väljalasete kuupäevaks 21. oktoobri. Ka sõltumatu Help Net Security kajastas samal päeval paranduste avaldamist.

See on uudise oluline ajapiir: avalikustamine ei tähenda, et nõrkus tekkis alles sel päeval. Wizi ajajoon paigutab esimese leiu augustisse ning kirjeldab koordineeritud tööd enne avalikku teadet. Meie artikli kuupäev tähistab seetõttu paranduste ja uurimistulemuste avalikustamist, mitte esmast avastamist. Wizi lehe esmane ajatempel vastab 21. oktoobri kella 16.59.59-le Eesti aja järgi.

Wiz tänab uurimise, koordineerimise ja paranduste kontrollimise eest PHP meeskonda, Califi ja OpenAI-d. Ettevõtte enda kirjelduse järgi aitasid mudelid keerulisi mäluprobleeme mõista, katsetulemusi analüüsida ja töötavaid demonstratsioone kohandada. See annab konkreetse näite AI kasutamisest turvauurimises, kuid pole sõltumatu mõõtmine sellest, kui palju oleks sama töö ilma mudeliteta aega võtnud.

Viga on PHP mootoris, mõju sõltub keskkonnast

Kõrgel tasemel puudutavad vead päringu lõppemisel ja järgmise päringu alguses kasutatava mälu ning sisemise oleku haldamist. Ühe probleemi keskmes on mälupuuduse käsitlemine; teise puhul võib päringuga seotud olek jääda püsima pärast selle mälu vabastamist. Ametlikud teated kirjeldavad nii kinnitatud juhtumeid kui ka tingimuslikult mõjutatud käituskeskkondi.

See eristus on haldajale olulisem kui üldine hirmutav levikunumber. Näiteks eristab PHP dokumentatsioon Apache mod_php kinnitatud ärakasutamist PHP-FPM-i tingimuslikest radadest. Mõne variandi toimimiseks on vaja sobivat rakenduse käitumist või seadistust. Ühest demonstratsioonist ei saa järeldada, et iga PHP veebileht on täpselt samal moel rünnatav.

Samas ei piisa riski välistamiseks sellest, et veebirakenduse enda kood pole muutunud. Probleem paikneb rakenduse all olevas käitusmootoris. Wizi demonstratsioonides kasutatud sisuhaldussüsteemid näitavad võimalikku mõju, kuid neid ei tohi pidada ainsateks mõjutatud toodeteks. Samuti ei tähenda PHP laialdane kasutamine veebis, et sama osakaal saite oleks kontrollitult ärakasutatav.

Mida AI rollist saab järeldada?

Meie hinnangul on loo keskne AI-küsimus keerukuse praktiline hind. Kui mudel aitab uurijal katsete tulemusi tõlgendada ja ebaõnnestumisi analüüsida, võib varem aeglane töö muutuda kättesaadavamaks. See võib aidata kaitsjatel vanu probleeme avastada, kuid vähendada ka ajavaru pärast tehniliste üksikasjade avalikuks saamist.

Üks juhtum ei anna siiski üldist kiirenduskoefitsienti. Võrdluseks oleks vaja samalaadseid ülesandeid, ühesuguseid tööriistu ja kontrollitud tingimusi. Uurijate hinnang AI panusele on sisuline allikateave; sellest erineb tõend, et kõik sarnased turvauuringud muutuvad kindla arvu kordi kiiremaks. Seda teist väidet kasutatud materjalid ei tõenda.

Organisatsiooni jaoks ei sõltu parandamisvajadus sellise koefitsiendi teadmisest. Kui kasutuses on mõjutatud komponent, tuleb hinnata konkreetset kokkupuudet ja rakendada tootja parandust. AI olemasolu muudab riskijuhtimise ajasurvet võimalikul määral, kuid varade leidmise, muudatuse tegemise ja tulemuse kontrollimise töö jääb endiselt vajalikuks.

AI-Radari vaade: mõõda parandatud varasid

Esimene praktiline küsimus on, kus PHP üldse töötab. Meie soovitus on vaadata koos servereid, konteinerikujutisi, majutusteenuseid ja vanu rakendusi. Ühes masinas võib olla mitu paralleelset versiooni. Veebipäringuid teenindav keskkond ja halduri käsureal nähtav versioon võivad samuti erineda, mistõttu üks kontroll ei peaks automaatselt esindama kogu teenust.

Teine küsimus on paranduse tõend. Paketi allalaadimine, uue konteinerikujutise loomine ja selle tootmises käivitamine on erinevad sammud. Kontrolliaruandes võiks olla vara omanik, kasutatav haru, tarnija parandusteade, paigalduse aeg ning tõend töötava teenuse versiooni kohta. Tarnija tagasiporditud paranduse puhul tuleb lähtuda tema turvateatest, mitte ainult upstream-versiooninumbrist.

Kolmas küsimus puudutab erandeid. Kui mõnda teenust ei saa kohe uuendada, vajab see vastutajat ja ajaliselt piiratud tegevusplaani. PHP ametlikud teated rõhutavad, et üldine seadistusmuudatus ei asenda täielikku parandust. Ajutiste meetmete valik peaks lähtuma konkreetse keskkonna tootjajuhistest. Veebitulemüüris nähtav reegel ei ole iseenesest tõend, et kõik variandid on kõrvaldatud.

Neljas küsimus on mõõdik. AI-Radari soovitus on näidata eraldi varade inventuuri katvust ja kontrollitult parandatud varade osakaalu. Ainult suletud piletite arv võib peita unustatud teenuseid. Aega võiks mõõta avalikust teabest vastutaja määramiseni, paranduse paigaldamiseni ja töötava keskkonna kontrollini. Nii muutub AI turvauudise jälgimine konkreetseks haldustulemuseks.