BIND 9 patch rregullon 14 dobësi në serverin DNS, një rrëzim DoH

Internet Systems Consortium (ISC), organizata që mirëmban BIND 9, ka publikuar BIND 9.20.29 dhe 9.21.26 për të rregulluar katërmbëdhjetë dobësi sigurie në softuerin e serverit DNS me burim të hapur, të gjitha të shpallura më 16 shtator. Njëra prej tyre prek çdo server BIND 9 që përgjigjet për DNS-over-HTTPS (DoH), një mënyrë për të transportuar kërkimet DNS, sistemi që kthen një emër domeni në adresën e një serveri, brenda trafikut normal të kriptuar të web-it. ISC thotë në njoftimet e saj se një dërgues pa asnjë kredencial mund të rrëzojë procesin e serverit, named, me një kërkesë të vetme që mban një nënshkrim SIG(0) të pavlefshëm, me kusht që dërguesi ta mbyllë lidhjen përpara se named të përfundojë kontrollin e atij nënshkrimi. ISC shton se nuk është në dijeni që ndonjëra nga katërmbëdhjetë dobësitë të jetë shfrytëzuar.

Cili përditësim rregullon çfarë varet nga dega që është në punë. BIND 9.20.29, në degën aktuale të qëndrueshme, rregullon të katërmbëdhjetë. BIND 9.21.26, në degën e zhvillimit, rregullon trembëdhjetë, sepse CVE-2026-19662 nuk prek 9.21. Edicioni i Parapamjes i Mbështetur për klientët me kontratë mbështetjeje, 9.20.29-S1, rregullon të katërmbëdhjetë, duke përputhur me intervalet -S1 të listuara në njoftimet e ISC. ISC nuk liston asnjë zgjidhje alternative për asnjërën nga katërmbëdhjetë, kështu që aplikimi i përditësimit është i vetmi ilaç që ofron.

Instalimet më të vjetra janë në një pozicion më të vështirë. Dymbëdhjetë nga katërmbëdhjetë prekin degën 9.18, deri dhe duke përfshirë 9.18.50, publikimin e saj të fundit. ISC e mbylli mbështetjen për 9.18 në fund të qershorit dhe nuk liston asnjë publikim 9.18 që i rregullon ato. Në maj tha se përdoruesit e 9.18 duhet të planifikojnë kalimin në 9.20 sa më shpejt të jetë e mundur, dhe matrica e saj e dobësive thotë se versionet e përfunduara duhet të supozohen të prekshme nga CVE-të e reja, identifikuesit standardë që u jepen dobësive të sigurisë të kataloguara publikisht. Paketat e sistemit operativ janë çështje më vete: Debian 12 sjell një paketë të bazuar në 9.18.49, dhe gjurmuesi i saj i sigurisë nuk kishte listuar asnjërën nga katërmbëdhjetë deri në orën 06:20 UTC të 17 shtatorit.

Dy nga katërmbëdhjetë mund të aktivizohen vetëm me një kërkesë, pa pasur nevojë që sulmuesi të drejtojë një server DNS të vetin, dhe të dyja prekin vetëm degët 9.20 dhe 9.21. Rrëzimi DoH është CVE-2026-77692. I dyti, CVE-2026-76163, lejon një kërkesë të tipit TKEY, një lloj regjistrimi që serverat e emrave përdorin për të negociuar çelësat mes tyre, të rrëzojë named kur skedari i konfigurimit të serverit, named.conf, nuk ka bllok global options.

Për shumicën e të tjerave, sulmuesi ka nevojë për një recursive resolver, llojin e serverit që kërkon emra në emër të klientëve, që të marrë të dhëna të ndërtuara me mjeshtëri nga një server që sulmuesi kontrollon. Një përgjigje e vetme e ndërtuar me mjeshtëri mund të rrëzojë një resolver që punon me konfigurim të parazgjedhur (CVE-2026-19667, një përgjigje negative prej saktësisht 65.536 bajtësh e dërguar nga një server i drejtuar nga sulmuesi), një resolver që përdor dns64 me break-dnssec yes (CVE-2026-19666, ku përgjigjja e keqformuar shërbehet nga cache), ose një validating resolver, një që kontrollon nënshkrimet kriptografike të bashkangjitura të dhënave DNS, që merr një përgjigje wildcard që mban njëkohësisht prova NSEC dhe NSEC3 në të njëjtin emër (CVE-2026-80274, e cila gjithashtu mund të prodhojë një SERVFAIL ose një regjistrim të gabuar mohimi). Një e katërta, CVE-2026-19662, kërkon një rend dhe kohë të caktuar përgjigjesh nga një zonë e nënshkruar e drejtuar nga sulmuesi dhe nuk prek 9.21.

