Linux SMB uygulamasında o3 kullanılarak uzaktan 0-day bulundu

• OpenAI o3 modeli kullanılarak Linux çekirdeğinin SMB uygulamasında uzaktan 0-day zafiyeti (CVE-2025-37899) bulunduğu deneyim paylaşılıyor
• ksmbd kodu üzerinde LLM analiz yeteneğini kıyaslama sürecinde, daha önce elle bulunan bir zafiyet referans alınarak LLM performansı karşılaştırılıyor
• Zafiyet tespiti sürecinde işlev bazında bağlam oluşturulup uygun promptlar verilerek o3'ün zafiyeti fark etmesi sağlanıyor
• Deney sonuçlarına göre o3, önceki LLM'lere kıyasla 2-3 kat daha yüksek doğrulukla zafiyet buluyor ve yeni türde bir use-after-free hatasını da aynı anda otomatik olarak keşfediyor
• LLM'ler, özellikle o3 gibi güncel modeller, kod denetimi ve zafiyet araştırmalarında insan yaklaşımına benzer esneklik ve yaratıcılık göstererek pratik kullanım değerini artırıyor

---

Giriş

Bu yazıda, OpenAI'nin o3 modelini kullanarak Linux çekirdeğinin SMB uygulamasında (ksmbd) uzaktan 0-day zafiyetinin nasıl bulunduğu anlatılıyor. Deney yalnızca o3 API'si kullanılarak, ek bir framework ya da araç olmadan yürütülüyor. ksmbd, Linux çekirdeği içinde SMB3 protokolünü uygulayarak ağ dosya paylaşımını sağlayan bir sunucu. LLM odaklı geliştirme işlerine kısa bir ara vermek için başlatılan bu zafiyet denetimi, o3'ün gerçek hataları ne kadar iyi bulabildiğini ölçen bir benchmark'a dönüşüyor. Burada özellikle, o3'ün bulduğu zero-day zafiyeti olan CVE-2025-37899'a odaklanılıyor.

Bu zafiyet, SMB logoff komutunun işlenişi sırasında ortaya çıkan bir use-after-free sorunu. Sorunun anlaşılması, sunucuya yönelik eşzamanlı bağlantı durumlarını ve belirli nesnelerin birden fazla thread tarafından nasıl paylaşıldığını kavramayı gerektiriyor. o3, bu eşzamanlılık sorunlarını ve nesne yönetimindeki hataları bağlam içinde anlayarak zafiyeti tespit ediyor. Bu, LLM'lerin bu tür bir zafiyeti bulduğuna dair kamuya açık ilk örnek.

Temel mesaj şu: o3, LLM'lerin kod analizi ve mantıksal akıl yürütme yeteneğinde yeni bir sıçrama olduğunu gösteriyor ve zafiyet araştırmacılarının bu eğilimi mutlaka yakından izlemesi gerekiyor. LLM'ler uzmanların yerini almıyor; ancak uzmanların üretkenliğini ve verimliliğini çarpıcı biçimde artıran araçlara dönüşmüş durumda. Kod 10 bin satırın altındaysa, o3 çoğu sorunun tespiti ve çözümünde pratik olarak anlamlı yardım sağlayabiliyor.

CVE-2025-37778 ile o3 benchmark'ı

Benchmark arka planı ve amacı

Önce, doğrudan elle bulunan bir zafiyet olan CVE-2025-37778 (bundan sonra kerberos kimlik doğrulama zafiyeti) referans noktası olarak alınarak o3'ün zafiyet tespit kabiliyeti değerlendiriliyor. Bu, istemci kimlik doğrulama sürecinde oturum durumunun belirli koşulları sağlaması halinde use-after-free oluşmasına yol açan bir sorun.

• Oturum durumu SMB2_SESSION_VALID iken kullanıcı nesnesi bellekten serbest bırakılıyor
• Sonrasında kimlik doğrulama başarısız olursa kullanıcı nesnesi yeniden başlatılmıyor ve bu durumda erişilebilir kalıyor; böylece use-after-free oluşuyor
• İlgili yolun tamamını anlamak için yaklaşık 3.300 satır kodun izlenmesi gerektiğinden, uygun zorlukta bir benchmark görevi oluşturuyor

