CVE-2026-45185 Dead.Letter: vienas baitas į atlaisvintą atmintį — ir jūsų pašto serveris priklauso kažkam kitam

Exim priėmė TLS ryšį. Klientas pradėjo siųsti laiško turinį per BDAT, tada staiga — perdavimo viduryje — išsiuntė TLS close_notify, sesijos pabaigos signalą. Exim atlaisvino buferį. Bet įdėtinis BDAT gavimo tvarkytuvas toliau skaitė baitus ir iškviestė ungetc(), įrašydamas vieną simbolį \n į jau atlaisvintą atmintį. Vienas baitas. Į alokatorius metaduomenis. To pakanka autentifikavimo nereikalaujančiam RCE.

CVE-2026-45185, pavadinta Dead.Letter — use-after-free Exim BDAT analizatoriuje naudojant GnuTLS. CVSS 9.8, CWE-416 (Use After Free). Paveiktos versijos: 4.97–4.99.2, sukompiliuotos su parametru USE_GNUTLS=yes. Pataisymas išleistas 2026 m. gegužės 12 d. versijoje 4.99.3. PoC viešas; aktyvaus išnaudojimo duomenų pataisymo išleidimo metu nebuvo — tačiau nuo tada praėjo trys savaitės.

Pažeidžiamybę rado tyrėjas Federico Kirschbaum iš XBOW Security, kuris savo paties žodžiais niekada anksčiau nebuvo skaitęs nė eilutės Exim kodo. Būtent tai daro šią istoriją įdomią: klaida slėpėsi devynerius metus.

KAS YRA EXIM IR BDAT

Exim — vienas labiausiai paplitusių Mail Transfer Agent Unix sistemose. Debian, Ubuntu ir jų pagrindu sukurti distribucijos istoriškai tiekia Exim kaip numatytąjį MTA, o dauguma tokių surinkimų naudoja GnuTLS kaip TLS biblioteką. Tai reiškia, kad milijonai pašto serverių visame pasaulyje yra potencialiai paveikti — vien todėl, kad veikia Debian pagrindu sukurtoje sistemoje.

BDAT — tai SMTP plėtinys, vadinamas CHUNKING (RFC 3030). Vietoj tradicinės komandos DATA, kuri baigia laiško turinį tašku atskiroje eilutėje, BDAT leidžia klientui perduoti turinį fragmentais nurodant tikslų dydį: BDAT 1234, BDAT 5678 LAST. Tai efektyviau dideliems laiškams ir palaikoma pagal nutylėjimą šiuolaikinėse Exim versijose — jokios specialios konfigūracijos nereikia.

Svarbu suprasti struktūrą: kai Exim veikia per TLS, yra du lygmenys — TLS sesija, valdanti šifravimą per GnuTLS, ir SMTP lygmuo, analizuojantis komandas ir laiško turinį. Problema kyla šių dviejų lygmenų sandūroje, kai TLS užsidaro anksčiau, nei SMTP tvarkytuvas suspėja baigti darbą.

KAIP VEIKIA KLAIDA

Po sėkmingo TLS rankos paspaudimo Exim paskiria perdavimo buferį per store_malloc() ir pakeičia standartines SMTP gavimo funkcijas TLS apvalkalais. Šis buferis — xfer_buffer — gyvena GnuTLS sesijos būsenos viduje ir atlaisvinamas uždarant TLS ryšį.

Pažeidžiama seka atrodo taip: klientas užmezga TLS ryšį, siunčia komandą BDAT ir pradeda perduoti laiško turinį. Perdavimo viduryje — prieš išsiunčiant paskutinį fragmentą su žyme LAST — klientas siunčia TLS close_notify. GnuTLS gauna sesijos pabaigos signalą ir atlaisvina visus susijusius resursus, įskaitant xfer_buffer. Tačiau įdėtinis BDAT tvarkytuvas apie tai nežino: jis toliau laukia paskutinio baito ir iškviečia ungetc('\n', ...), įrašydamas eilutės pabaigos simbolį į jau atlaisvintą atminties sritį.

Tas vienintelis baitas patenka ant Exim alokatoriaus metaduomenų — struktūrų, aprašančių, kurie atminties blokai laisvi, kurie užimti ir koks jų dydis. Įrašas į alokatoriaus metaduomenis — tai ne tik atminties sugadinimas, tai galimybė kontroliuoti tolesnių malloc() ir free() iškvietimų elgseną. Būtent tai atveria kelią tolesniam išnaudojimui.

KAIP TAI IŠNAUDOJAMA

Vieno baito įrašas į alokatoriaus metaduomenis — silpnas primitivas, tačiau pakankamas. Kaip rašo Kirschbaum savo analizėje, šio įrašo pagrindu konstruojami stipresni primitivai: kontroliuojami įrašai į savavališkus adresus, leidžiantys galų gale perrašyti funkcijos rodyklę Exim proceso viduje.