Katër të tjera nga katërmbëdhjetë harxhojnë CPU-në ose memorien e një resolveri në vend që ta rrëzojnë atë. Dy prej tyre punojnë përmes regjistrimeve të ruajtura në cache SVCB ose alias HTTPS: me CVE-2026-81563 cache rritet përtej kufirit të saj derisa zgjidhja dështon, pasi një resolver ndjek në mënyrë të përsëritur një alias SVCB ose HTTPS me më shumë se trembëdhjetë regjistrime objektivi, dhe me CVE-2026-81736 një pemë aliasesh e ruajtur në cache mund të shterojë procesorin kur klientëve u lejohet rekursioni dhe sulmuesi drejton një zonë. CVE-2026-19668 shteron CPU-në e një validating resolver përmes një zone me shumë etiketa çelësash dhe pa përputhje të vlefshme, dhe ISC vëren se kufijtë e parazgjedhur të regjistrimeve e zvogëlojnë ekspozimin. CVE-2026-75029 e shtyn përdorimin e memories përtej kufijve të konfiguruar kur një përgjigje përsërit të njëjtin regjistrim SOA, CNAME ose DNAME shumë herë. ISC vlerëson shtatë nga katërmbëdhjetë si të Larta, të gjitha me 7.5 në CVSS 3.1, një shkallë standarde ashpërsie ku 10 është më e keqja: rrëzimet e përshkruara më sipër përveç CVE-2026-19662, plus dy dobësitë SVCB dhe HTTPS. Shtatë të tjerat janë Mesatare, nga 5.3 në 6.5.

Katër dobësitë e mbetura kanë të bëjnë me integritetin e të dhënave DNS, atë që një server shpërndan ose atë që një resolver pranon, në vend të rrëzimeve ose shterimit. ISC i vlerëson të katërtat Mesatare, dhe secila vjen me kushte për vendndodhjen e sulmuesit ose për atë që ai kontrollon tashmë.

Dy prej tyre lejojnë një validating resolver të pranojë provën e gabuar DNSSEC. Me CVE-2026-19941, një regjistrim NSEC i nënshkruar nga një zonë e palidhur mund të kalojë si provë se nuk ekziston një wildcard. Një sulmues i vendosur në rrugën e rrjetit, ose një përcjellës keqdashës, që kontrollon një zonë të nënshkruar, mund ta përdorë këtë për të bërë që një përgjigje NXDOMAIN e falsifikuar të pranohet për një emër që duhet të zgjidhej përmes një wildcard, dhe përgjigjja e falsifikuar do të kalonte validimin DNSSEC. Me CVE-2026-77119, një regjistrim NSEC3 i nënshkruar nga një zonë motër e palidhur mund të kalojë si provë se një delegim është i panënshkruar, dhe një sulmues i aftë të injektojë përgjigje ndaj kërkesave të resolverit mund të bëjë që një përgjigje e panënshkruar e falsifikuar të pranohet për emrat nën atë delegim. ISC i përshkruan të dyja rezultatet si cache poisoning, domethënë të dhëna të rreme që mbahen dhe ripërdoren nga një resolver.

CVE-2026-19033 ka të bëjë me një server sekondar, një që kopjon një zonë regjistrimesh DNS nga një server primar dhe pranon vetëm transferime të nënshkruara me një çelës TSIG, një sekret i përbashkët që përdoret për të vërtetuar transferime të tilla. Gjatë një transferimi inkremental me shumë mesazhe (IXFR) mbi TCP, named mund të fillonte të shërbente të dhënat e reja të zonës përpara se mesazhi i fundit që mbante nënshkrimin të mbërrinte, dhe nuk kthente gjendjen e mëparshme nëse ai nënshkrim nuk vinte kurrë. Një palë e aftë të dorëzojë një transferim të tillë mund të bënte që përmbajtja e paautorizuar e zonës të shërbehej pa pasur çelësin. Rregullimi kërkon një TSIG në çdo mesazh të një transferimi në hyrje, dhe ISC thotë se serverat modernë të emrave tashmë nënshkruajnë çdo mesazh, kështu që nuk pret ndryshim në praktikë.

CVE-2026-78301 kërkon më shumë akses se të tjerat: një sulmues që mund të bëjë që një zonë e keqformuar të ngarkohet në një server autoritativ, për shembull përmes një transferimi zone. Një zonë që përmban një nyje NS ose DNAME mbi origjinën e vet trajtohet si një prerje zone, kështu që kërkesat për emrat brenda zonës kthejnë një delegim jashtë zonës në vend të të dhënave të vetë zonës. Nëse serveri gjithashtu bën rekursion, ai mund të ndjekë atë delegim dhe të ruajë në cache regjistrime të furnizuara nga sulmuesi për emra jashtë zonës, dhe efekti zgjat sa kohë që zona e keqformuar mbetet e ngarkuar.

