CVE-2025-32463: Kullanıcı Kontrollü Chroot Dizininden Root Olarak Kod Yükleme

60 saniyede CVE-2025-32463

sudo, bir komutu root yetkileriyle çalıştırmadan önce normal şartlarda güvenlik politikasını (sudoers) denetler. CVE-2025-32463 zafiyeti, yerel (local) bir kullanıcının; ayrıcalıklı dosya yolu, kimlik ve yetki denetimi süreçleri henüz devam ederken sudo’nun kullanıcı tarafından belirlenen bir kök dizine (chroot) girmesini sağlamasına yol açtı. /etc/nsswitch.conf kullanan Linux sistemlerinde bu yeni root dizini, saldırgan kontrollü bir ad servisi (Name Service Switch - NSS) yapılandırması barındırabilir ve bu da sudo’nun saldırgan kontrollü bir paylaşımlı kütüphaneyi (.so) root yetkileriyle yüklemesine neden olur.

Saldırı yolu (attack path) şu şekilde gerçekleşmektedir:

sudo erişimine sahip yerel kullanıcı
  -> sudo -R / --chroot parametresiyle saldırgan kontrollü bir dizin seçer
  -> sudo, sudoers değerlendirmesi tamamlanmadan önce bu dosya sistemine girer
  -> Ayrıcalıklı NSS sorgusu saldırganın /etc/nsswitch.conf dosyasını okur
  -> libc seçilen name-service modülünü (.so) yükler
  -> Komut yetkilendirmesi güvenlik sınırını koruyamadan önce saldırgan kodu root olarak çalışır

Bu mekanizma, zafiyetin şaşırtıcı etkisini açıklar: Talep edilen komutun sudoers dosyasında izinli olması gerekmiyordu. Tehlikeli kod yükleme adımı, sudo henüz isteğin yetkilendirilip yetkilendirilmeyeceğine karar verme aşamasındayken tetikleniyordu.

chroot, NSS ve sudo -R nedir?

chroot(), bir sürecin gördüğü dosya sistemi kökünü (/) değiştirir. İzole bir çalışma ortamı belirlemek için yararlıdır; ancak güvenilmeyen bir kullanıcı bu dizini kontrol ettiğinde ve ayrıcalıklı bir süreç dizin içindeki dosyaları yorumlamaya devam ettiğinde tek başına bir güvenlik sınırı (security boundary) oluşturmaz.

NSS (Name Service Switch), libc kütüphanesine kullanıcıların, grupların, host adlarının ve diğer isimlerin nereden çözümleneceğini bildirir. /etc/nsswitch.conf dosyası sağlayıcıları belirler ve bu sağlayıcıların bazıları paylaşımlı kütüphaneler (shared libraries) olarak uygulanmıştır.

sudo -R, güvenlik politikası izin verdiğinde kullanıcı tanımlı bir root dizini özelliği sunuyordu. Zafiyet; seçilen kök dizinin, politika kararı güvenli bir şekilde tamamlanmadan önce ayrıcalıklı NSS davranışını etkileyecek kadar erken aktif hale gelmesinden kaynaklandı.

Ne oldu?

Sudo 1.9.14 sürümü, kullanıcı tarafından belirtilen root dizinine sudoers dosyası henüz değerlendirilirken chroot() ile girilebilecek şekilde dosya yolu işleme mantığını değiştirdi. Yerel bir kullanıcı, bu root dizininin altında özel bir /etc/nsswitch.conf hazırlayabilir ve sonraki ad servisi sorgusunu rastgele bir paylaşımlı kütüphaneye yönlendirebilirdi. Sorgu ayrıcalıklı sudo süreci içerisinde gerçekleştiği için kütüphane doğrudan root yetkileriyle belleğe yüklendi.

Sudo 1.9.17p1 sürümü, bu erken-root tasarımını geri aldı (revert), dosya yolu çözümlemesi sırasında seçilen root dizinini önek (prefix) olarak ekleme mantığına geri döndü ve chroot özelliğini kullanımdan kaldırdı (deprecated). Bu düzeltme işlem sırasını olması gereken hale getirdi: Güvenilmeyen bir dosya sistemi, yetkilendirme tamamlanmadan önce ayrıcalıklı yorumlama sürecinin bir parçası olamaz.

Kimler etkilendi?

Üretici açıklaması sudo 1.9.14 ile 1.9.17 arasındaki tüm sürümleri etkilenen kapsam olarak belirtmektedir. İstismar için etkilenen sudo yolunu çalıştırabilen yerel bir kullanıcı, /etc/nsswitch.conf destekleyen bir sistem ve savunmasız bir derleme gerekiyordu. İstenen komutun sudoers dosyasında bulunması gerekmiyordu; çünkü kütüphane yüklemesi henüz yetkilendirme değerlendirmesi yapılırken gerçekleşiyordu.