Atakai paleisti reikia tik užmegzti TLS ryšį ir palaikyti BDAT — abu reikalavimai įvykdomi bet kurioje šiuolaikinėje GnuTLS pagrindu sukurtoje Exim konfigūracijoje. Jokio autentifikavimo, jokių kredencialų, jokių išankstinių žinių apie serverį. Vienintelis reikalavimas — kad Exim būtų surinktas su GnuTLS, o tai yra numatytasis Debian ir Ubuntu pasirinkimas.

XBOW atsakingo atskleidimo laikotarpiu tikrino, kaip toli galima nueiti kuriant išnaudojimą — tiek rankiniu būdu, tiek naudojant autonominius įrankius. Rezultatus jie apibūdina kaip pakankamai įtikinamus, kad pažeidžiamybę būtų galima drąsiai klasifikuoti kaip praktiškai išnaudojamą RCE, o ne teorinę heap corruption.

KAS VYKSTA TOLIAU — PRIKLAUSO NUO KONFIGŪRACIJOS

Exim paprastai veikia kaip neprivilegijuotas vartotojas — Debian-exim ar panašus. Jei systemd paslaugos vienetas nesukonfigūruotas su PrivateTmp, NoNewPrivileges ir capabilities apribojimais — užpuolikas gauna apvalkalą to vartotojo teisėmis. Tolesnė privilegijų eskalacija priklauso nuo likusios sistemos konfigūracijos.

Tačiau daugelyje serverių Exim kai kurioms operacijoms veikia su root teisėmis — pavyzdžiui, pristatydamas paštą vietiniams vartotojams per setuid bitus. Be procesų izoliacijos per systemd ar Linux namespaces, Exim kompromitavimas gali tiesiogiai suteikti root. Patikrinkite, kokio vartotojo teisėmis iš tikrųjų veikia procesas:

ps aux | grep exim

Pirmasis stulpelis — vartotojas. Jei ten root — sėkmingo išnaudojimo atveju užpuolikas iš karto gauna root prieigą. Jei Debian-exim ar kitas neprivilegijuotas vartotojas — žala apribota to proceso teisėmis, bet RCE vis tiek įvyko.

Jei serveris naudoja Exim tik kaip relay ir nepriima pašto iš atsitiktinių išorinių klientų — praktinė rizika mažesnė. Tačiau jei prievadai 25, 465 ar 587 atvirai pasiekiami iš interneto ir Exim versija pažeidžiama — tai tiesioginis atakos paviršius be jokių kliūčių.

REALUS ATAKOS SCENARIJUS

Žvalgyba greita. Užpuolikas nuskaituoja 25 prievadą, nuskaito SMTP antraštę su Exim versija, siunčia EHLO ir tikrina plėtinių sąrašą. Jei serveris atsako 250-CHUNKING — BDAT palaikomas. Jei antraštė ar kiti fingerprinting metodai patvirtina versiją iš diapazono 4.97–4.99.2 — serveris taikiklyje. Visa tai trunka sekundes ir nereikalauja nei kredencialų, nei specialių įrankių.

Toliau — užmegzti TLS ryšį ir atkurti pažeidžiamą seką: išsiųsti BDAT, pradėti perduoti turinį, viduryje nusiųsti TLS close_notify, tada paskutinį baitą atviru tekstu. Exim įrašo \n į atlaisvintą atmintį. Serveris arba lūžta, kas patvirtina pažeidžiamybę, arba — esant teisingai paruoštai heap išdėstymui — toliau veikia su sugadintais alokatoriaus metaduomenimis, atveriant kelią pilnam išnaudojimui.

Būtent šią dalį — nuo heap corruption iki pilno RCE — XBOW tyrė atsakingo atskleidimo laikotarpiu. Tai ne trivialus uždavinys: reikia suprasti Exim alokatoriaus elgseną esant konkretiems alokacijos šablonams, konstruoti stipresnius primitivus iš silpno vieno baito įrašo, rasti būdą perrašyti funkcijos rodyklę. Kirschbaum viešai tai apibūdino kaip įgyvendinimą — ir XBOW tai patikrino tiek rankiniu būdu, tiek autonominiais įrankiais. Paruošto išnaudojimo iki apvakalo atskleidimo metu nebuvo, tačiau tai laiko ir užpuoliko motyvacijos klausimas.

LAIKO JUOSTA

2026 m. gegužės 1 d. Federico Kirschbaum iš XBOW Security išsiuntė pirmąjį pranešimą Exim komandai. Tai buvo jų autonominio pažeidžiamybių paieškos įrankio rezultatas — paminėtina, kad pats Kirschbaum niekada anksčiau nedirbo su Exim kodo baze.

Gegužės 4 d. Kirschbaum paklausė apie pranešimo nagrinėjimo statusą. Gegužės 5 d. Exim palaikytojai patvirtino pažeidžiamybę ir pranešė, kad privatus pataisymas jau kuriamas. Gegužės 7 d. prasidėjo atskleidimo koordinavimas su distribucijų palaikytojais.

2026 m. gegužės 12 d. paskelbta CVE-2026-45185 ir tą pačią dieną išleistas Exim 4.99.3 su pataisymu. Tą pačią dieną XBOW paskelbė Dead.Letter analizę su techninėmis detalėmis. Viešas aptikimo skriptas GitHub’e pasirodė netrukus po atskleidimo.