Analiz bağlamının kurulması

Deneyde, gerçek bir otomatik zafiyet tespit sistemi bakış açısından, LLM'e verilecek bağlamın (kod bölgelerinin) dikkatle kurulması gerekiyor. SMB komut işleyicisi birimi temel alınarak ana işlevler ve alt işlevler 3 seviyelik çağrı derinliğine kadar dahil ediliyor; böylece mantıksal olarak ilişkili tüm kod girişe ekleniyor (toplam 3.3k LoC, yaklaşık 27k token). Veri ayrıştırma, istek dallanması, bağlantı sonlandırma gibi ilgili işlevlerin de dahil edilmesi, güvenilir sonuçlar için gerekli görülüyor.

Kullanılan somut promptlar ve giriş materyalleri ilgili Github deposunda görülebiliyor. LLM'e şu koşullar veriliyor:

• use-after-free zafiyetini tespit etmesi açıkça isteniyor
• ksmbd'nin temel yapısı ve tehdit modeli kısaca açıklanıyor
• yanlış pozitifleri (False Positive) azaltmaya yönelik yönlendirici promptlar kullanılıyor

Gerçek sorgular, deney sonuçlarını toplamak için llm komut satırı aracıyla tekrar tekrar çalıştırılıyor (N=100).

Benchmark deney sonuçları

• o3: 100 denemenin 8'inde kerberos kimlik doğrulama zafiyetini tespit ediyor, 66'sında kaçırıyor, 28'inde yanlış pozitif bildiriyor
• Claude Sonnet 3.7: yalnızca 3 kez tespit ediyor
• Claude Sonnet 3.5: 100 denemenin tamamında tespit edemiyor

Sonuç olarak o3, önceki LLM'lere kıyasla 2-3 kattan fazla daha yüksek doğruluk sergiliyor. Ayrıca o3'ün gerçek çıktısı, bir insan güvenlik araştırmacısının yazdığı özet rapora benzer biçimde kısa ve öz. Buna karşılık Sonnet 3.7 çıktıları, sürece odaklı bir çalışma günlüğü izlenimi veriyor; bunun da hem artıları hem eksileri var.

o3 ile gerçek bir 0-day keşfi (CVE-2025-37899)

Büyük ölçekli kod girişi ortamında deney

Kerberos zafiyetine ek olarak, tüm SMB komut işleyicileri (yaklaşık 9.000 satır) o3'e verilerek genel zafiyet tespiti de deneniyor. Çeşitli işleyiciler ve bağlantı/ayırma kodları dahil edilince toplam yaklaşık 12k LoC (yaklaşık 100 bin token) tek seferde giriş olarak kullanılıyor. 100 tekrar sonunda kerberos kimlik doğrulama zafiyeti yalnızca 1 kez bulunuyor; bu da performans düşüşünü açıkça gösteriyor. Ancak asıl amaç, daha geniş kod kapsamlarında LLM'in kullanılabilirliğini denemek.

Bu deneyde bulunan yeni zafiyet

Bu sırada o3, kerberos kimlik doğrulama zafiyetinden bağımsız olarak yeni bir use-after-free hatası da tespit ediyor. Sorun, oturumun logoff işleyicisinde, iki thread'in eşzamanlı bağlantı durumunda oturumun user nesnesini paylaşması/erişmesi ve bir thread nesneyi serbest bıraktıktan sonra diğer thread'in ona başvurmaya devam edebilmesiyle ortaya çıkan bir eşzamanlılık hatası.

o3'ün otomatik zafiyet raporu özeti

• İki worker thread birlikte çalışıyor; bunlardan biri oturum sonlandırma (logoff) sırasında user nesnesini bellekten serbest bırakırken, diğeri mevcut oturumda aynı user nesnesini kullanmaya devam ediyor
• Serbest bırakmanın hemen ardından (henüz NULL ile başlatılmadan önce) başka bir yolda dereference gerçekleşirse klasik bir use-after-free oluşuyor
• Zamanlamaya bağlı olarak NULL dereference kaynaklı DoS da meydana gelebiliyor
• Bu durum çekirdek belleğinin bozulmasına ve keyfi kod çalıştırmaya kadar gidebiliyor

Otomatik rapordan elde edilen içgörüler

