SCTPhantom ve OVSwrap: 18 Yıllık Hayalet Modüller — NixOS ile Declarative Savunma
Bu hafta Linux dünyasında iki kritik zafiyet patladı. İkisi de yıllardır kernel’in derinliklerinde uyuyordu. İkisi de muhtemelen hiç kullanmadığımız modüllerde yaşıyor. Ve en kötüsü, modül hiç yüklenmemiş olsa bile auto-load mekanizmasıyla tetiklenebiliyorlar.
Biri 18, diğeri 13 yaşında. Ortak noktaları: Doğrudan root yetkisi veriyor olmaları.
SCTPhantom: 18 Yıllık Hayalet (CVE-2026-64564)
SCTP, telekomünikasyon dünyasından gelen ve TCP’ye alternatif olarak tasarlanan bir ağ protokolü. Kendi bilgisayarımda veya sunucumda aktif olarak kullanmıyorum. Ancak kernel modülü diskte bulunuyorsa, bir saldırgan auto-load ile modülü zorla yükletebilir.
Krizin Kaynağı
SCTP’nin Dynamic Address Reconfiguration mekanizmasında bir use-after-free açığı bulundu. Süreç şöyle işliyor:
- Saldırgan özel bir ASCONF chunk’ı gönderiyor.
- Kernel,
asconf->transportreferansını önbelleğe alıyor. - Peşinden belirli bir adres ve ardından wildcard içeren bir DEL-IP dizisi gönderiliyor.
- Kernel transport nesnesini serbest bırakıyor ama referans temizlenmiyor.
- Sonraki işlem bu dangling pointer’ı kullandığında use-after-free tetikleniyor.
Sonuç: Herhangi bir kullanıcı doğrudan root yetkisi kazanıyor. Hatta araştırmacılar bunun container ortamlarından kaçış için de kullanılabildiğini gösterdi.
Bu açık Linux kernel 2.6.25’ten beri kod tabanındaydı. Yani 2008’den 2026’ya kadar 18 yıl boyunca kimsenin ruhu duymadı.
Etki Alanı
SCTP modülünün diskte bulunduğu her Linux dağıtımı potansiyel hedef konumunda. Ana akım Linux kernel’inde (commit 9b2854f86f0b) giderilen bu zafiyet için yamalar 6.6.148, 6.12.101, 6.18.42, 7.1.6 ve 7.2-rc5 kernel sürümleriyle gelmeye başladı.
OVSwrap: 13 Yıllık Hafıza Bozulması (CVE-2026-64531)
Open vSwitch, genellikle veri merkezlerinde kullanılan bir sanal ağ altyapısı. Benim gibi standart ev kullanıcıları için pek bir esprisi yok. Ama modül diskte bekliyorsa risk maalesef devam ediyor.
Krizin Kaynağı
OVS kernel modülünde action attribute’ları işlenirken 16-bit nla_len alanı overflow’a uğruyor. Aşırı büyük iç içe geçmiş eylemler oluşturularak bu alanın taşması sağlanıyor. Kernel, manipüle edilmiş bu veriyi meşru komut gibi işleyip memory corruption’a yol açıyor; ardından arbitrary kernel read/write ile root yetkisi alınıyor.
Bu zafiyet 13 yıldır koddaki yerini koruyordu ancak toplam action stream boyutundaki 32 KiB sınırı nedeniyle sömürülemez durumdaydı. Mart 2025’te bu sınırın kaldırılmasıyla açık maalesef tetiklenebilir hale geldi.
Tetiklenme Koşulları
openvswitchkernel modülünün yüklenebilir durumda olması yeterli. Önceden yüklenmiş olması gerekmiyor.- Unprivileged user namespace’lerin açık olması şart. Modern Linux dağıtımlarında Docker, Podman veya tarayıcı sandbox’ları (Chromium gibi) kullandığımız için bu özellik genelde varsayılan olarak açık.
- Sistemde çalışan bir OVS bridge veya prosesi bulunması gerekmiyor.
Etki Alanı
Zafiyet 24 Temmuz 2026’da yamalandı. OVSwrap için yayınlanan güvenli kernel sürümleri şunlar: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 ve 7.1.5. Güncelleme yapana kadar modülün yüklenmesini engellemek şimdilik en iyi çözüm.
NixOS Sisteminde Durum Tespiti
“SCTP ve OVS kullanmıyorum, bana bir şey olmaz” diye düşünmüştüm ama durum pek öyle değilmiş. Modül dosyası diskteyse yüklenebilir; yüklenebiliyorsa zafiyet kapıda demektir.
Benim Sistemde Durum Neydi?
Kernel hardening yazısında sysctl parametrelerini, audit lock’u ve systemd isolation ayarlarını anlatmıştım. Soft hardening konseptinde de çok kasmayan, geliştirici dostu bir denge kurmuştuk.
Fakat dönüp bakınca fark ettim ki, benim sistemde kernel modül blacklisting hiç yokmuş. Yani kullanmadığım modüllerin auto-load olmasını engelleyen hiçbir şey yapmamışım.
Modülleri Kara Listeye Almak
NixOS’ta boot.blacklistedKernelModules seçeneği, kullanmadığım modülleri engellemek için biçilmiş kaftan. Klasik Linux’taki /etc/modprobe.d/ ayarlarının declarative, daha temiz hali diyebiliriz.
Hemen yeni bir güvenlik modülü ekledim:
# modules/core/module-blacklist.nix
lib.mkIf config.mySystem.security.hardened {
boot.blacklistedKernelModules = [
# CVE-2026-64564: SCTPhantom
"sctp"
"sctp_diag"
# CVE-2026-64531: OVSwrap
"openvswitch"
# Genel saldırı yüzeyi daraltma
"dccp"
"rds"
"tipc"
# Eski dosya sistemleri
"cramfs" "freevxfs" "hfs" "hfsplus" "jffs2" "udf"
# Eski donanım arayüzleri
"firewire-core" "firewire-net" "firewire-sbp2"
];
}
Bu modül mySystem.security.hardened = true flag’ini açınca sistemime otomatik olarak dahil oluyor.
Neden Sadece SCTP ve OVS Değil?
Listeye bakınca “neden sadece o iki modülü kapatıp geçmedin?” diyebilirsiniz. SCTP ve OVS sadece bugünün popüler açıkları. DCCP, RDS ve TIPC gibi protokoller geçmişte benzer zafiyetlerle çok baş ağrıttı. Eski dosya sistemleri de (cramfs, jffs2 vb.), USB üzerinden zararlı veri bağlandığında parser açıklarını tetiklemek için harika birer araç. Kullanmadığım ve işime yaramayan her modül benim için gereksiz bir risk. Bu yüzden listeyi olabildiğince geniş tutup sistemi temizledim.
Impermanence ve Runtime Koruması
NixOS’ta tmpfs root kullandığım için her boot’ta sistem sıfırlanıyor. “Modül yüklense bile yeniden başlatınca gider” demek güzel ama yeterli değil. Çünkü impermanence sistemi sadece yeniden başlarken temizler. Sistem çalışırken SCTP modülü üzerinden root yetkisi alan biri, o andan reboot’a kadar her şeyi yapabilir: kalıcı /persist dizinine yazabilir, SSH anahtarlarımı alabilir veya kernel’deki audit kurallarını çöpe atabilir.
Özetle, modül blacklisting sistemi açıkken koruyor, impermanence ise yeniden başlatırken temizliyor. İkisi birbirini tamamlıyor aslında.
Unprivileged User Namespace İkilemi
OVSwrap’ın çalışabilmesi için unprivileged user namespace’lerin açık olması şart. Sysctl üzerinden bunu kolayca kapatabilirdim:
boot.kernel.sysctl."kernel.unprivileged_userns_clone" = 0;
Ama bunu yaparsam Docker, Podman ve kullandığım Chromium sandbox’ı bozulur. Bütün geliştirme altyapımı kırmak yerine namespace’leri açık bırakıp, sorunu yaratan modülleri kara listeye almak çok daha mantıklı bir çözüm oldu.
Kernel Sürümleri ve Yamalar
Ben sistemimde linuxPackages_zen kullanıyorum. Zen kernel yamaları oldukça hızlı alıyor ama yine de terminalden güncel durumu kontrol etmekte fayda var:
uname -r
# Fix içeren sürümler: 6.6.148+, 6.12.101+, 6.18.42+, 7.1.6+
Kernel sürümüm güncel olsa bile blacklisting’i kaldırmayı düşünmüyorum. Yarın başka bir modülden yine benzer bir açık çıkabilir.
Kontrol Etmek İçin
Değişiklikleri uyguladıktan sonra modüllerin gerçekten engellendiğini şu komutlarla test ettim:
modprobe sctp 2>&1
# Beklenen Çıktı: modprobe: ERROR: could not insert 'sctp': Operation not permitted
modprobe openvswitch 2>&1
# Beklenen Çıktı: modprobe: ERROR: could not insert 'openvswitch': Operation not permitted
lsmod | grep -E "sctp|openvswitch"
# Çıktı boş olmalıdır.
Sonuç
Kısaca, kullanmadığım modülleri NixOS’ta declarative olarak blacklist’ledim. Hem SCTP hem OVS artık auto-load ile yüklenemiyor. Kodla yönetilen bir sistemin en güzel yanı da bu; bu ayarı bir kere yapıyorsunuz, konfigürasyonda yaşıyor ve başka bilgisayara geçseniz bile unutulmuyor.
İlgili Yazılar:
- NixOS Kernel Hardening ve Immutable Auditd
- NixOS Soft Hardening: Geliştirici Dostu
- Impermanence: Ephemeral Root ve /persist Mimarisi
- KVM Kaçışı: Januscape Zafiyeti ve NixOS Mitigasyonları
Kaynaklar ve Advisory Detayları:
- CVE-2026-64564 (SCTPhantom) — NIST NVD Advisory
- CVE-2026-64531 (OVSwrap) — NIST NVD Advisory
- Linux Kernel SCTP Fix (Commit 9b2854f86f0b) — git.kernel.org
- OVS nla_len Overflow Teknik Analizi — oss-security mailing list (Seclists)