Konuyu Okuyanlar:

OpenBSD Çekirdeğinde 37 Yıllık shmat Açığı: KARL, SMAP ve SMEP Aşılarak Root Alındı

OpenBSD Çekirdeğinde 37 Yıllık shmat Açığı: KARL, SMAP ve SMEP Aşılarak Root Alındı
[Resim: attachment.php?aid=228]

Selam arkadaşlar,

"Güvenlik odaklı işletim sistemi" denince akla ilk gelen isimlerden olan OpenBSD için bu hafta ilginç bir araştırma yayımlandı. Güvenlik firması Calif, OpenBSD 7.9'da yerel bir kullanıcının root yetkisi almasını sağlayan bir istismar zinciri yayımladı. Zincirin başlangıç noktası, kökleri yaklaşık 37 yıl öncesine, orijinal BSD kaynak kodlarına uzanan bir tam sayı taşması. İyi haber: Her iki açık da eylülde yamalandı. Kötü haber: Tam çalışan kavram kanıtı (PoC) kodu artık herkese açık; yani syspatch'i ihmal edenler için risk artık teorik değil.

Konuda Anlatılacaklar
  1. Ne yayımlandı?
  2. 37 yıllık sayaç: hata nereden geliyor?
  3. Zincir nasıl çalışıyor? (Üst düzey bakış)
  4. Neden "reliability fix" etiketi önemli?
  5. Düzeltmeler ve errata numaraları
  6. Sisteminizi nasıl kontrol edersiniz?
  7. Calif'in önerdiği sıkılaştırmalar
  8. Kaynaklar

Ne Yayımlandı?

Calif araştırmacısı Andrew Griffiths, 16 Ekim 2026'da "Big Fish" başlıklı bir yazı yayımladı. Calif'e göre şirket bu yılın başlarında OpenBSD'ye bazı açıkları, çoğunlukla önerilen yamalarla birlikte bildirmiş. The Hacker News'in aktardığına göre Calif, OpenBSD her iki açık için de eylülde yama yayımladıktan sonra ayrıntılı teknik yazıyı ve tam PoC kodunu kamuya açtı; kod GitHub'da bulunuyor.

Temel bilgiler:
  • Etki: Yerel ayrıcalık yükseltme (local privilege escalation), root yetkisi
  • Test edilen sürüm: OpenBSD 7.9
  • Atlatılan korumalar: KARL (çekirdek adres rastgeleleştirme), SMAP ve SMEP donanım korumaları
  • Bilgi sızdırma açığı gerekiyor mu?: Hayır
  • CVE: The Hacker News'e göre yayın itibarıyla iki açık için de CVE atanmadı
  • Gerçek dünyada sömürü: The Hacker News'e göre kanıt yok

Saldırganın önce sistemde yerel bir hesaba ya da kod çalıştırma imkânına sahip olması gerekiyor. Yani bu, uzaktan doğrudan sömürülebilen bir açık değil. Ama çok kullanıcılı sistemler, kabuk erişimi verilen sunucular ya da başka bir servisteki açık üzerinden düşük yetkili erişim elde edilmiş makineler için ciddi bir yetki yükseltme yolu.

37 Yıllık Sayaç: Hata Nereden Geliyor?

Hatanın merkezinde System V paylaşımlı bellek (shared memory) mekanizması var. Bir paylaşımlı bellek segmentine kaç sürecin bağlı olduğunu tutan shm_nattch alanı, The Hacker News'in aktardığına göre 1988 tarihli orijinal BSD kaynaklarında işaretli 16 bitlik bir short olarak tanımlanmış. Bu tipin alabileceği en büyük değer 32.767. OpenBSD bu tipi miras almış ve hiç genişletmemiş.

Calif'in açıklamasına göre paylaşımlı bellek bağlantı kayıtlarına sahip bir süreci tekrar tekrar çatallamak (fork), bu sayacı en büyük değerinin ötesine itip negatif bir değere taşırabiliyor. Bu tam sayı taşması, bir yarış durumu (race condition) üzerinden use-after-free'ye yol açabiliyor: Bozulan referans sayısı, çekirdeğin hâlâ başka süreçlerin kullandığı belleği serbest bırakmasına neden oluyor.

Bu, eski kodun neden tehlikeli olabileceğinin klasik bir örneği. 1988'de bir paylaşımlı bellek segmentine 32 binden fazla bağlantı olması muhtemelen hayal bile edilmiyordu; bugün ise bir saldırgan bunu bilerek tetikleyebiliyor.



Zincir Nasıl Çalışıyor? (Üst Düzey Bakış)

Savunma odaklı bir forum olduğumuz için adım adım istismar ayrıntısına girmeyeceğim; meraklılar teknik detayları Calif'in yazısında bulabilir. Kavramsal olarak zincir üç parçadan oluşuyor:

  1. Tam sayı taşması (shmat): Paylaşımlı bellek bağlantı sayacı taşırılıyor.
  2. Use-after-free (SysV IPC): Bozulan referans sayısı ve bir yarış durumu sayesinde serbest bırakılmış bellek yeniden kullanılıyor.
  3. Ayrı bir sınır dışı yazma (out-of-bounds write): Çekirdekteki çok noktaya yayın (multicast) üyelik verisinde bir sınır dışı yazma kullanılıyor. The Hacker News'e göre bu yazma sonucunda sayfa tablosu girdileri değişiyor ve bir kullanıcı belleği eşlemesi çekirdek tarafından erişilebilir hale gelerek SMAP ve SMEP atlatılıyor. Son adımda öngörülebilir bir çekirdek adresindeki işlev işaretçisinin üzerine yazılıyor.

