Bir yetki yükseltme bulgusunu anlatırken benim için en net başlangıç, iki çıktıyı yan yana koymak: işlemi başlatan kullanıcı kim, çalıştırılan komut hangi kimlikle yürütülüyor? Bu testte ilk sorunun cevabı uid=1000(pardus), ikincisinin cevabı ise uid=0(root) oldu.
Bu yazıda, Pardus ETAP ortamında eta-register bileşeni üzerinden yürüttüğüm PoC’nin dört ekran görüntüsünü adım adım paylaşıyorum. Testin amacı etkileşimli bir root kabuğu açmak değildi. Kullanıcı tarafından hazırlanan bir servis dosyasındaki komutun root yetkisiyle çalıştığını, küçük bir çıktı dosyasıyla göstermek yeterli.
Kayıt özeti
CVE: CVE-2026-92886 · Bildirim: TR-26-1440
Sınıf: CWE-862 / Eksik yetkilendirme
CVSS v3.1: 7.8 (Yüksek)
Etkilenen sürüm aralığı: 2.0.8 ≤ sürüm < 2.0.9 [1, 2, 3]
root olmayan oturum
Önce oturumun kimliğini kontrol ettim. whoami çıktısı pardus; id çıktısı ise kullanıcı ve birincil grup kimliğinin 1000 olduğunu gösteriyor.
Burada atlanmaması gereken ayrıntı, hesabın sudo grubunda olması. Oturum root değil; fakat bu kanıt tek başına, aynı sonucun sudo grubunda bulunmayan her kullanıcıda alınacağını göstermiyor. Yazıdaki değerlendirmeyi bu test koşuluyla sınırlı tutuyoruz.
Küçük ve ölçülebilir bir PoC
Bir sonraki adımda ev dizinimde etap-poc.service adlı bir systemd servis dosyası hazırladık. Dosyadaki komut iki iş yapıyor: çalıştığı kimliği /tmp/etap_root_poc dosyasına yazıyor ve hemen altına teste özgü bir işaret ekliyor. Böylece yalnızca bir dosyanın oluşmasına değil, içeriğine de bakabiliyoruz.
cat > ~/etap-poc.service <<'EOF' [Service] Type=oneshot ExecStart=/bin/sh -c 'id > /tmp/etap_root_poc; echo MARKER_ETAP_LPE >> /tmp/etap_root_poc' [Install] WantedBy=multi-user.target EOF
Type=oneshot, kısa bir iş çalıştırıp sonlanan servis tipini seçiyor. Asıl test yükü ExecStart satırında: kabuk, id çıktısını dosyaya yönlendiriyor; ardından MARKER_ETAP_LPE satırını ekliyor. İşaret satırı, sonradan okunan çıktının bu PoC ile ilişkisini görünür kılıyor. Servis dosyasında bir User= tanımı yok. Sistem düzeyindeki bir systemd servisi için bu durum, başka bir kısıtlama yoksa varsayılan root bağlamını önemli hâle getiriyor. Ancak burada vardığım sonuç yalnızca bu varsayıma dayanmıyor; son adımda doğrudan komutun kimlik çıktısını kontrol ediyoruz. Dosyadaki WantedBy=multi-user.target satırı da tek başına servisin açılışta etkinleştirildiğini kanıtlamaz. Görsellerde bir enable işlemi ya da yeniden başlatma testi bulunmuyor.
eta-register çağrısı
Hazırladığımız servis dosyasını, eta-register içindeki opr.py yardımcı programının start-service işlemi için argüman olarak verdik. Ekran görüntüsündeki çağrı şöyle:
eta-register/src/opr.py start-service \ /home/pardus/etap-poc.service
Bu adımın kritik noktası, dosyanın kullanıcı tarafından hazırlanmış olması. Ayrıcalıklı bir yardımcı programın, bu dosyada tanımlanan komutu hangi yetkilendirme koşullarıyla çalıştırabildiği güvenlik sınırını belirliyor. Komutun sessizce dönmesi tek başına başarı kanıtı değil; bu yüzden hemen çıktı dosyasına baktık. Görüntüde bir parola istemi görünmüyor. Yine de yalnızca bu kareden, önceki kimlik doğrulama durumu veya etkin Polkit kurallarının tamamı hakkında kesin sonuç çıkarmak mümkün değil. Bunu “her kullanıcı için koşulsuz, parolasız root” diye genellemek doğru olmaz.
komut root olarak çalıştı
cat /tmp/etap_root_poc ls -la /tmp/etap_root_poc
Dosyanın ilk satırı uid=0(root) gid=0(root) gruplar=0(root). İkinci satırda ise eklediğim işaret var. Dosyanın sahipliği de root:root olarak görünüyor. Bu üç bulgu birlikte, servis içindeki komutun root bağlamında yürütüldüğünü destekliyor. Buradaki sonuç bir root kabuğu ekran görüntüsü değil; root yetkisiyle komut çalıştırma kanıtı. PoC için seçtiğim komut yalnızca kimlik bilgisini ve işaret satırını yazıyor.
Sorun nerede?
CVE kaydı bulguyu eksik yetkilendirme olarak sınıflandırıyor; başlıkta Polkit yapılandırmasına işaret ediliyor. [2, 3] Ekran görüntülerinde görülen akış ise somut: kullanıcı bir servis dosyası hazırlıyor, bu dosyanın yolunu ayrıcalıklı yardımcıya veriyor ve dosyadaki komut root olarak çalışıyor. Güvenlik açısından mesele yalnızca pkexec kullanılması değil. Ayrıcalıklı giriş noktasına kimin erişebildiği ve bu noktadan hangi işlemlerin, hangi kullanıcı girdileriyle yürütülebildiği birlikte değerlendirilmek zorunda. Kullanıcının denetimindeki servis içeriği root bağlamına taşındığında, dosyanın ExecStart satırı da bu yetkiyle çalışabilir. Bu dört görsel Polkit kuralının içeriğini, yardımcı programın kaynak kodunu veya düzeltme farkını içermiyor. Dolayısıyla hatayı belirli bir kural satırına bağlamıyorum. Kanıtlanan davranış ile kayıttaki sınıflandırma arasındaki ayrımı korumak, bulguyu olduğundan büyük göstermemek kadar önemli.
Etki ve kapsam
Test, yerel bir oturumdan root yetkisiyle komut yürütülebildiğini gösteriyor. Böyle bir yetki sınırı aşımı, sistem dosyalarının ve hizmetlerinin bütünlüğünü, gizliliğini ve kullanılabilirliğini etkileyebilir. PoC’de ise veri okuma, veri sızdırma ya da hizmet kesintisi denenmedi. Uzaktan sömürülebilirlik de bu kanıtların kapsamında değil. Ekran görüntülerinde kurulu paket sürümü yer almadığı için test makinesinin kesin eta-register sürümünü bu görsellerden çıkarmıyorum. Etkilenen sürüm aralığı, CVE kayıt bilgisinden geliyor. Aynı şekilde dosya listesindeki tarih bilgisini keşif veya bildirim tarihi olarak kullanmıyorum.
Düzeltme
Yayımlanan kayıt ve duyuruya göre eta-register bileşeninin 2.0.9 veya daha yeni bir sürüme yükseltilmesi gerekiyor. [1, 3] Sürüm güncellemesinden sonra, aynı kullanıcı ve yetkilendirme koşullarıyla kontrol edilerek kullanıcı denetimindeki servis dosyasının yetkisiz biçimde çalıştırılamadığı doğrulanmalı. Bu belgede yamalı sürüm üzerinde yapılmış bir tekrar testinin sonucu yer almıyor. Bu bulgudan çıkardığım temel ders şu: güvenilen bir yardımcı programın varlığı, ona verilen girdiyi de güvenilir yapmıyor. Yetki kontrolü ile kullanıcı denetimindeki servis içeriği arasındaki sınır, bu PoC’nin merkezinde.
Kaynaklar ve kanıt notu
[1] Siber Güvenlik Başkanlığı, TR-26-1440
siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-1440
[2] CVE Programı, CVE-2026-92886
cve.org/CVERecord?id=CVE-2026-92886
[3] CVE kaydının indekslenen kopyası, Vulnerability-Lookup
Vulnerability-Lookup / eta-register kayıtları