Dobësia e certificate në LXD mundëson imitimin e një klienti të besuar
Një dobësi kritike e certificate në LXD i lejon një sulmuesi të imitojë një klient të besuar pa zotëruar private key të atij klienti, pra sekretin që përdoret për të vërtetuar identitetin e tij. Problemi prek produktet LXD dhe MicroCloud të Canonical dhe mund të ekspozojë një cluster dhe virtual machines të tij, të cilat janë kompjuterë të bazuar në software që funksionojnë brenda një host fizik. Canonical paralajmëroi se imitimi i një llogarie me privilegje mund t’i japë sulmuesit root access, që nënkupton kontroll të plotë administrativ mbi host.
Cenueshmëria gjurmohet si CVE-2026-112816 dhe ka rezultatin maksimal CVSS prej 10.0. CVSS, ose Common Vulnerability Scoring System, është një shkallë standarde për vlerësimin e rëndësisë së dobësive të sigurisë. Canonical ka publikuar versione të korrigjuara të LXD dhe MicroCloud, megjithëse administratorët duhet të verifikojnë se versioni i instaluar e ka marrë vërtet përditësimin.
LXD dhe MicroCloud u lejojnë klientëve në distancë të lidhen përmes një HTTPS API, një ndërfaqe rrjeti e enkriptuar që software përdor për të shkëmbyer udhëzime dhe të dhëna. Autentikimi kryhet përmes mutual TLS, një lidhje ku si serveri, ashtu edhe klienti që lidhet, përdorin digital certificates për të përcaktuar identitetet e tyre. Një server e konsideron një klient të besuar kur certificate i atij klienti gjendet në trust store, pra në listën e identiteteve që serveri është konfiguruar të pranojë.
Dobësia lidhej me mënyrën se si serveri shqyrtonte certificate chain të dërguar gjatë një lidhjeje. Serveri krahasonte çdo certificate të paraqitur nga klienti me hyrjet në trust store. Megjithatë, lidhja TLS vërteton vetëm se klienti që po lidhet zotëron private key që i përket certificate të parë në atë chain, i njohur si leaf certificate. Çdo certificate shtesë i bashkëngjitur pas tij zgjidhet nga klienti që po lidhet dhe nuk mbulohet nga kjo provë pronësie.
Prandaj, një sulmues mund të lidhej duke përdorur një certificate dhe private key nën kontrollin e tij dhe më pas të shtonte public certificate të një klienti të ligjshëm e të besuar. Public certificates nuk janë sekrete. Për shkak se serveri i cenueshëm kontrollonte të gjitha certificates në chain e paraqitur, ai mund të gjente certificate e besuar dhe ta pranonte sulmuesin si atë klient, edhe pse sulmuesi nuk zotëronte private key të klientit të besuar.
Shfrytëzimi kërkon dy kushte. Sulmuesi duhet të jetë në gjendje të arrijë HTTPS API të objektivit përmes rrjetit dhe duhet të ketë public certificate të një klienti që serveri tashmë e konsideron të besuar. Një instalim i pavarur i LXD nuk e ekspozon API e tij në rrjet si parazgjedhje. Ai dëgjon vetëm përmes një socket lokal, një lidhje e disponueshme në të njëjtën makinë, përveçse kur një administrator aktivizon qasjen në rrjet me parametrin core.https_address.
MicroCloud ka një ekspozim shtesë sepse bashkon disa makina LXD në një cluster. Canonical tha se një sulmues që kap public certificate të një anëtari ndërsa ajo makinë po bashkohet me cluster mund të autentikohet më vonë si ai anëtar. Imitimi i suksesshëm do t’i jepte sulmuesit të gjitha lejet për cluster dhe virtual machines që i ishin caktuar atij identiteti.
Regjistrimi i CVE identifikon LXD 4.0.14, 5.0.10, 5.21.8 dhe 6.9 si të prekur përpara release përkatëse të korrigjuara. Canonical rendit si të korrigjuara LXD 6.10.1 në snap channel 6/stable, 5.21.9 në 5.21/stable, 5.0.11 në 5.0/stable dhe 4.0.15 në 4.0/stable. Për MicroCloud, versionet e korrigjuara janë 3.4.1 në 3/stable dhe 2.1.5 në 2/stable. Një snap është formati i paketuar i aplikacionit përmes të cilit shpërndahen këto release.
Projekti Incus, i cili filloi si një community fork i LXD, raportoi fillimisht problemin themelor. Canonical më pas konfirmoi se edhe LXD ishte i cenueshëm. Incus korrigjoi të njëjtën dobësi në versionin 7.6.0, së bashku me 17 probleme të tjera sigurie. Paketat e arkivit të Ubuntu për LXD renditen ose si të paprekura, ose si të pashpërndara, kështu që release përkatëse të korrigjuara të LXD janë paketat snap.
Nuk ka tregues publikë se CVE-2026-112816 është shfrytëzuar. Një vlerësim i U.S. Cybersecurity and Infrastructure Security Agency, i datës 30 tetor, thotë se dobësia nuk dihet të jetë përdorur në sulme. Ajo nuk përfshihet në listën Known Exploited Vulnerabilities të agjencisë dhe nuk është publikuar asnjë exploit publik funksional.
Administratorët duhet t’i përditësojnë instalimet snap duke ekzekutuar sudo snap refresh lxd dhe sudo snap refresh microcloud. Në kohën e njoftimit të Canonical, point releases e korrigjuara të LXD po kalonin ende nga candidate channel në stable. Prandaj, administratorët duhet të kontrollojnë versionin e instaluar pas rifreskimit, në vend që të supozojnë se release e korrigjuar është dorëzuar.
Canonical nuk ofroi asnjë zgjidhje të përkohshme për LXD. Kufizimi i personave dhe sistemeve që mund të arrijnë HTTPS API mund ta zvogëlojë ekspozimin ndërsa pritet përditësimi, por nuk e korrigjon gabimin në validimin e certificate. Edhe projekti Incus tha se nuk kishte një zgjidhje të bazuar në konfigurim dhe këshilloi kufizimin e qasjes në rrjet te listener derisa sistemet të mund të përditësoheshin. Përdoruesit e Incus duhet të instalojnë versionin 7.6.0.
Organizatat që kanë nevojë për mbështetje për sigurimin e mjedisit përreth të IT mund të përdorin AEU-I për IT, infrastrukturë dhe konsulencë me sigurinë si përparësi. Për instalimet e prekura, përparësia mbetet instalimi i release së korrigjuar, konfirmimi i versionit të saj dhe mbajtja e management API të paarritshme nga rrjetet e pabesuara.