Bu otomatik rapor sayesinde, mevcut kerberos kimlik doğrulama zafiyetindeki düzeltme yaklaşımının (serbest bırakmadan hemen sonra NULL atamak) logoff işleme yolu için temel çözüm olmadığını fark ediliyor. Başka bir deyişle, güvenliği garanti etmek için oturum bağlama ve thread'ler arası saldırı vektörlerinin de hesaba katılması gerekiyor. o3 de bazı raporlarında bunu fark ederek daha güçlü bir düzeltme önerebildiğini fiilen göstermiş oluyor.

Sonuç

LLM'ler, özellikle o3 gibi güncel modeller, kodu yaratıcı ve esnek biçimde analiz etme açısından önceki tekniklere göre insan güvenlik araştırmacılarına çok daha yakın bir performans gösteriyor. Yakın zamana kadar bu sadece teorik bir olasılık olarak tartışılıyordu; ancak gerçek örneklerde pratikte işe yarayan bir seviyeye ulaşan ilk model o3 olmuş görünüyor. Elbette o3'te de hâlâ yanlış alarm ve kaçırma ihtimali var; ancak gerçekten faydalı sonuç üretme olasılığı belirgin biçimde arttığı için pratik kullanıma sokmanın anlamlı olduğu bir noktaya gelinmiş durumda. Artık zafiyet araştırmacıları ve geliştiricilerin, LLM'leri kendi iş akışlarına verimli biçimde nasıl entegre edeceklerini araması gerekiyor.

[GN⁺]

Hacker News görüşü

• Yazar, sistem promptu, arka plan bilgisi ve yardımcı komutlar gibi parçaları ayrı .prompt dosyaları halinde düzenleyip bunları llm üzerinden çalıştırarak projeyi yönettiğini belirtmiş
  LLM’leri bu kadar sistematik kullanma biçimi, bunun da diğer mühendislik araçları gibi dikkatli tasarım düşüncesi ve ince ayarlı spesifikasyon dengesi gerektirdiğini hissettiriyor
  İlgili projeye buradan bakılabilir

  • İlginç olan, yazarın bu kısım hakkında “aslında tüm sistem promptum tahmine dayanıyor ve bilim ya da mühendislikle pek ilgisi yok” diye dürüstçe söylemiş olması, bana komik geldi

  • Farklı prompt yazma yöntemleri var ama bunları gerçekten değerlendirecek ya da karşılaştıracak sağlam bir ölçüt olmadığı için biraz doğaçlama büyü okumaya benziyor gibi geliyor
    Örneğin “sen bir açık bulma uzmanısın”, “bana sahte değil gerçek açıkları söyle” gibi talimatlar ya da modelin iyi tepki verdiği varsayılan rastgele HTML etiketleriyle bölümlere ayırmak gibi şeyler
    Mühendislik tarafının bunun neresine girdiği belirsiz

  • Özünde kararsız ve öngörülemez bir sistemi kontrol etmeye çalışırken mühendislik ilkelerini devreye sokma fikri komik geliyor
    Böyle promptlara aslında “ipucu” demek daha uygun olurdu
    Bugünün bütün LLM’leri, prompt çelişkili olsa bile, çoğu zaman promptu görmezden gelip (gerçek olup olmamasından bağımsız olarak) mutlaka bir yanıt üretmeye yöneliyor

