Attēlu augšupielāde, kas izraisīja OpenAI hakeru uzbrukumu — un kāpēc TYPO3 administratoriem tas ir svarīgi

2026. gada septembrī drošības pētniecības uzņēmums „Hacktron” publicēja rakstu, kurā aprakstīja, kā viņiem izdevās panākt koda attālinātu izpildi OpenAI piederošajā infrastruktūrā. Ieejas punkts bija gandrīz banāls: viņi augšupielādēja attēlu forumā. Tas, kas padara šo stāstu lasīšanas vērtu — un liek rīkoties —, ir tas, kur faktiski atradās šī kļūda un kā tā tika izmantota ļaunprātīgi.

Ja jūsu TYPO3 vietne pieņem attēlu augšupielādes un apstrādā tos ar ImageMagick vai GraphicsMagick, tad arī jums draud tāds pats apdraudējums. Šeit ir izklāstīts, kas notika, kāpēc parastais uzskats, ka „vainīgs ir ImageMagick”, ir nepareizs, un ko darīt, lai to novērstu.

OpenAI, tāpat kā tūkstošiem citu organizāciju, uztur kopienas forumu „Discourse “. „Discourse” ļauj lietotājiem augšupielādēt attēlus. Lai nolasītu attēlu izmērus, tas parasti izmanto vieglu Ruby bibliotēku ar nosaukumu „FastImage”. Taču „FastImage” neatpazīst Apple HEIC/HEIF fotoformātu — tāpēc, kā stāsta Hacktron, „Discourse” šos failus tā vietā nodeva „ImageMagick” komandai „magick ”.

Šī nodošana ir visa stāsta būtība. ImageMagick pats par sevi nedekodē HEIC. Tas deleģē šo uzdevumu atsevišķai bibliotēkai ar nosaukumu libheif. Un libheif versija, kas bija instalēta serverī — iegūta no pamatoperētājsistēmas attēla — saturēja krātuves bufera pārpildījumu, ko varēja izraisīt vienkārši, analizējot ļaunprātīgu HEIC failu.

No šī brīža seko klasiskais atmiņas bojājuma ķēdes posms: bufera pārpildījums, kas rada ārpus robežām esošas lasīšanas un rakstīšanas operācijas, pakāpeniski pārvēršoties par procesa kontroli. Uzbrucējs augšupielādē attēlu; serveris mēģina izveidot tā sīktēlu; attēls izpilda kodu. „Hacktron” ziņoja, ka, izmantojot šādi iegūto atbalsta punktu, tas caur kompromitētiem darbinieku kontiem piekļuva iekšējiem repozitorijiem.

Šī ievainojamība nekad nav bijusi pašā „ImageMagick”. „ImageMagick” bija tikai ieejas durvis, kas veda uz bibliotēku ar faktisko ievainojamību.

Šis ir sīkums, ko cilvēki bieži pārprot, tāpēc ir vērts to skaidri norādīt. ImageMagick un GraphicsMagick ir koordinatori. Visiem formātiem, kas ir sarežģītāki par vienkāršākajiem, tās izmanto specializētas bibliotēkas — libheif HEIC/AVIF formātiem, Ghostscript PDF un EPS formātiem, renderētāju SVG formātam un tā tālāk. Ja kādā no šīm izmantotajām bibliotēkām ir atklāta kļūda, kas apdraud atmiņas drošību, rīks, kas to izsauc, pilnībā pārņem šo ievainojamību.

No tā izriet divas sekas, un abas ir svarīgas, lai jūs varētu sevi aizsargāt:

• ImageMagick atjaunināšana šo problēmu neatrisina. Vajadzīgais labojums atrodas libheif (un tās kodekos), kas tiek piegādāts caur jūsu operētājsistēmu, nevis pašā attēlu apstrādes rīkā.
• Pāreja uz GraphicsMagick to arī neizlabo. GraphicsMagick ir ImageMagick atzars ar tādu pašu arhitektūru un, HEIC gadījumā, to pašu delegēto bibliotēku pamatā. Tam ir reputācija kā konservatīvākam rīkam — pēc noklusējuma tas ietver mazāk neparastu dekodētāju un izvairījās no slavenajiem 2016. gada „ImageTragick” trūkumiem —, taču attiecībā uz šāda veida kļūdām tas atrodas tieši tajā pašā situācijā. Tajā arī trūkst ImageMagick faila policy.xml, tāpēc to faktiski ir grūtāk ierobežot ar konfigurāciju.

Hacktron turpināja izsekot tai pašai libheif neaizsargātībai plašā labi zināmu platformu un ietvaru sarakstā — turpinājumu, ko viņi nosauca par „HEIF Heist”. Jautājums nav tajā, ka vienam forumam nepaveicās. Jautājums ir tajā, ka viena trausla C bibliotēka atrodas nepamanīta zem milzīga daudzuma programmatūras, kas pieņem lietotāju augšupielādētus attēlus.

