LXD ve MicroCloud, herkesçe bilinen sertifikaların güvenilir istemcileri taklit edebilmesini sağlayan açığı yamaladı

Canonical, 29 Ekim 2026'da her iki ürünün istemci kimlik modelini baltalayan bir açık için LXD ve MicroCloud'un yamalanmış sürümlerini yayınladı. CVE-2026-112816 olarak takip edilen ve CVSS puanı 10.0 olan bu güvenlik açığı, güvenilir bir public certificate'e sahip olan herkesin, private key gerekmeksizin dilediği bir istemci olarak kimlik doğrulaması yapmasına imkân tanıyordu. Canonical'ın duyurusunu özetleyen dev.to'daki teknik yazıya göre hatalı mantık ilk sürümden beri mevcuttu.

Ne yanlış gitti

LXD, bir Linux ana makinesinde system container'ları ve sanal makineleri yönetir ve ağ üzerinde暴露 edilen bir HTTPS API üzerinden kontrol edilir; MicroCloud ise böyle birkaç ana makineyi bir küme (cluster) halinde birleştirir. Bu API'nin kimlik modeli tamamen mutual TLS üzerine kuruludur: el sıkışma (handshake) sırasında istemci, sunduğu zincirdeki ilk sertifikaya karşılık gelen private key'in sahibi olduğunu kanıtlar ve daemon, sunulan malzemeyi trust store'u ile karşılaştırır.

Hata bu düzenin ikinci yarısındaydı. dev.to'daki yazının açıkladığı gibi, LXD'nin HTTPS dinleyicisi istemci sertifikalarını istiyordu ama zinciri doğrulamıyordu; sahiplik denetimi ise zincirdeki, istemcinin kendi seçtiği ara sertifikalar dahil her sertifikayı trust store ile karşılaştırıyordu. Handshake yalnızca ilk sertifikanın anahtarını kanıtladığı için, bir istemci kendi zincirine herhangi bir public certificate ekleyerek o kimlik olarak kabul edilebiliyordu.

Duyuru, rapor eden kişi olarak stgraber'e atıfta bulunuyor; sorun Incus aracılığıyla — projenin fork'u, defekti keşfeden ve LXD'de de bulunduğunu doğrulayan — LXD'ye ulaştı.

Sertifika nereden geliyor

Saldırganın önceden herhangi bir erişime ihtiyacı yok. Sunucu sertifikaları her TLS handshake'de paylaşılır; istemci sertifikaları ise herhangi bir güvenilir istemci tarafından certificates API üzerinden okunabilir ya da o istemcinin bağlandığı herhangi bir sunucudan toplanabilir. Saldırgan bu public certificate'lerden birini kendi zincirinde ara sertifika olarak ekler ve sahibi olarak kimlik doğrular. Sunucunun kendi sertifikasını eklemek veritabanı geçidini (database gateway) açar; kümede ise başka bir üyenin sertifikasını eklemek, yetkilendirme denetimlerini atlayan iç küme erişimi sağlar.

Taklit edilen kimlik neye erişebilir

Zayıf sahiplik denetimi birkaç farklı yüzeyi koruyordu. Ana API küme ve instance kontrolü verir, metrics uç noktası telemetriyi açığa çıkarır, küme ve veritabanı geçitleri de aynı karşılaştırmanın arkasındadır. Sertifika yenileme ve kendini silme işlemleri self-service yollarından geçer; yani saldırgan, başkası adına trust store kayıtlarını yenileyebilir veya silebilir. Token tabanlı kayıt (enrolment) ile bir ana makine ve sanal makineleri arasındaki bağlantı da buna dayanır. dev.to'nun aktardığı Canonical'ın özetine göre, taklit edilen kullanıcının ayrıcalığına bağlı olarak saldırgan ana makinede root erişimi kazanabilir.

Küme katılımı sırasında MicroCloud

MicroCloud, yeni bir üye kümeye katılırken aynı hatayı tekrarlar. Duyuruya göre, katılan bir üyenin public TLS sertifikasını yakalayan bir saldırgan, o üye olarak kimlik doğrulaması yapabilir; bu kimlik, yapılandırmayı küme genelinde çoğalttığı, storage kimlik bilgilerini taşıdığı ve control plane'in parçası olduğu için tasarım gereği ayrıcalıklıdır.

Düzeltme ve operatörlerin yapması gerekenler

Yamalanmış kod yalnızca leaf certificate'i — handshake'in fiilen kanıtladığı tek anahtara sahip sertifikayı — karşılaştırır ve önceki davranışı geri getiren bir yapılandırma seçeneği yoktur. Canonical 29 Ekim 2026'da düzeltilmiş snap kanallarını yayınladı: LXD 6.10.1, 5.21.9, 5.0.11 ve 4.0.15 ile MicroCloud 3.4.1 ve 2.1.5. Şirket, nokta sürümlerinin hâlâ candidate'dan stable'a doğru yuvarlandığını belirtti; bu yüzden operatörler yalnızca kanal adına güvenmek yerine çalışan sürümü doğrulamalıdır. Sunulan tek geçici çözüm HTTPS dinleyicisine ağ erişimini kısıtlamaktır; Canonical, yapılandırmaya dayalı bir geçici çözüm olmadığını açıkça belirtir.

Neden önemli

Bir container ana makinesi veya hypervisor API'si, self-hosted bir ortamın en hassas servislerinden biridir: makineler oluşturur, storage bağlar, workload'ları taşır ve snapshot'lar aracılığıyla belleklerini okuyabilir. Kimlik doğrulaması yalnızca protokolün fiilen teslim ettiği kanıtlara dayanmalıdır ve bu açık, bir güven denetiminin çağrıyı yapan tarafın sağladığı değerlere uygulanmasıyla ne olacağını gösteriyor. LXD'nin ötesinde dikkat edilmesi gereken iki nokta var. Birincisi, defekt ilk sürümle birlikte yayınlandı; dolayısıyla denetimler yalnızca yakın geçmiş log'lara değil, yıllara yayılan trust store kayıtlarına ve geçmiş erişim kayıtlarına kadar uzanmalıdır. İkincisi, istemci kontrollü zincir verisini güvenilir bir listeyle karşılaştırma kalıbı, mutual TLS uygulayan diğer servislerin de tekrarlayabileceği bir tasarım hatasıdır ve bunun upstream'de ortaya çıkması Incus fork'undaki bir incelemeyi gerektirdi.