• Yazıda sinyal-gürültü oranının yaklaşık 1:50 olduğu söylenmişti; yazarın kod tabanını iyi tanıdığı için anlamlı sinyali seçebildiğini düşünüyorum
  Bence asıl büyük fırsat, bu anlamlı sinyali ayıklama işinin otomatikleştirilmesi; o yüzden bundan sonraki gelişmeleri dikkatle izleyeceğim

  • Biz de bu sinyal-gürültü oranı sorununu iyileştiren bir sistem geliştiriyoruz ve son dönemde popüler olan yazılım ajanlarını da doğrudan benchmark ediyoruz
    Sonuçlardaki oynaklık çok yüksek ve yakında yapılacak bir konferansta tüm deney sonuçlarını açıklamayı planlıyoruz
    Sektördeki güncel tabloyu topluca görmek mümkün olacak

  • Birkaç gün önce aklıma geldi: Linux çekirdeğindeki tüm geçmişi, yani bütün git değişikliklerini, mailing listeleri vb. kullanarak bunu fine-tune edilmiş bir modele dönüştürmek mümkün olabilir mi diye düşündüm
    Böyle bir LLM, gerçekten yıllar boyunca kodla uğraşmış bir geliştiricinin sezgisine daha yakın sentetik bir sürüm olabilir gibi geliyor
    Yüksek bağlam penceresiyle bile çok şey kapsanabilir; bazı kod tabanları sadece kod olarak bile 200 bin token’ı aşıyor, o yüzden mümkün görünüyor

  • 1:50 oranı, “samanlıkta iğne aramak” türü durumlar için aslında gayet iyi bir tespit oranı

  • Eğer LLM her açık tahmini için bunu kanıtlayan harness’leri ve proof-of-concept testlerini de kendisi yazabilirse, sinyal-gürültü oranı ciddi biçimde iyileşir
    Ama bugün böyle bir otomasyonun maliyeti hâlâ oldukça yüksek

• En etkileyici kısım, yazarın farklı LLM modelleri için açık aramasını tam 100 kez tekrarlamış olmasıydı
  Bu kadar kaynak kullanımı, şimdiye kadar LLM ile ele aldığım çoğu probleme kıyasla çok yüksek; ben de artık modele biraz “kör tekrar” yaptırmayı düşünmeye başladım

  • Sonuçta iş dönüp dolaşıp çok para gerektiriyor

  • Zero-day açıklar ciddi paralara satılıyor ve bug bounty’den de gelir elde edilebiliyor
    LLM kullanım maliyeti bu ödüllerle karşılaştırınca çok küçük kalıyor
    Muhakeme maliyetinin neredeyse sıfıra indiği bir gelecekte güvenlik ortamı tamamen farklı görünecek

  • Model başına 100 çalıştırma demek, enerji tüketiminin de ciddi olduğu anlamına geliyor
    C tabanlı kodlarda sık görülen bir açığı bulmak için bu kadar kaynak harcanması, işi anlamlı olmaktan çıkarıp daha çok israf ve lüks göstergesi haline getiriyor gibi
    Dünya çapında bir iklim krizinin içindeyken, 1950’lerdeki gibi çok da değerli olmayan işler için kaynak yakmaya devam etmemiz beni gerçekten endişelendiriyor

• Claude’da ayrı bir scratchpad (ara düşünceleri toparlama alanı) verilmediği için, sonuçta düşünce akışıyla raporun birbirine karıştığını düşünüyorum
  Claude’a resmi olarak düşüncelerini düzenleyebileceği bir alan verilirse ne kadar farklı davranacağını test etmek isterim
  o3, temel noktaları insan yazımı bir bug report gibi süzüp aktarırken, Sonnet 3.7 çıktılarında zihinsel akış veya çalışma günlüğü hissi kalıyor; bence bu da aynı bağlamın parçası

  • Ben bizzat o3, 3.7 ve Gemini 2.5 pro kullandım; o3 bana göre kıyas kabul etmeyecek düzeyde
    Benchmark skorları çok büyük görünmeyebilir ama iş karmaşıklaştıkça bu farkın anlamı büyüyor
    Geçen yıl kasımda duyurulup ancak yaklaşık bir ay önce yayınlanmasının sebebini merak ediyorum (muhtemelen güvenlik hazırlıkları yüzündendir); o4’ü de sabırsızlıkla bekliyorum

  • “scratchpad”i araştırmada kullanan örnekler, makaleler veya ilgili bağlantılar önerebilir misiniz diye merak ediyorum

• Prompt engineering sürecinin özünü çok iyi özetleyen bir bölüm olmuş
  Özellikle “yanlış pozitifler yüzünden hatalı açıklar işaretlenmesin diye elimden gelenin en iyisiyle yönlendirdim ama bunun gerçekten faydalı olup olmadığını bilmem mümkün değil, sadece öyle olmasını umuyorum; bunun etkili olup olmadığını henüz yeterince değerlendirmedim, yani bu ne bilim ne de mühendislik, değerlendirmeyi sonra paylaşacağım” kısmı benim prompt geliştirme sürecime fazlasıyla benziyor

