8. jūlijā drošības pētnieks Sébastien Féry no FoxIO publicēja kļūdu Alibaba bibliotēkā XQUIC, kas ļauj jebkuram klientam nogāzt HTTP/3 serveri ar aptuveni 260 baitiem pilnīgi likumīgu datu. Nav vajadzīga ne autentifikācija, ne bojāta pakete — pietiek ar parastu QPACK plūsmu. Féry kļūdu nosauca par XRING. Uz 10. jūliju labojuma nav, un CVE numurs nav piešķirts.
XQUIC ir Alibaba atvērtā koda QUIC un HTTP/3 realizācija, ko uzņēmums izmanto pats savā Nginx atvasinājumā Tengine. Pēc FoxIO ziņām, Tengine apkalpo Alibaba mākoni un CDN tādām vietnēm kā Taobao un Alipay. Kļūda skar katru serveri, kas iekļauj XQUIC un apkalpo HTTP/3 ar noklusējuma QPACK iestatījumiem, arī tos, kam ar Alibaba nav tieša sakara.
Kā 260 baiti nogāž procesu
QPACK ir HTTP/3 galveņu saspiešanas mehānisms — HTTP/2 laika HPACK pēctecis, aprakstīts RFC 9204. Tā dinamiskā tabula glabā biežāk lietotās galvenes, lai klients un serveris tās nesūtītu atkārtoti pilnā tekstā. Klients ar atsevišķu encoder plūsmu norāda serverim, ko ielikt šajā tabulā un cik liela tā drīkst būt. Standarts šo tabulu nepadara par obligātu: serveris drīkst norādīt ietilpību 0 un iztikt bez tās. Tieši šī izvēles brīvība vēlāk noder par glābiņu.
Tieši tabulas izmēra maiņā slēpjas kļūda. Kad tabula aug — teiksim, no 64 baitiem uz 65 — un rakstīšanas kursors ir tuvu beigām, XQUIC pārrēķina, cik astes baitu jāpārvieto uz jauno buferi. Bibliotēka nolemj, ka pārvietojami 70 baiti, lai gan patiesībā to ir 6. Nepareizais skaitlis nonāk atmiņas kopēšanas izsaukumā. Kopējamā garuma aprēķins atņem šo pārrēķinu no mazāka skaitļa; tā kā tips ir bezzīmes size_t, rezultāts pāriet cauri nullei un kļūst par gandrīz maksimālo iespējamo vērtību. Kopēšana aiziet ārpus atmiņas robežām, un process avarē.
FoxIO testā uz Ubuntu 26.04 glibc aizsardzība _FORTIFY_SOURCE=2 pamanīja aplamo garumu un uzreiz nogalināja procesu. Tas nozīmē, ka konkrētajā būvējumā izpausme ir avārija, nevis koda izpilde uzbrucēja rokās. Uz citiem būvējumiem un kompilatora iestatījumiem šī robeža var izskatīties citādi.
Kļūda dzīvo kopš 2022. gada
Pēc The Hacker News apraksta aplamais aprēķins XQUIC kodā ir kopš pirmā publiskā laidiena 2022. gada janvārī. Skarti visi laidieni līdz jaunākajam — v1.9.4. Iemesls, kāpēc kļūda tik ilgi palika nepamanīta, ir vienkāršs: parasta pārlūka trafiks nekad neaizved dinamisko tabulu tieši tajā stāvoklī, kas iedarbina aplamo pārrēķinu. To panāk tikai speciāli sagatavota encoder plūsma.
Uzbrukumam nav vajadzīga sesija vai konts. Serveris avarē, apstrādājot datus, kas pēc formāta ir pilnīgi derīgi — tāpēc parastie filtri to nepamana.
Cik nopietns ir pieejamības zudums
XRING nedod uzbrucējam datus vai piekļuvi — vismaz FoxIO pārbaudītajā būvējumā. Iegūtais ir process, kas apstājas. Publiskam HTTP/3 galapunktam tas ir pietiekami: viens klients ar pāris simtiem baitu var atkārtoti nogāzt strādnieka procesu un turēt pakalpojumu nepieejamu tik ilgi, cik grib. Nav ne rate-limit, ko apiet, ne CPU izsīkuma, ko pamanīt — process vienkārši mirst uzreiz.
Mērogs padara to nepatīkamu. QUIC un HTTP/3 ir standartizēti kā RFC 9000 un RFC 9114, un tos jau apkalpo lielākie CDN un mākoņu priekšgali. Ja Tengine tiešām stāv Taobao un Alipay priekšā, kā apgalvo FoxIO, tad runa ir par vienu no lielākajām e-komercijas plūsmām pasaulē, ko teorētiski var apturēt no vienas klienta saites.
XQUIC drošības problēmas nav jaunas
Šī nav pirmā DoS kļūda QUIC bibliotēkās. NCC Group un Fox-IT pērn publicēja kopīgu brīdinājumu par jaucējfunkciju DoS deviņās QUIC realizācijās, tostarp XQUIC 1.8.1 un vecākos (labots 1.8.2). Tur uzbrucējs izvēlējās savienojuma identifikatorus, kas sadūrās serverja jaucējtabulā, un ar 10 000 paralēliem savienojumiem panāca 300 reižu palēninājumu. XRING ir cita kļūda — atmiņas, ne jaucēju — bet tā pati aina: neliela derīgu datu porcija rada nesamērīgu slodzi vai avāriju.
Abas kļūdas norāda uz to pašu vājo vietu jaunajos protokolos. QUIC un HTTP/3 pārcēla lielu daļu loģikas no kodola uz lietotāja telpas bibliotēkām, un šīs bibliotēkas vēl ir jaunas. XQUIC pirmkodu var apskatīt GitHub, un tur redzams, cik daudz manuāla atmiņas darba ir aiz vienas galveņu saspiešanas.
Ko darīt tagad
Kamēr labojuma nav, FoxIO iesaka divus soļus. Pirmais — iestatīt SETTINGS_QPACK_MAX_TABLE_CAPACITY uz 0, kas izslēdz QPACK dinamisko tabulu. Tieši šī tabula ir kļūdas avots, tāpēc bez tās uzbrukuma vairs nav. Otrais, radikālākais — atslēgt HTTP/3 pavisam un palikt pie HTTP/2 caur TCP.
Ja tu neekspluatē XQUIC tieši, tomēr ir vērts pārbaudīt, ko izmanto tavs reversais starpniekserveris un CDN. Tengine un daži Alibaba mākoņa priekšgali balstās uz XQUIC, tāpēc pakalpojums, kuru tu pērc, var būt skarts, pat ja tavā kodā QUIC nav nemaz. Administratoriem, kuri paši būvē HTTP/3 galapunktus, tagad ir laiks pārbaudīt QPACK iestatījumu, nevis gaidīt CVE numuru — labojums var aizkavēties, jo Alibaba līdz šim uz atklājumu publiski nav reaģējusi.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.