Vienuolika dienų nuo pirmojo pranešimo iki viešo pataisymo — greita, ypač open source projektui su nedidele palaikytojų komanda. Tai tapo įmanoma todėl, kad XBOW iš pradžių pateikė išsamų, tikslų pranešimą — Exim komanda galėjo iš karto imtis taisymo, negaišdama laiko problemai atkurti.

KODĖL TAI SVARBU

Exim — ne siauros nišos programinė įranga. Ji apdoroja didelę interneto pašto srauto dalį, o dauguma Debian/Ubuntu įdiegimų naudoja GnuTLS. Pašto serveriai pagal prigimtį atvirai pasiekiami iš interneto ir priima ryšius iš bet kokių klientų — vienintelė kliūtis tarp užpuoliko ir šios klaidos yra Exim versija ir TLS biblioteka.

Potencialiai pažeidžiamų sistemų mastas ypač nerimą kelia: daugelis prieglobos paslaugų teikėjų ir VPS operatorių tiekia vaizdus su Exim iš anksto įdiegtu. Sistemos administratoriai, kurie niekada specialiai nekonfigūravo MTA, gali nežinoti, kad jų serveryje apskritai veikia Exim — juo labiau su kokia TLS biblioteka jis surinktas.

Galiausiai — istorinis kontekstas: use-after-free BDAT komponente jau egzistavo Exim 2017 metais — CVE-2017-16943, taip pat CVSS 9.8. Ta pati sritis, ta pati klaidos klasė, devyneriais metais vėliau. Tai ne aplaidumas — tai signalas, kad riba tarp TLS sluoksnio ir SMTP tvarkytuvos Exim viduje struktūriškai sudėtinga ir sunkiai tikrinama. Geroji žinia: XBOW rado šią klaidą įrankiais, nepraėję mėnesių kodo bazėje. Blogoji: tie patys įrankiai pasiekiami ir užpuolikams.

ATNAUJINIMAS

Oficialus Exim advisory nedviprasmiškas: jokios kitos išeities nėra — tik atnaujinimas iki 4.99.3. Jokių konfigūracinių vėliavėlių, jokio „išjungti CHUNKING ir palaukti” — tik pataisymas.

Pirmiausia — patikrinti Exim versiją ir TLS biblioteką. Komanda exim -bV išveda surinkimo detales — versiją, kompiliacijos datą ir palaikomų galimybių sąrašą, kuriame bus nurodyta TLS biblioteka:

exim -bV | grep -E "version|TLS"

Ieškokite versijos eilutės ir palaikymo sąrašo. Jei matote GnuTLS ir versiją žemiau 4.99.3 — serveris pažeidžiamas ir reikia atnaujinti nedelsiant. Jei vietoj GnuTLS matote OpenSSL — šis surinkimas pažeidžiamybės neveikiamas.

Debian/Ubuntu sistemose atnaujinti per apt. Pirmiausia patikrinkite, ar saugykla jau turi pataisytą versiją:

apt-cache policy exim4

Žiūrėkite į eilutę Candidate:. Jei ten versija 4.99.3 ar naujesnė — atnaujinkite:

apt update && apt install exim4

Jei saugykla dar neatnaujinta — atsisiųskite tiesiogiai iš oficialaus Exim FTP. Abu adresai nurodyti oficialiame advisory: ftp.exim.org/pub/exim/exim4/ ir code.exim.org/exim/exim/releases. Atsisiųsti ir išpakuoti:

wget https://ftp.exim.org/pub/exim/exim4/exim-4.99.3.tar.xz
tar xf exim-4.99.3.tar.xz

Surinkimas iš šaltinio kodo reikalauja priklausomybių ir konfigūracinio failo Local/Makefile — daugumai produkcinių serverių paprasčiau palaukti, kol saugykla atsinaujins, nei rinkti rankiniu būdu. Jei laukti negalima — rinkite su tais pačiais parametrais, kaip ir dabartinis įdiegimas (jie matomi exim -bV išvestyje). Po atnaujinimo patikrinkite versiją:

exim -bV | grep version

Išvestyje turi būti 4.99.3. Norint greitai patikrinti daug serverių — yra aptikimo skriptas iš liamromanis101 GitHub’e (Dead.Letter-CVE-2026-45185): jis tikrina versiją, TLS backend’ą ir konfigūraciją. Reikia teisių skaityti Exim konfigūracijos failą — paleiskite kaip root arba Debian-exim grupės vartotojas.

IŠVADOS

Dead.Letter: vienas baitas į atlaisvintą atmintį, CVSS 9.8, pažeidžiamybė komponente, kuris priima ryšius iš viso interneto be autentifikavimo. Oficialus Exim advisory nepalieka abejonių: jokios kitos priemonės nėra, tik atnaujinimas iki 4.99.3.

Patikrinkite dabar: exim -bV | grep -E "version|TLS". Jei matote GnuTLS ir versiją žemiau 4.99.3 — atnaujinkite. Jei saugykla dar neatnaujinta — atsisiųskite tiesiogiai iš ftp.exim.org. Tai ne užduotis kitam sprintui.