Šeit ir pavērsiens, kas padara šo gadījumu par kaut ko vairāk nekā vienkārši vēl vienu stāstu par CVE. „Hacktron“ ir mākslīgā intelekta drošības uzņēmums, un šis ekspluatācijas kods tika izstrādāts, izmantojot lielu valodas modeli, kas darbojās kā autonoms aģents.

Pēc viņu teiktā, interesantākais šķērslis bija ASLR — adreses telpas izkārtojuma randomizācija, standarta aizsardzības mehānisms, kas izkliedē atmiņu tā, lai uzbrucējs nevarētu paredzēt, kur kas atrodas. Sākumā viņi izveidoja darbojošos ekspluatācijas rīku ar atslēgtu ASLR. Padarīt to uzticamu pret standarta konfigurāciju ar ieslēgtu ASLR ir patiesi grūts un sarežģīts pētniecības uzdevums. „Hacktron” ziņoja, ka viena modeļa paaudze nespēja to uzticami paveikt, bet nākamā — kas tika izlaista, kamēr viņi vēl strādāja — to atrisināja dažu stundu laikā.

To jāuztver ar atbilstošu piesardzību: tas ir ražotājs, kas stāsta labu stāstu par saviem rīkiem, un sīkāk izstrādātie apgalvojumi ir viņu pašu, nevis neatkarīgi pārbaudīti. Taču virziens, kurā notiek attīstība, ir reāls un ir vērts tam pievērst uzmanību. Izmantošanas metožu izstrāde pret atmiņas bojājumu kļūdām vienmēr ir bijusi specializēta, darbietilpīga nodarbe — tas, kas neļāva daudzām teorētiski izmantojamām kļūdām kļūt par praktiskiem uzbrukumiem. Ja AI aģenti turpinās samazināt šo darba apjomu, atšķirība starp „kļūda pastāv” un „kļūda tiek izmantota pret jums” kļūs mazāka. Nepievilcīgais darbs, kas saistīts ar labojumu tūlītēju ieviešanu, vairs nebūs fakultatīvs.

TYPO3 strukturāli darbojas tāpat kā Discourse. Tas pieņem failus caur administrācijas saskarni un daudzās vietnēs — arī caur lietotāja saskarnes veidlapām. Tā apstrādā attēlus — maina izmēru, apgriež, veido sīktēlus — ar ārējo procesoru, kuru konfigurējat sistēmas iestatījumos sadaļā GFX, norādot procesoru ImageMagick vai GraphicsMagick un procesora ceļu (processor_path), kas norāda uz bināro failu. Katrs augšupielādētais attēls, kura izmērs tiek mainīts, tiek apstrādāts šajā procesā, kas izmanto tās pašas delegēto bibliotēku funkcijas.

Vairāki faktori nosaka, cik atklāta konkrētā vietne patiesībā ir:

• Kādus formātus jūs faktiski pieņemat un apstrādājat. Parastie JPEG/PNG/GIF/WebP attēli tiek apstrādāti ar salīdzinoši labi pārbaudītiem dekoderiem. Risks strauji pieaug, ja tiek izmantoti neparasti formāti — HEIC/AVIF, JPEG XL un jo īpaši PDF, EPS un SVG, kuru delegātiem (Ghostscript, SVG renderētāji) ir ilga vēsture attiecībā uz attālinātu koda izpildi.
• Kas var augšupielādēt. Ja augšupielāde ir ierobežota tikai uzticamiem aizmugures redaktoriem, uzbrukuma virsma ir šaura. Ja anonīma priekšgala veidlapa pieņem attēlus — avatarus, kontaktu veidlapas, komentārus —, jūs atrodaties tajā pašā situācijā, kādā bija Discourse.
• Ar kādu lietotāju tiesībām darbojas darba process. Ja jūsu PHP-FPM pūls darbojas ar to pašu lietotāju, kuram pieder vietnes faili un kurš glabā datubāzes piekļuves datus, koda izpilde attēla analizatorā nozīmē šīs vietnes pilnīgu kompromitēšanu.

Svarīgs brīdinājums. Standarta TYPO3 vietne sākotnējā konfigurācijā ne vienmēr nodod HEIC failus savam procesoram tā, kā to darīja „Discourse“ — konkrētais HEIC uzbrukuma vektors ir atkarīgs no jūsu izmantotajiem formātiem un konfigurācijas. Taču pamatā esošais modelis (neuzticams fails → ārējais dekoders → atmiņai nedroša C bibliotēka) ir tieši tas, kāds ir TYPO3 attēlu apstrādes process, un bibliotēkas, uz kurām tas balstās, ir tās pašas, kas šeit tiek izskatītas. Uztveriet to kā riska kategoriju, nevis atsevišķu CVE.