Sudo 1.9.17p1 hatayı düzeltmektedir. Linux dağıtım paketleri bu düzeltmeyi geriye dönük yamalarla (backport) uygulayabileceğinden, savunmacılar yalnızca upstream sürüm dizesine bakmak yerine kurulu paket için dağıtım güvenlik bültenini ve changelog kaydını kontrol etmelidir.

Doğruladığım hususlar

• Yama, erken pivot_root mantığını geri almakta ve komut yollarını çözümlerken seçilen kökü önek olarak ekleme yaklaşımına dönmektedir.
• Bu geri alma işleminden önce runchroot, ayrıcalıklı kimlik ve politika işlemleri devam ederken sudo_goodpath() ve find_path() gibi kontrollerden geçmekteydi.
• Upstream yama; passwd ve group sorgularının root değiştirildikten sonra güvenli bir şekilde yapılamayacağını ve özel hazırlanmış nsswitch.conf üzerinden kütüphane yüklenmesini CVE-2025-32463’ün doğrudan sonucu olarak belirtmektedir.
• Bu kod değişikliklerini proje güvenlik bülteni ve kamuya açık ifşa zaman çizelgesiyle karşılaştırdım.
• Bu çalışma, tehlikeli işlem sırasının ve düzeltmesinin statik analizle yeniden üretimidir (static reproduction).

Derinlemesine teknik analiz: Hata zararlı bir dosyadan değil, işlem sırasından kaynaklanıyor

Zafiyeti “zararlı bir nsswitch.conf dosyası” olarak tanımlamak yanıltıcı bir basitleştirmedir. Bu sadece zincirdeki son görünür girdidir. Kendi kök dosya sisteminden yapılandırma okuyan normal bir program doğası gereği savunmasız değildir. Tehlikeli sekans şudur:

1. Ayrıcalıklı bir program, yetkisiz bir çağrıcı tarafından seçilen bir kök dizini kabul eder;
2. Politika ve kimlik çözümleme işlemleri sürerken bu dizin süreç için aktif kök haline gelir;
3. libc ad servisi çözümlemesi yeni kök altındaki yapılandırmaya başvurur;
4. Bu yapılandırma ayrıcalıklı süreç içinde modül yüklenmesini yönlendirir;
5. Saldırgan kontrollü kod, yetkilendirme mekanizması koruyucu bir sınır oluşturamadan önce root olarak çalışır.

Kök neden bu nedenle “NSS güvensizdir” demek değildir. NSS tasarlandığı görevi yerine getirmektedir: geçerli root ile ilişkili yapılandırmayı okumak ve seçilen servis modüllerini yüklemek. Temel hata; ayrıcalıklı bir süreç bu davranışları tetikleme potansiyeline sahipken, o root dizininin kontrolünü yetkisiz bir kullanıcıya vermektir.

1.9.14 regresyonu dosya yollarının çözümlenme zamanını değiştirdi

Koordineli oss-security açıklaması, etkilenen aralığın sudo 1.9.14 ile başladığını doğrulamaktadır. Bu sürüm; sudoers dosyası değerlendirilirken kullanıcı tanımlı root dizini kullanılarak dosya yollarının chroot() üzerinden çözümlenebilmesini sağlayan bir değişiklik yaptı.

Bu sıra hayati bir regresyondur. Kullanıcı tarafından seçilen bir chroot, ilk bakışta bir çalıştırma özelliği gibi görünebilir: “komutu bu dosya sistemi içinde çalıştır.” Savunmasız uygulamada bu durum aynı zamanda bir yorumlama özelliğine dönüştü: “kimliklere, yollara ve politikalara karar verirken bu dosya sistemini kullan.” Bu iki kavram asla eşdeğer yetkiler değildir.

Bu durum, yalnızca sudoers kural incelemesi yapmanın riski neden ekarte edemeyeceğini gösterir. Kamuya açık bültende belirtildiği gibi, rastgele komutlar sudoers dosyasında listelenmemiş olsalar dahi çalıştırılabilmekteydi. Bu bypass, izin verilen bir komutla akıllıca eşleşme meselesi değildir; sistem yöneticilerinin denetlediği soyutlama katmanının çok altında gerçekleşir.

NSS: Yapılandırmadan koda uzanan köprü

Name Service Switch, libc’nin kullanıcıları, grupları ve host’ları yapılandırılmış kaynaklar üzerinden çözümlemesini sağlar. Bu kaynakları /etc/nsswitch.conf belirler ve bazı seçimler sürecin doğrudan dinamik paylaşımlı nesneleri (.so) yüklemesine karşılık gelir.

Savunmasız sudo süreci yalnızca saldırgan kontrollü bir metni okumakla kalmadı; uygulaması bu metin tarafından seçilebilen ayrıcalıklı bir arama gerçekleştirdi. Bu durum genel bir güvenlik araştırması prensibini hatırlatır:

Ayrıcalıklı kod saldırgan kontrollü bir ad alanına (namespace) girdiğinde; yalnızca yamada adı geçen dosyayı değil, her örtük yorumlayıcıyı, yükleyiciyi, çözümleyiciyi ve yapılandırma arama yolunu envantere alın.

Aynı mantık locale katalogları, dynamic linker yapılandırması, PAM yığınları, plugin keşif mekanizmaları, sertifika depoları ve dil çalışma zamanları (runtimes) için de geçerlidir. Chroot dosya yolu görünürlüğünü değiştirir; ancak görünen dosyaları otomatik olarak güvenilir kılmaz.

Düzeltme neleri değiştirdi?

Sudo 1.9.17p1, 1.9.14 değişikliğini tamamen geri aldı ve chroot özelliğini kullanımdan kaldırıldı (deprecated) olarak işaretledi. Bu çözüm şüpheli bir NSS belirtecini filtrelemekten çok daha köklüdür: kullanıcı kontrollü dosya sistemi durumunun yetki değerlendirmesine dahil olmasını sağlayan ön koşulu ortadan kaldırır.

Özelliğin kullanımdan kaldırılması (deprecation) stratejik bir karardır. Geliştiriciler, kullanıcı kontrollü chroot desteğini “hataya açık ve nadiren kullanılan bir özellik” olarak nitelendirdi. Bu mimari bir derstir: Bir özellik ayrıcalıklı yorumlamayı sürekli olarak güvenilmeyen bir ad alanına zorluyorsa, özelliği kısıtlamak veya tamamen kaldırmak, etrafına yamalar eklemekten çok daha güvenlidir.

Evidence matrix

Exploit geliştirmeden güvenli doğrulama

Bir maruz kalma denetimi üç ayrı soruyu yanıtlamalıdır:

İlk olarak, kurulu paket sürümünü ve dağıtımın güvenlik bültenini kaydedin. Dağıtıcılar düzeltmeleri geriye dönük yamaladığında 1.9.17p1’den eski bir sürüm dizesi kesin kanıt değildir; dağıtım bülteni ve changelog doğru referans noktalarıdır.

İkinci olarak, kurulu sudo derlemesinin chroot seçeneğini sunup sunmadığını ve yerel politikanın bu çağrıya izin verip vermediğini denetleyin. Bu, zararlı bir kütüphane yüklemeyi denemeden erişilebilirliği ortaya koyar.

Üçüncü olarak, savunmasız ve düzeltilmiş derlemeleri gözlem altında karşılaştırın. Güvenli bir test ortamı, zararsız bir dizin ağacı kullanarak dosya sistemi erişimini izleyebilir (strace). Buradaki doğrulama yapısal olmalıdır: Düzeltilmiş derleme, ayrıcalıklı politika kararını verirken kullanıcı tarafından seçilen root altındaki ad servisi yapılandırmasına başvurmamalıdır. Tehlikeli sorgunun kaybolduğunu doğrulamak için özel bir root kabuğu (shell) açmaya gerek yoktur.

Sonuç

Sudo sürümünüzü 1.9.17p1’e veya bu düzeltmeyi geriye dönük olarak içeren dağıtım paketine yükseltin. Güncelleme tamamlanana kadar yerel hesap maruziyetini azaltın ve kullanıcı tanımlı root dizinlerine izin veren gereksiz politika yollarını kaldırın. Tespit mekanizmaları; sudo’nun chroot seçeneğinin beklenmedik kullanımına, yerel kullanıcılar tarafından hazırlanan şüpheli dizin ağaçlarına ve sistem dışı konumlardan ad servisi modülleri yükleyen ayrıcalıklı süreçlere odaklanmalıdır.

Vardığım teknik sonuç şudur: Hazırlanan zararlı dosya zincirin yalnızca son halkasıydı; asıl zafiyet, ayrıcalıklı çözümleme tamamlanmadan önce kullanıcı kontrollü bir dosya sistemi görünümüne girilmesiydi. Bu işlem sırası tersine çevrildiğinde, NSS artık yetkilendirme yolunda saldırgan tarafından belirlenen yapılandırmayı alamaz.

@misc{jankesec_sudo_chroot_nss_cve_2025_32463_2026,
  author       = {Sevban D\"{o}nmez},
  title        = {CVE-2025-32463: Kullanıcı Kontrollü Chroot Dizininden Root Olarak Kod Yükleme},
  year         = {2026},
  howpublished = {\url{https://jankesec.com/tr/arastirma/sudo-chroot-nss-cve-2025-32463/}},
  note         = {jankesec technical security research (CVE-2025-32463)}
}

[CVE-2025-32463: Kullanıcı Kontrollü Chroot Dizininden Root Olarak Kod Yükleme](https://jankesec.com/tr/arastirma/sudo-chroot-nss-cve-2025-32463/) — Sevban Dönmez (2026) [CVE-2025-32463]