• LLM’ler için en uygun kullanım alanının belki de tam olarak bu tür bir şey, yani otomatik açık tespiti olduğunu düşünüyorum
  Teorik olarak tüm süreç otomatikleştirilebilir; LLM, çok gelişmiş bir fuzzer gibi kullanılıp hedef sürekli bir VM içinde çalıştırılır, anomali görülürse gerçek açık olasılığı tespit edilebilir
  (İlk exploit’lerin çoğunun makineyi düşürmek ya da crash üretmekle başlayıp sonra geliştirildiğini hatırlayın)
  Bu tür LLM kullanımı bir yandan çok etkili görünüyor, ama öte yandan “bunu yapabiliyor olmamız, mutlaka çok yeni ya da belirleyici bir şey keşfettiğimiz anlamına gelmiyor” sonucunu da düşündürüyor

• zk bug’ların (zero-knowledge proof ile ilgili) otomatik hedeflenmesi konusunda yaptığım sunuma ait YouTube bağlantısını bırakıyorum

  • Yukarıdaki YouTube videosunun takip parametreleri çıkarılmış temiz bağlantısını da ayrıca paylaşıyorum
    Ek parametreler bağlantı takibi amaçlı gibi düşünülebilir

• Umarım iş, curl’de sürekli patlayan sorunlarda olduğu gibi olmaz
  İlgili bağlam için Daniel Stenberg’in yazısına bakılabilir

• Bildiğim kadarıyla ksmbd, geleneksel Samba sunucusuna kıyasla daha hafif ve yüksek performans hedefleyen, çekirdek alanında çalışan bir SMB sunucusu
  S1: Gerçekte ksmbd’yi production ortamında kimler kullanıyor, merak ediyorum
  S2: Kullanıyorlarsa neden kullanıyorlar, onu da merak ediyorum

  • 1. Solaris veya Windows’ta çekirdeğe gömülü SMB sunucularını kullanmaya alışık olanlar muhtemel kullanıcı grubudur diye düşünüyorum

2. Samba’nın performansı buna kıyasla oldukça geride kalıyor; bu yüzden 2025’te bile birçok kişi dosya paylaşım sunucusu olarak Windows çalıştırıyor
   Acaba bunun Windows’taki gibi ACL desteğini native olarak sunup sunmadığını bilen var mı?
   (Bu, Solaris çalıştırmaya devam etmek için elimde kalan son sebepti; bildiğim kadarıyla ZFS üzerinden destekleniyordu)
   Samba hâlâ Unix’in UID/GID ve güvenlik modeliyle senkron kalmaya çalışan, biraz modası geçmiş bir yapı
   Çekirdek içi SMB sunucularında ise Windows tarafında ciddi uzaktan root açıkları gerçekten yaşandı; dolayısıyla takasları net görmek lazım

• Sebep lisans meselesi
  Samba GPLv3, Linux ise yalnızca GPLv2 kullanabiliyor

• Tahminimce sadece hafif ve yüksek performanslı olduğu için kullanılıyor

• relayd yerine kmod-trelay kullanılmasına benzer bir sebep gibi geliyor

• Bence LLM’lerin kısa vadeli en büyük alignment problemi tam da bu tür açık otomasyonunda ortaya çıkıyor
  Ben de yakın zamanda ara sıra kullandığım niş bir sunucuda, LLM ile neredeyse hiç emek harcamadan gerçekten ciddi bir güvenlik açığı buldum
  Bu pazar otomatikleşirse, geçmişte elle istismar etmeye değmeyecek kadar önemsiz görülen uzun kuyruk yazılımlarda bile ciddi sorunlar topluca patlayabilir diye endişeleniyorum

  • Öte yandan, bu teknolojik ilerleme sayesinde biz de kendi kod tabanımızı “saldırgan bakış açısıyla” otomatik analiz edebilir hale geliyoruz
    Yoksa bir araştırmacının bulup bize karşı kullanabileceği açıkları önceden kapatma fırsatı doğuyor
    O yüzden buna alignment problemi demek çok uygun olmayabilir

  • Saldırganlar açık bulmayı otomatikleştirebilir ama savunmacılar da aynı kabiliyeti edinebilir
    Commit onay sürecine veya her build’e savunma otomasyonu eklemek de mümkün