Risinājums ir vienkāršs, un tā ir laba ziņa. Aptuvenā ietekmes secībā:

1. Atjauniniet delegēto bibliotēku caur savas operētājsistēmas drošības kanālu — nevis ImageMagick. Kļūda bija libheif un tās kodekos (libaom, libde265). Debian/Ubuntu sistēmās tas nozīmē, ka jāpatur ieslēgti automātiskie drošības atjauninājumi vai arī tie nekavējoties jāuzstāda manuāli. Pārbaudiet instalēto versiju ar komandu dpkg -l | grep libheif.
2. Ja izmantojat Docker, pārveidojiet attēlu — nevis vienkārši to restartējiet. Tieši tāda bija Discourse faktiskā problēma: neaizsargāta libheif, kas bija iesaldēta konteineru attēlā. Vienkārša pārstartēšana saglabā veco, kešēto slāni. Veiciet pārveidošanu no jaunas bāzes, lai ielāpītā bibliotēka tiktu integrēta.
3. Ierobežojiet formātus ImageMagick failā policy.xml. Atvienojiet to, kas jums nav vajadzīgs — PDF, PS, EPS, MVG, MSL un HEIC/AVIF/JXL, ja jūsu vietne tos nekad neapstrādā. Tas noņem veselas delegātu kategorijas, pirms kāds uzbrucēja iesniegts fails tās sasniedz. (GraphicsMagick lietotājiem: jums nav pieejama šī iespēja, tāpēc vairāk koncentrējieties uz nākamajiem diviem punktiem.)
4. Ierobežojiet to, kas var augšupielādēt, un pārbaudiet reālos failu tipus — faktisko MIME parakstu, nevis paplašinājumu — īpaši jebkurā augšupielādes ceļā, kas ir pieejams anonīmiem lietotājiem.
5. Izolējiet apstrādi. Katrā vietnē izmantojiet atsevišķu lietotāju bez privilēģijām un atsevišķu PHP-FPM pūlu, lai koda izpilde vienas vietnes attēlu analizatorā nevarētu sasniegt citu vietni vai iegūt root tiesības. Tas pārvērš situāciju „viens kļūdas gadījums = viss serveris” par „viens kļūdas gadījums = viena vietne” — tas ir visvērtīgākais strukturālais risinājums, kāds jums var būt.

Nekas no šī nav vienreizējs uzdevums. Jaunas „libheif” ievainojamības turpināja parādīties visā 2026. gadā; vien vasarā tika izlaisti vairāki drošības atjauninājumi. Reālistisks mērķis nav „lāpīt uz visiem laikiem”, bet gan „lāpīt ātri un ierobežot ietekmi, ja jauna ievainojamība parādās pirms labojuma”. Ātri atjauninājumi aizver zināmās caurumus; izolācija ierobežo to ievainojamību ietekmes rādiusu, kuras vēl neviens nav atklājis.

Es pārvaldu tīmekļa serveri, un katrai vietnei tiek piešķirts savs lietotājs bez privilēģijām Linux vidē ar savu PHP-FPM pūlu. Tas praksē ir izolācijas punkts: ja kāds speciāli izveidots attēls kādreiz izpilda kodu vienas vietnes apstrādes procesā, tas darbojas kā šīs vietnes lietotājs un nekas vairāk. Tas var sabojāt šo vienu vietni — tās failus, datubāzes piekļuves datus —, bet tas nevar sasniegt kaimiņus vai iegūt root piekļuvi bez otrā, atsevišķa ievainojamības. „Viena kļūda = viena vietne”, nevis „viena kļūda = visa sistēma”.

Lai veiktu labojumus, es paļaujos uz automātiskajiem drošības atjauninājumiem, kuru darbības joma ir tikai -security katalogs, un automātiskā pārstartēšana ir atspējota. Parastos funkciju atjauninājumus es joprojām instalēju manuāli pēc īsa pārskata, bet drošības labojumi — tie, kas ir svarīgi tieši šim draudam — instalējas paši naktī. Kad es, rakstot šo rakstu, pārbaudīju žurnālus, izrādījās, ka sistēma jau pirms dažām dienām bija automātiski instalējusi libaom — AV1 kodeku, ko libheif izmanto AVIF dekodēšanai. Sistēma klusi laboja tieši to attēlu dekodēšanas ķēdi, par kuru ir šis stāsts, man to nemaz nepieskaroties.

Oriģinālais pētījums ir Hacktron pētījums: „Hacking OpenAI”.