Secili nga katërmbëdhjetë njoftimet e ISC, të publikuara më 16 shtator, thotë se organizata nuk është në dijeni të ndonjë shfrytëzimi aktiv. Asnjëra nga katërmbëdhjetë nuk shfaqet në katalogun Known Exploited Vulnerabilities të CISA-s deri në versionin e katalogut të publikuar të njëjtën ditë. CISA është Agjencia e Sigurisë Kibernetike dhe Infrastrukturës e Shteteve të Bashkuara. Testet që riprodhojnë dobësitë janë publike, megjithatë. ISC tha në maj se tani publikon teste riprodhimi kur publikon një dobësi, dhe pema e burimit 9.20.29 shton teste sistemi për të paktën gjashtë nga katërmbëdhjetë, përfshirë një që dërgon një kërkesë SIG(0) të pavlefshme përmes DoH, mbyll lidhjen dhe kontrollon që named mbijeton. Këto janë teste që konfirmojnë rregullimin dhe jo mjete sulmi, por ato përcaktojnë qartë kushtet e aktivizimit.

Katërmbëdhjetë është numri më i madh i pesë publikimeve të sigurisë BIND nga ISC këtë vit, pas një dobësie në janar, katër në mars, gjashtë në maj dhe nëntë në korrik. ISC paralajmëroi në maj se "përdoruesit duhet të presin rregullime sigurie në çdo publikim mujor mirëmbajtjeje të BIND" për pjesën e mbetur të 2026-ës, një ndryshim që tha se u shkaktua nga një valë raportesh dobësish të gjeneruara nga modele të mëdha gjuhësore, si nga studiues ashtu edhe nga sulmues. Rregullimet vijnë në 9.20.29 dhe jo në 9.20.28 sepse ISC tërhoqi 9.20.28 përpara publikimit pasi testet para publikimit zbuluan një regresion.

Katër nga katërmbëdhjetë u gjetën në testet e vetë ISC. Të tjerat u raportuan nga Vitaly Simonovich (CVE-2026-77692), Rintaro Kawasugi (CVE-2026-19666 dhe CVE-2026-19667), Samy Medjahed, i njohur gjithashtu si Ap4sh (CVE-2026-19662 dhe CVE-2026-81563), Henrique Pereira (CVE-2026-78301 dhe CVE-2026-81736), Owais Lone, i njohur gjithashtu si thesecguy (CVE-2026-76163), një studiues i kredituar si hythyt (CVE-2026-80274), dhe Zuyao Xu dhe Xiang Li nga Universiteti Nankai (CVE-2026-19668).

Për pronarët e faqeve të web-it dhe ekipet IT, leximi praktik është i thjeshtë: ky është softuer nga ana e serverit, jo diçka që një vizitor ose një sistem menaxhimi përmbajtjeje e aktivizon nga jashtë. Nëse organizata juaj drejton serverat e vetë të emrave, përditësimi është e gjithë historia, sepse ISC nuk publikoi asnjë zgjidhje alternative. Nëse hostimi ose shërbimi juaj DNS menaxhohet për ju, pyetja që ia vlen të bëhet është nëse ai ofrues ka kaluar tashmë në 9.20.29 ose 9.21.26 dhe çfarë po bën për serverat që janë ende në degën 9.18 të pambështetur, të cilën ISC thotë se duhet supozuar e prekshme nga dobësi të reja. Një rrëzim i një resolveri nuk është vjedhje të dhënash në vetvete, por mund të nxjerrë jashtë linje një emër domeni për të gjithë ata që përpiqen ta arrijnë, dhe katër dobësitë e integritetit tregojnë se përgjigjet e gabuara të mbajtura në cache-n e një resolveri janë lloji i problemit që është shumë më i vështirë për t'u vënë re sesa një ndërprerje. Lexuesit që nuk duan të drejtojnë dhe rregullojnë vetë shtresën e tyre të zgjidhjes së emrave mund të shohin opsionet e menaxhuara: AEU DNS është një shërbim DNS privat dhe i sigurt, një mënyrë për t'ia dorëzuar një ofruesi drejtimin e kërkimeve në vend që ta mbani në serverat tuaj. Ajo që ka rëndësi në të dyja rastet është të dini kush është përgjegjës për rregullimin dhe të keni një përgjigje që mund ta kontrolloni.