Calif'in vurguladığı asıl dikkat çekici nokta, KARL'ın nasıl aşıldığı. Griffiths'in ifadesiyle KARL çekirdek ikili dosyasını yeniden bağlayarak işlev ve veri adreslerini rastgeleleştiriyor; ancak çekirdeğin bellek ayırıcıları deterministik kalıyor. Açılış sırasında yapılan bazı ayırmalar, aynı donanımda her açılışta aynı adreslere düşüyor. Bu öngörülebilirlik, istismarın ayrı bir bilgi sızdırma açığına ihtiyaç duymadan çalışmasını sağlıyor.

Neden "Reliability Fix" Etiketi Önemli?

The Hacker News'in altını çizdiği bir ayrıntı, sistem yöneticileri için çok önemli: Zincirin giriş noktası olan tam sayı taşmasını düzelten errata 018, OpenBSD tarafından güvenlik düzeltmesi değil, güvenilirlik düzeltmesi (RELIABILITY FIX) olarak sınıflandırıldı. OpenBSD 7.9 errata sayfasında da 018 bu etiketle, "shmat(4)'te tam sayı taşmasını önle" açıklamasıyla yer alıyor.

Pek çok kurumda yama politikası "güvenlik düzeltmelerini hemen uygula, diğerlerini bakım penceresinde" şeklinde işler. Bu olay, güvenilirlik olarak etiketlenmiş bir düzeltmenin de bir istismar zincirinin kritik parçası olabileceğini gösteriyor. OpenBSD'de syspatch zaten tüm errata'ları birlikte uyguladığı için düzenli syspatch çalıştıranlar etkilenmiyor; ama yamaları seçerek uygulayanlar dikkat etmeli.

Düzeltmeler ve Errata Numaraları

OpenBSD 7.9:
  • 018 - RELIABILITY FIX, 14 Eylül 2026: shmat(4)'te tam sayı taşmasının önlenmesi
  • 026 - SECURITY FIX, 30 Eylül 2026: Çekirdekte use-after-free'ye yol açabilen referans sayma hatası

OpenBSD 7.8:
  • 054 - RELIABILITY FIX, 14 Eylül 2026: shmat(4)'te tam sayı taşmasının önlenmesi
  • 062 - SECURITY FIX, 30 Eylül 2026: Çekirdekte use-after-free'ye yol açabilen referans sayma hatası

The Hacker News'e göre düzeltmeler syspatch üzerinden tüm mimariler için mevcut. Bir not: Calif ve haber kaynakları zincirde kullanılan multicast sınır dışı yazma hatası için ayrı bir errata numarası vermiyor; OpenBSD errata sayfalarını takip etmekte fayda var.

Sisteminizi Nasıl Kontrol Edersiniz?

Sürümünüzü kontrol edin:
Kod:
uname -a sysctl kern.version

Uygulanmış ikili yamaları listeleyin:
Kod:
syspatch -l

Uygulanabilir ama henüz kurulmamış yamaları görün:
Kod:
syspatch -c

7.9 için çıktıda 018 ve 026'yı, 7.8 için 054 ve 062'yi arayın:
Kod:
syspatch -l | grep -E "018|026|054|062"

Eksikse tüm yamaları uygulayın ve çekirdek yamaları olduğu için sistemi yeniden başlatın:
Kod:
syspatch reboot

OpenBSD errata sayfasına göre ikili güncellemeler amd64, i386 ve arm64 için sunuluyor; diğer mimarilerde imzalı kaynak kodu yamalarının uygulanması gerekiyor.



Calif'in Önerdiği Sıkılaştırmalar

Calif, yamaların ötesinde bu tür açık sınıflarını bütünüyle zorlaştıracak dört yaklaşım öneriyor:
  • Safe-unlinking: Çekirdekteki çift bağlı listelerde silme işleminden önce liste bütünlüğünü kontrol etmek. Calif'e göre FreeBSD ve NetBSD'nin sys/queue.h uygulamalarında bu zaten var.
  • Sayfa tablosu öz-referans eşlemesinin rastgeleleştirilmesi: İstismarın hedef aldığı adreslerin öngörülemez hale gelmesi.
  • Çekirdek bellek ayırıcısının rastgeleleştirilmesi: Açılıştaki taban adresin ve çalışma zamanındaki ayırma sırasının rastgeleleştirilmesi.
  • Derleyici tabanlı sınır kontrolleri: Array bounds sanitizer gibi özellikler. Calif, FreeBSD'ye bu özelliği sürüm derlemelerinde etkinleştirmeyi önerdiğini ve bu sanitizer'ın yakalayabileceği 21 sorunu özel olarak bildirdiğini söylüyor.

Calif'in kapanış notu da önemli: Yapay zeka destekli açık keşfi çağında, tek tek açıkları kapatmanın yanında bütün açık sınıflarını etkisiz kılan önlemler daha da kritik hale geliyor.

OpenBSD'yi güvenlik duvarı, VPN geçidi ya da DNS sunucusu olarak kullanan arkadaşlar, en son ne zaman syspatch çalıştırdınız? Ve yama politikanızda "reliability" etiketli düzeltmeleri nasıl ele alıyorsunuz? Yorumlarda görüşlerinizi bekliyorum.

Kaynaklar
Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).


Ek DosyalarEkran Görüntüleri
   
Cevapla



Hızlı Menü: