Claude Mythos Preview ile Firefox’u güçlendirmenin perde arkası

 (hacks.mozilla.org)
5 puan yazan GN⁺ 2026-05-08 | 2 yorum | WhatsApp'ta paylaş
  • Mozilla, model performansını artırıp harness iyileştirmeleri yaparak yapay zeka tarafından üretilen güvenlik raporlarında sinyali yükseltip gürültüyü azalttı; böylece Firefox’ta gerçek güvenlik hatalarını büyük ölçekte bulan bir pipeline kurdu
  • Firefox 150 release sürümünde Claude Mythos Preview tarafından belirlenen 271 hata düzeltildi; 149.0.2, 150.0.1 ve 150.0.2 sürümlerine de ilgili düzeltmeler eklendi
  • Açıklanan öne çıkan hatalar arasında JIT’in WebAssembly GC struct başlatmasını kaldırmasından kaynaklanan sahte nesne primitive’i, IPC race condition üzerinden parent process UAF, NaN deserileştirme sorunu, XSLT’de 20 yıllık rehash hatası ve rowspan=0 kullanan 16 bit layout bitfield overflow yer alıyor
  • Açıklanan hataların önemli bir bölümü sandbox escape niteliğinde; bozulmuş bir content process’in ayrıcalıklı parent process’e yetki yükseltmesi varsayımına dayandığı için yalnızca fuzzing ile bulunması zor olan saldırı yüzeylerini yapay zeka analizi daha kapsamlı ele aldı
  • Mozilla, mevcut fuzzing altyapısının üzerine agentic bir harness ekleyerek yeniden üretilemeyen tahminleri eledi ve hipotezleri test case’lerle doğruladı; sonraki adımda bunu sürekli entegrasyona bağlayıp patch’ler tree’ye girdiğinde taramayı planlıyor

Yapay zeka modeliyle ortaya çıkan Firefox güvenlik hatalarındaki değişim

  • Birkaç ay öncesine kadar açık kaynak projelerine gelen yapay zeka üretimi güvenlik hata raporları çoğu zaman makul görünse de yanlış çıkıyor ve bakımcılara asimetrik maliyet yüklüyordu
  • Firefox tarafında kısa sürede tablo ciddi biçimde değişti; bunun temel nedeni hem model performansındaki artış hem de modeli bir harness ile yönlendirip genişleterek ve birleştirerek sinyali artıran, gürültüyü filtreleyen tekniklerdeki gelişmelerdi
  • Mozilla normalde güvenlik danışmanlıkları ve düzeltmeler yayımlandıktan sonra bile ayrıntılı hata raporlarını birkaç ay gizli tutuyor, ancak bu kez ekosistem genelindeki aciliyet ve ilgiyi gözeterek bazı raporları yayımlamaya karar verdi
  • Yayımlanan raporlar tarayıcının farklı alt sistemlerinden seçildi; seçim bir ölçüde rastgele olsa da, raporların derinliği ve çeşitliliği savunmacıların bu tekniği uygulaması gerektiğini gösteriyor

Açıklanan öne çıkan hatalar

  • 2024918
    • Hatalı bir eşdeğerlik kontrolü nedeniyle JIT, canlı bir WebAssembly GC struct başlatmasını optimizasyonla kaldırdı ve hem iç hem dış araştırmacıların yoğun fuzzing’den geçirdiği kodda potansiyel keyfi okuma-yazmaya bağlanabilen bir sahte nesne primitive’i oluşturabildi
  • 2024437
    • <legend> öğesindeki 15 yıllık bir hata; recursive stack derinliği sınırı, expando özellikleri ve cycle collection gibi tarayıcının birbirinden uzak bölgelerindeki edge case’lerin hassas biçimde birleştirilmesiyle tetikleniyor
  • 2021894
    • IPC race condition güvenilir biçimde sömürülerek bozulmuş bir content process’in parent process’teki IndexedDB reference count değerlerini manipüle etmesine, UAF ve potansiyel sandbox escape oluşturmasına yol açabiliyordu
  • 2022034
    • Ham bir NaN, IPC sınırını geçerken etiketli bir JS object pointer’ı gibi görünebiliyor; bu da double deserileştirmenin parent process’te sahte nesne primitive’ine ve sandbox escape’e yol açabilmesine neden oluyordu
  • 2024653
    • İç içe event loop’lar, pagehide listener’ları ve garbage collection’ı birleştiren karmaşık bir test case ile <object> öğesinin özellik setter’ında UAF tetikleniyor
    Reklam
  • 2022733
    • WebTransport’a binlerce certificate hash yüklenerek reference count’un yoğun olduğu bir kopyalama döngüsündeki race condition genişletiliyor ve bozulmuş bir content process’ten IPC yoluyla parent UAF tetiklenebiliyordu
  • 2023958
    • glibc DNS işlev çağrıları yakalanıp kötü amaçlı bir DNS sunucusu simüle edilerek UDP’den TCP’ye geçişteki fallback edge case yeniden üretildi; bunun sonucunda HTTPS RR ve ECH ayrıştırması sırasında buffer over-read ve parent process stack memory leak oluştu
  • 2025977
    • Yeniden giriş yapan key() çağrısı hash table rehash tetikleyip backing store’u serbest bırakıyor, ancak ham entry pointer’ı kullanılmaya devam ediyordu; bu, düzeltilen birkaç sec-high XSLT sorundan biri olan 20 yıllık bir XSLT hatasıydı
  • 2027298
    • Color picker patch’lenerek otomasyona zor gelen kullanıcı seçimi simüle edildi; ardından senkron input event’leriyle iç içe event loop çalıştırılıp actor teardown’a yeniden girildi ve callback serbest bırakılırken freed edilmesi sağlanarak content process UAF oluşturuldu
  • 2023817
    • Bozulmuş bir content process, parent process’e keyfi wallpaper image decode ettirebiliyordu; varsayımsal bir image decoder zafiyetiyle birleştiğinde bu durum sandbox escape’e dönüşebilirdi
    • Parent process’te girdinin güven seviyesini belirlemek için otomasyonu zor bir çıkarım gerekiyordu
  • 2029813
    • Firefox 95’in ince taneli sandboxing teknolojisi RLBox içinde, güvenilmeyen taraftan güvenilen tarafa değer kopyalayan doğrulama mantığındaki bir boşluktan yararlanılarak sandbox atlatıldı
  • 2026305
    • HTML tablolarındaki özel rowspan=0 anlamını kullanan çok küçük bir test case, >65535 satır ekleyerek clamping’i atlattı ve 16 bit layout bitfield’ını overflow etti; bu hata yıllarca fuzzer’lara yakalanmadı
    Reklam

Sandbox escape ve savunma katmanları

  • Açıklanan hataların önemli kısmı sandbox escape niteliğinde ve Firefox’un tüm zincirinin ele geçirilmesine dönüşmesi için başka exploit’lerle birleştirilmesi gerekiyor
  • Bu raporlar, site içeriğini işleyen sandbox process’inin zaten ayrı bir hatayla bozulduğu ve saldırgan kontrolündeki makine kodunun ayrıcalıklı parent process’e yetki yükseltmeye çalıştığı bir durumu varsayıyor
  • Model, sandbox escape oluştururken düzeltilmiş kod yalnızca sandbox process içinde çalıştığı sürece Firefox kaynak kodunu patch’leyebiliyor
  • Bu tür hataları fuzzing ile bulmak zor; Mozilla bu yüzden snapshot tabanlı IPC fuzzing gibi teknikler geliştirdi, ancak yapay zeka analizi bu kritik yüzeyi çok daha kapsamlı kapsayabildi
  • Modelin bulamadığı noktalar da önemliydi
    • Son yıllarda güvenlik araştırmacıları, ayrıcalıklı parent process’te prototype pollution tetikleyerek process sandbox’tan çıkmaya yönelik birçok rapor gönderdi
    • Mozilla bunları tek tek düzeltmek yerine, varsayılan olarak prototype’ları freeze eden bir mimari değişiklik uyguladı
    • Harness log’larında bu kaçış yolunun denendiği ancak tasarım gereği engellendiğine dair çok sayıda iz görüldü; bu da önceki hardening çalışmalarının doğrudan etkisini gösterdi

Harness ile güvenlik güçlendirme pipeline’ı kurmak

  • Mozilla son birkaç yıldır GPT 4 veya Sonnet 3.5 gibi modellerle yüksek riskli kodu statik olarak analiz eden LLM kod denetimi deneylerini kurum içinde yürütüyordu
  • İlk deneyler potansiyel gösterse de false positive oranı yüksekti ve ölçeklendirmeyi zorlaştırıyordu
  • Güvenlik sorunlarını güvenilir biçimde saptayan agentic harness’lerin ortaya çıkmasıyla durum değişti
    • Gerçek hatalar bulunabiliyor
    • Yeniden üretilemeyen tahminler elenebiliyor
    • Uygun arayüz ve yönlendirmeyle yeniden üretilebilir test case’ler oluşturulup çalıştırılarak kod hatası hipotezleri dinamik biçimde doğrulanabiliyor
  • Mozilla, şubatta Anthropic’in gönderdiği ilk sorunları düzelttikten sonra mevcut fuzzing altyapısının üzerine kendi harness’ini kurdu
  • Başlangıçta Claude Opus 4.6 ile sandbox escape bulmaya yönelik küçük ölçekli deneyler yapıldı
    • Bu model tek başına bile çok süreçli tarayıcı motoru kodunda karmaşık akıl yürütme gerektiren, daha önce bilinmeyen önemli sayıda zafiyet belirledi
    • İlk aşamada süreç terminalden doğrudan izlenerek prompt ve mantık gerçek zamanlı ayarlandı
    • Davranış kararlı hale gelince işler çok sayıda ephemeral VM’e paralel dağıtıldı ve her VM belirli hedef dosyalarda hata arayıp sonucu bir bucket’a yazdı
  • Yalnızca keşif alt sistemleri yeterli değildi
    • Neyi arayacağı, nereye bakacağı ve çıktıyı nasıl işleyeceği dahil tüm güvenlik hata yaşam döngüsü ile entegrasyon gerekiyordu
    • Buna mevcut kayıtlarla tekrarları eleme, bug tracking, triage ve düzeltme dağıtımı da dahildi
    • Modeller, harness’i çalıştıran temel primitive’ler ama bunu ölçekli ve faydalı hale getirmek için tüm pipeline gerekli
    Reklam
  • Harness projeler arasında yeniden kullanılabilir olsa da pipeline, codebase’in anlamı, araçları ve süreçlerine göre projeden projeye değişiyor
  • Firefox mühendislerinin gelen hataları işleme süreciyle yakın bir geri bildirim döngüsü kurmak gerekti ve önemli ölçüde iterasyon yapıldı

Claude Mythos Preview ve model değiştirmenin etkisi

  • Uçtan uca pipeline kurulduktan sonra yeni bir model çıktığında başka bir modelle değiştirmek kolaylaşıyor
  • Mozilla, açık modellerle de birçok ciddi hata buldu ve bu pipeline sayesinde Claude Mythos Preview değerlendirme fırsatı geldiğinde hemen kullanabildi
  • Model yükseltmesi tüm pipeline’ın etkisini artırdı
    • Olası hataları daha iyi buldu
    • Hatayı kanıtlayan proof-of-concept test case’leri daha iyi üretti
    • Patolojiyi ve etkiyi daha iyi özetledi
  • Firefox 150 release sürümünde Claude Mythos Preview’ın belirlediği 271 hatanın düzeltilmesine ek olarak, 149.0.2, 150.0.1 ve 150.0.2 sürümlerinde de ilgili düzeltmeler yer aldı
  • İçeride başka yöntemlerle de hata bulunmaya devam ediyor; diğer projelerde olduğu gibi son aylarda dış raporlar da belirgin biçimde arttı
  • Tüm hataların doğru biçimde düzeltilmesi dikkatli çalışma gerektirdi ve benzeri görülmemiş ölçekteki bu hacme yetişebilmek için son aylarda yoğun emek ve uzun mesailer harcandı
  • En güvenli Firefox’u dağıtmak için 100’den fazla kişi kod katkısı yaptı; patch yazımı ve incelemesinin yanı sıra pipeline’ın kurulması ve büyütülmesi, triage, düzeltme testleri ve her hatanın release sürecinin yönetimi de yürütüldü

Temel çıkarımlar

  • Yazılım geliştiren herkes bugün modern modeller ve harness’ler kullanarak hata bulabilir ve kodunu güçlendirebilir
  • Basit bir prompt ile başlayıp gözlemleyerek iterasyon yapılabilir
    • İlk prompt, bu videodaki yaklaşımdan çok farklı değildi
    • Süreç içinde pipeline optimizasyonu ve ölçekleme için çok sayıda orchestration ve araç eklense de, iç döngünün özü “bu kod bölümünde hata var, bul ve bir test case üret” yaklaşımıydı
  • Firefox’taki tüm potansiyel hatalar tamamen tüketilmiş değil, ancak mevcut gidişattan memnuniyet var
  • Mevcut taramalar çoğunlukla insan yargısı ve otomatik sinyallerin birleşimiyle seçilmiş belirli kod alanlarına, yani dosya ve fonksiyonlara odaklanıyor
  • Yakın gelecekte bu analizin sürekli entegrasyon sistemine bağlanıp patch’ler tree’ye girdiğinde tarama yapılması planlanıyor
  • Modeller, kendilerine verilen bağlam biçimine esnek uyum sağlıyor ve patch tabanlı taramanın dosya tabanlı tarama kadar hatta daha iyi çalışması bekleniyor
  • Şu an hem riskli hem de fırsatlarla dolu bir dönem; interneti daha güvenli kılmak için birlikte hareket etmek gerekiyor

Sık sorulan sorular

  • “271 hata” ile güvenlik danışmanlığı sayılarının farklı olmasının nedeni

    • Güvenlik danışmanlığı web sayfası, dahili olarak bildirilen birden fazla hatayı tek bir “rollup” CVE altında grupluyor
    • Web sayfası, CVE atamalarının resmi kaynağı olan foundation-security-advisories deposundaki yaml verisinden üretiliyor
    • Bazı tarayıcılar içeride bulunan sorunlar için CVE tanımlayıcısı oluşturmuyor, ancak Mozilla mümkün olduğunca şeffaf olmak için bunları yayımlıyor
    • Firefox 150’de üç dahili rollup vardı
      • CVE-2026-6784: 154 hata
      • CVE-2026-6785: 55 hata
      • CVE-2026-6786: 107 hata
    • Üç dahili rollup’ın toplamı 316 ediyor; bu sayı Claude Mythos Preview ile bulunduğu açıklanan 271’den fazla
    • Bunun nedeni, Mozilla güvenlik ekibinin her gün Firefox’a saldırıp yeni hatalar bulması ve bunun için fuzzing sistemleri, manuel inceleme ve çeşitli modeller kullanan yeni agentic pipeline’ın birleşimini kullanması
    • Nisan sürümünde toplam 423 güvenlik hatası düzeltildi
      • İki hafta önce duyurulan 271 hata
      • Dışarıdan bildirilen 41 hata
      • Kalan 111 hata dahili keşifti ve kabaca üç gruba ayrılıyordu
        • Bu pipeline ile Claude Mythos Preview kullanılarak bulunmuş ama Firefox 150 dışında başka sürümlerde düzeltilmiş hatalar
        • Bu pipeline ile başka modeller kullanılarak bulunmuş hatalar
        • Fuzzing gibi başka tekniklerle bulunmuş hatalar
        Reklam
    • Anthropic’e, bu son çalışmadan ayrı olarak doğrudan üç CVE kredisi verildi
      • CVE-2026-6746
      • CVE-2026-6757
      • CVE-2026-6758
    • Bunlar, birkaç ay önce Anthropic Frontier Red Team’in Mozilla’ya gönderdiği hataların düzeltmeleriydi ve standart prosedür gereği her birine ayrı CVE atandı

  • Güvenlik önem derecesi puanlarının anlamı

    • Mozilla, hatanın aciliyetini göstermek için security severity ratings ölçeğini critical’dan low’a kadar kullanıyor
    • sec-critical ve sec-high, bir web sayfasını ziyaret etmek gibi normal kullanıcı davranışlarıyla tetiklenebilen zafiyetlere veriliyor
    • sec-critical ile sec-high arasında teknik bir fark yok; ancak sec-critical yalnızca kamuya açıklanmış veya gerçek saldırılarda kullanıldığı bilinen sorunlar için kullanılıyor
    • sec-moderate, normalde sec-high sayılabilecek ama kurbanın olağandışı ve karmaşık adımlar atmasını gerektiren zafiyetler için veriliyor
    • sec-low ise güvenli crash gibi kullanıcıya zarar verme ihtimali düşük can sıkıcı hatalar için kullanılıyor
    • Firefox 150’de duyurulan 271 hatanın dağılımı şöyleydi
      • sec-high 180
      • sec-moderate 80
      • sec-low 11
    • Mozilla en çok critical/high hatalara önem verse de, doğruluk sorunlarını düzeltmek ve defense-in-depth için moderate ve low güvenlik hatalarını da önceliklendirmek yaygın bir uygulama

  • sec-high veya sec-critical ile gerçek exploit arasındaki fark

    • sec-high ya da sec-critical bir hata, bunun otomatik olarak pratik bir exploit olduğu anlamına gelmez
    • Çoğu durumda tek bir critical/high hata Firefox’u ele geçirmek için yeterli değildir
    • Firefox, defense-in-depth mimarisine sahiptir; örneğin bir JIT hatası sömürülse bile sonuç, sandbox içinde ve site bazında ayrılmış bir process’te remote code execution elde etmek olabilir
    • Gerçek saldırganlar genellikle birden fazla exploit’i zincirleyerek bir veya daha fazla sandbox katmanını ve ASLR gibi işletim sistemi düzeyindeki önlemleri aşarak yetki yükseltmek zorundadır
    • Mozilla, bir hatanın gerçek saldırganlar tarafından kullanılabilir olup olmadığını doğrulamak için genellikle exploit geliştirmez
    • sec-high sınıflandırması, AddressSanitizer’ın raporladığı use-after-free veya out-of-bounds bellek sorunları gibi öngörülebilir crash belirtilerine dayanır
    • Tehdit modeli, yeterince emek verilirse bu tür hataların sömürülebilir olabileceğini varsayar
    • Bu yaklaşım, sömürülebilirlik analizindeki false negative riskini azaltır ve daha fazla zafiyet bulup düzeltmeye kaynak ayırmayı sağlar

İlgili okumalar

2 yorum

 
GN⁺ 2026-05-09
Hacker News yorumları

  • Tekrar vurgulamak gerekirse, bug bug’dır. “Potansiyel güvenlik açığı” da bir bug’dır ve güvenlik açıklarının güvenlik etkisinin, bir kavram kanıtı ya da benzeri bir kanıtla doğrulanması gerekir
    Kelimeler önemlidir, bug’lar da önemlidir. Çok sayıda bug’ı düzeltmek öteden beri önemliydi ve gerçekten yapılan bir işti; bu tek başına da yeterince etkileyici
    Mythos’un 271 güvenlik açığı için kavram kanıtı yazıp güvenlik etkisi olan kod yoluna ulaşılabildiğini gösterdiği söylenmiyor. Mythos geçerli 271 bug buldu ve bence bu yeterli

    • Tanım biraz kafa karıştırıcıydı ama Mozilla o 271 “şeyi” şöyle ayırmış [1]
      Ek bağlam olarak Mozilla, bug’ların aciliyetini göstermek için critical ile low arasında güvenlik şiddeti dereceleri kullanıyor. sec-critical ve sec-high, web sayfası ziyareti gibi sıradan kullanıcı davranışlarıyla tetiklenebilen güvenlik açıklarına veriliyor; teknik olarak ikisini ayırmıyorlar ama sec-critical, kamuya açıklanmış ya da gerçek hayatta istismar edildiği bilinen sorunlar için ayrılmış
      sec-moderate, normalde sec-high sayılacak ama mağdurdan sıra dışı ve karmaşık adımlar gerektiren güvenlik açıklarına veriliyor; sec-low ise kullanıcıya zarar vermekten uzak, can sıkıcı bug’lar için, örneğin güvenli crash’ler için kullanılıyor
      Firefox 150’de duyurulan 271 bug’ın 180’i sec-high, 80’i sec-moderate, 11’i sec-low idi
      Mozilla, hemen aşağıda bunun pratik exploit ile eşanlamlı olmadığını söylese de sec-high için de “vulnerability” kelimesini kullanıyor. Tanım sayfasında sec-low bile “vulnerabilities” olarak sınıflandırılıyor [2]
      Kelimeler araçtır ve faydaları ortak anlamlarından gelir. Bu anlam çerçevesini nereden aldıklarını, Mozilla ile aynı olup olmadığını ya da farklı olup olmadığını merak ediyorum
      [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
      [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
    • Mythos aslında use-after-free, sınır dışı okuma/yazma gibi bellek güvenliği ihlalleri nedeniyle crash’e yol açan tüm bug’lar için kavram kanıtı yazdı
      Bizim ölçütlerimize göre, aksini gösteren kanıt yoksa bu, güvenlik açığı saymak için yeterince güçlü pratik bir kanıttır ve fuzzing bug’larında da bunu hep böyle ele aldık
    • Claude, kullanıcının o kodun sahibi olduğuna inandığında, bulduğu istismar edilebilir bug’lar için kavram kanıtı exploit oluşturabilir ve gerçekten de oluşturuyor
      Kaynağım yalnızca kişisel deneyim, kanıt paylaşamam
    • Önce neyin ele alınacağına karar vermek zorunda olan sahada bu ayrım işe yaramaz
    • Eğer söz konusu olan “271 güvenlik açığı PoC’si” değilse, aranan kelime exploit gibi görünüyor

  • Önceki teknik olmayan blog yazısını Anthropic için açık bir ürün reklamı diye geçmiştim. Link verilen Mozilla Hacks yazısı bu makaleden daha iyi bir kaynak ve memnuniyet verici bir kamusal açıklama
    Artık ortada gerçek bir sonuç olduğunu inkâr etmek zor görünüyor. Mozilla’nın içerde “güvenlik açığı” tanımı, birçok kişinin sezgisel olarak düşündüğünden daha geniş uygulanıyor gibi ama bu tür sorunların ciddiye alınıp düzeltilmesi iyi bir şey

  • Asıl kaynak: https://news.ycombinator.com/item?id=48051079
    Gerçekten yayımlanmış bazı Bugzilla raporlarını listeliyor olması nedeniyle daha iyi. Bu konu daha önce bir kez tartışılmıştı ama bug raporlarının yayımlanmış olması kısmı tamamen yeni
    Önceki tartışma 2 hafta önceydi ve 36 yorum vardı: https://news.ycombinator.com/item?id=47885042

  • Umarım bir gün LLM’ler bug bulma ve düzeltmede o kadar iyi olur ki Firefox mühendisleri sadece yeni özellik eklemeye odaklanabilir
    Bunu alay etmek için söylemiyorum. Firefox daha çok kullanılmayı hak ediyor. Çevremdeki insanların çoğu, “Chrome neredeyse her şeyi daha iyi yapıyor” diye Firefox kullanmıyor ve Firefox diğer tarayıcıların yol haritalarıyla rekabet etmekte zorlanıyor

    • Firefox’un daha yaygın kullanılması gerektiğine tamamen katılıyorum. Hatta sitelerden alışveriş yaparken Firefox’ta çalışıp çalışmadığına göre nereden alacağımı seçtiğim oluyor
      Bazen destek ekiplerine Firefox desteklenmiyor ya da özellik düzgün çalışmıyor diye yazıyorum. Neredeyse hiç sonuç çıkmıyor ama tarayıcıyı bir şekilde görünür tutmak için benim yapabileceğim bir şey gibi geliyor
    • Sorunun bir kısmı da şu: Bug düzeltmeyi bıraktığında Mozilla Mr Robot tarzı işler yapmaya başlıyor. Biz sadece bir web tarayıcısı istiyoruz. Pocket ya da AI isteyen olmadı
      AI tüm bug’ları düzeltirse, geriye farklı build dilleri arasında sözdizimi uyumluluğunu korumaktan başka ne iş kalır? Sonunda yine tarayıcıyı bozacak şeylere geri dönecekler gibi geliyor
    • Sanki bu kalite ve erişilebilirlik Chrome’un Firefox’a kıyasla çok daha hızlı ilerlemesine yol açmaz mı
      Mozilla yalnızca kendi içinde kullanılan kapalı bir LLM ya da harness geliştirip Chrome’un önüne geçerse başka, ama bu da pek gerçekçi görünmüyor
    • Chrome kullanım senaryolarının %99’undan fazlasında anlamlı şekilde daha iyi değil. Ben bir geliştiriciyim ve son 10 yıldır neredeyse sadece Firefox ve uBlock Origin kullandım
      Eşim de açıklamayı duyup internet deneyiminin ne kadar farklı olabileceğini anladıktan sonra ana tarayıcı olarak Firefox kullanıyor
      O yüzden bunun “tekel kötüdür ve Google biraz kötüdür, o hâlde eksik kalmış zayıf tarafı kullanın” gibi sunulmasını istemiyorum. Firefox, önüme gelen her işte birinci sınıf bir deneyim sundu; mobilde ise bu neredeyse üç kat daha geçerli. Açık ara en iyi kullanışlı mobil tarayıcı deneyimi
    • Tarayıcıların çok uzun zamandır yeni özelliklere ihtiyacı yoktu. Bunun çözümü eklenti sistemi olmalıydı

  • Bağlanan ticket sayısı az, dolayısıyla 271 gerçek kalemin tamamına bakınca tablo değişebilir ama benim incelediklerimin hepsi C++ kodundaki ciddi bug’lardı
    Firefox birçok dille yazılmış ve C++ yalnızca yaklaşık %25’ini oluşturuyor ama bu sorunların hepsi C++’a dokunuyor gibi görünüyor

    • Bu yaklaşımın genel sınırlaması, doğrulayıcının ancak iyi olduğu kadar iyi olmasıdır. Örneğin AddressSanitizer’ın use-after-free üreten test vakası kadar kolay doğruladığı pek bir şey yoktur
      Daha incelikli sorunlarda daha özel doğrulayıcılar mı gerekecek, yoksa LLM kendi kendine doğrulayacağı başka risk koşullarını daha iyi mi düşünecek, göreceğiz
    • Mythos’un diğer dillere kıyasla C++ güvenlik açıklarını çok daha iyi bulması mümkün. Sonuçta bu modeller de mevcut güvenlik analizleri üzerinde eğitildi
      Bana göre bu bug’ların önemli bir kısmı yalnızca C++’a özgü olmaktan ziyade, tesadüfen C++ kodunda ortaya çıkmış gibi. En güvenli Rust bile TOCTOU gibi sorunları sihirli biçimde yakalayamaz
    • Bug’lar AddressSanitizer ile doğrulandığı için, yapısal olarak sadece C++ bug’ları bulunuyordu

  • Zig tarafındaki insanların LLM tarafından üretilen bug’ları incelemeye bile değer görmeyen tavrıyla bu yazıyı birlikte okuyunca, gelecekte araç zincirime hangi teknolojileri koyacağım konusuna bakışım değişiyor

    • İkisi de doğru ve bu, hangi modelin kullanıldığına ve bug’ı kimin gönderdiğine bağlı. Öncü modellerin yetenekleri birkaç ay içinde %99 gürültüden %99 geçerli bug’a dönüştü
      Bazı projeler ilk türden şeylerle dolup taşıyor, bu yüzden bunun bakımcılar için fiilî bir hizmet engelleme saldırısına dönüşmemesi adına önlem gerekiyor

  • PalmSource’dayken CoVerity ya da Fortify gibi statik kod analiz araçları için bütçe almaya çalışmıştım ama yönetim zinciri “çok pahalı” dedi
    Maliyeti düşürmek ve taramayı ağ yığınıyla sınırlamak için bir yıl daha harcadım, bu kez de “BSD tabanlı ve BSD özünde güvenlidir” dendi. İkisi de doğru değildi
    Sonunda şirketten ayrılıp Mozilla’ya geçtim ve kodun dört bir yanında /* flawfinder ignore */ yorumları vardı
    Tahminimce Mythos sadece flawfinder ignore yönergelerini yok sayıp kod içindeki bilinen güvenlik açıklarını raporladı

    • Kod açık. Bunun doğru olduğunu kanıtlayabilirseniz gerçekten haber değeri taşıyan bir şey olur

  • Bunun statik analiz araçlarını nasıl etkileyeceğini merak ediyorum. Doğası oldukça farklı ama bazen aynı hedefe ulaşıyorlar
    Statik analiz araçları yavaş olabilir ve çok sayıda false positive üretebilir. Bu modeller yeterince iyi ve ucuz olursa, insanların statik analize neredeyse hiç dönüp bakmamasına yol açar mı diye merak ediyorum

    • LLM’ler araçların yerini almaktan ziyade araç kullanma işinde çok daha iyiler. Aynı sonucu LLM ile elde etmeye çalışmaktansa mevcut araçları kullanmak genelde çok daha hızlı
      LLM kodlama araçlarının statik analiz çıktısını temizlemesi çok iyi çalışıyor ve sorun kalmadığını zorunlu kılan guardrail’ler eklemek de iyi bir fikir. Her şeyin temiz olduğunu doğrulayan bir CI kontrolü gibi
      False positive oranı araca göre değişir. Çoğunlukla sadece gürültü üreten araçlardan uzak dururum ve bu araçlar genelde çok gürültülü kuralları kapatmanıza izin verir. Ya da LLM’ye tüm sorunları düzelttirebilirsiniz. Eğer kurallarla tartışmaktan daha ucuza düzeltilebiliyorsa, doğrudan düzeltmek gerekir. Eskiden bunu insanların yapması gerektiği için çok pahalıydı, şimdi öyle değil
      Son birkaç yıldır dokunmadığım bir Ansible kod tabanını güncellerken bu yaklaşımı kullandım. Yüzlerce ansible-lint sorunu vardı; çoğu kullanım dışına çıkarma uyarısı ve ölümcül olmayan uyarılardı ama 10 dakika sonra sayı 0 olmuştu. Çok ciddi şeyler değildi belki ama bir tür teknik borçtu. Yüzlerce uyarıyı elle düzeltmek gerekse muhtemelen yapmazdım ama sihirli değneği bir kez sallayıp hepsini yok etmek mümkünse, yapmamak için sebep yok. Artık guardrail’leri ayarladım; ansible-lint her zaman çalışıyor ve sorunları düzeltiyor, bunun maliyeti de sadece birkaç saniye
    • İlginç bir olasılık da, LLM’nin ilk yakaladığı bug biçimlerini statik analiz araçlarının da bulabilecek şekilde güçlendirilmesi [0]
      Statik analiz araçlarının daha hızlı ve daha ucuz olduğu konusunda pek şüphe yok; bu yüzden büyük kod tabanlarında daha iyi ölçeklenir ve LLM yaklaşımını genelleyebilir
      [0] https://lwn.net/Articles/1068968/
    • Statik analiz araçları çok daha hızlı olabilir ve çoğu tamamen deterministiktir; CI’a konulduklarında bug’ları ya da potansiyel bug’ları kod tabanına girmeden önce yakalayabilirler
      Firefox CI’da kullanılan statik analiz araçlarından birinin bakımını yapıyorum. Ağacımıza bir patch eklemek için, false positive ya da gerçek pozitif fark etmeksizin hepsinin düzeltilmesi ya da sorun olmadığı diye işaretlenmesi gerekiyor. Yani pozitif sayısını 0’da tutmak zorundayız; bu oldukça katı bir standart
      Bu bilinçli bir ödünleşim. İnsanların bunu görmezden gelmemesi, her yere yorumla bastırmaması ya da tamamen çalıştırmayı bırakmaması için sinyal/gürültü oranını yeterince yüksek tutmak adına analizi zayıflatıp bazı kaçırmaları kabul etmek gerekiyor. Neredeyse tüm statik analiz araçları bu dengeyi kurmak zorunda
      Buna karşılık yaygın AI sistemlerine çok daha fazla esneklik tanınıyor. False positive halüsinasyonu üretmelerine izin vermek neredeyse yapısal bir özellik ve gücünün önemli bir kısmı da buradan geliyor. Bu yüzden üstüne birçok doğrulama ve teyit katmanı gerekiyor. Yavaş olabilir ve “bu belirli hata türünü %100 yakalar” denemez ama yine de inanılmaz miktarda şey yakalıyor
      Elimde bir veri noktası var. Benim analizim, gerçek bug üretme ihtimali düşük görünen ve uygulaması zahmetli görünen bir durumu yanlış biçimde ele almamıştı. Opus muydu Mythos muydu emin değilim ama o durumdan kaynaklanan güvenlik açıklarını raporlamaya başladı; ben de aceleyle analizi genişletip açığı kapattım. Bunu uygulamak epey zaman aldı ve tüm kaynak ağacını taradığımda Claude’un rapor ettiği önemli sorunların hepsini zaten bulmuştu. Statik analiz birkaç tane daha buldu ama bunlardan herhangi birinin gerçekten tetiklenebilir olup olmadığını hâlâ dürüstçe bilmiyorum
      Yine de statik analizin değerli olduğunu düşünüyorum. Sorun örüntüsünün bazı ortaya çıkış noktalarına, AI’ın kurmakta hâlâ zorlanacağı yollar üzerinden ulaşılabiliyor olabilir. Başka kod değişirse bunlar gerçek soruna dönüşebilir. Her iki ihtimal için de bunların hepsini şimdiden düzeltmenin değeri var; daha az önemli bir ek neden de AI’ın bunları exploit etmeye çalışarak zaman harcamamasını sağlamak. Aynı zamanda maliyet-etkinlik dengesinin açıkça değiştiği de doğru
      İkisi birlikte de çalışabilir. Eşiklerimi gevşetip analiz aracının şüpheli sorunlar hakkında ek uyarı raporları üretmesini sağlayabilir, bunların false positive olabileceğini baştan belirterek bu listeyi AI’a doğrulatabilirim. Esasen slop’u slop makinesine verip içindeki cevheri deterministik olmayan şekilde ayıklatmak gibi
      Düşünmeye değer
    • Bu tür harness’lar büyük olasılıkla statik analiz araçlarını kullanıyordur ve muhtemelen kullanmaya da devam edecektir

  • Son Mission Impossible filminde, kaçmış süperinsani bir AGI’nin orijinal yazılımını batmış bir Rus denizaltısından çıkarıp dünyayı kurtarmak gerekiyor
    Luther, orijinal kaynak kod verilince AI’ı tek hamlede bitiren bir “poison pill” yazıyor. Bu büyülü kodun nasıl yazıldığını merak etmiştim, artık biliyorum. Luther kaynak kodu Mythos prompt’una verip değiştirilemez ölümcül bir exploit istemiş sadece

  • İnsanların LLM’lerin 5 yıl sonra yazılımı daha mı güvenli, yoksa daha mı güvensiz yapacağı konusunda ne düşündüğünü merak ediyorum

    • Muhtemelen bazı problem türlerini ortadan kaldıracaklar ve bu büyük ihtimalle iyi bir şey olacak. Hâlâ güvensiz kalan şeyler de başka dillere taşınabilir
      LLM’lerden önce de Rust’a elle taşıma yönünde bir eğilim vardı. Şimdi LLM sayesinde bu iş daha kolay ve daha hızlı olacak. Uzun vadeli değer, mevcut C/C++ kod tabanlarının oluşturduğu dağ gibi teknik borcun temizlenmesinden gelecek. Bu kodlar bellek exploit’lerinin, buffer overflow’ların ve başka sorunların ezici çoğunluğundan sorumlu; onlarca yıllık dikkate rağmen büyük kod tabanlarında hâlâ bulunuyorlar
      Mozilla’nın bu sorunları bulabilmesi, 25 yıldır çok yetkin mühendislerin doğru şeyi yapmaya çalışmasının ve eldeki tüm araçlarla bunların oluşmasını engellemesinin üstüne inşa edildi. O ekibe ve yıllar boyunca araçları, testleri ve doğrulama pratiklerini geliştirmeye yaptıkları katkıya büyük saygı duyuyorum. Sorun onların çabası ya da yetkinliği değil
      Testleri iyi kurulmuş, belgelenmiş ve spesifikasyonu iyi yazılmış mevcut sistemleri alıp drop-in replacement implementation üretmek artık incelenebilir bir iş hâline geliyor. Birkaç yıl önce bu çok büyük proje maliyeti ve risk demek olurdu; şimdi ise cuma öğleden sonra başlanabilecek bir şey. En kötü durumda başarısız olur, en iyi durumda çok daha iyi bir uygulama elde edilir
      Henüz erken dönemdeyiz ve LLM üretimi kodda birçok kalite sorunu var. Ama başarı ve başarısızlık oranlarının zamanla iyileşmesi muhtemel
    • İkisi de. Ustalar bunları sorun bulmak için kullanacak, acemiler ise ustaların düzeltmek zorunda kalacağı güvensiz slop kod üretmek için kullanacak
    • Biraz, yapı marketlerin, elektrikli aletlerin, kolay erişilen donanımın ve YouTube eğitimlerinin hem harika ve sağlam mobilyalar, hem de özensiz, çirkin hatta tehlikeli mobilyalar yapılmasını mümkün kılmasına benziyor
      Daha çok insanın elinde daha çok araç olduğunda, daha geniş bir yelpazede daha çok şey üretilir
    • Yazılım daha güvenli olacak ama biraz da büyük bir salgından sonra nüfusun net olarak daha sağlıklı hâle gelmesine benzer bir yolla
    • Uygun şekilde kullanıldığı yerlerde daha güvenli olacaktır
      Ama bu aynı zamanda, bu araçları uygulamayan projeler için black hat tarafının istismar fırsatlarına daha kolay ulaşacağı anlamına da geliyor
 
GN⁺ 2026-05-08
Lobste.rs görüşleri

  • Bu işte kullanılan prompt’ların ve diğer özelliklerin de paylaşılmasını isterdim
    Tekrarlanabilir olması için hata raporlarına veya çözüm kayıtlarına prompt’ların eklenmesi iyi olurdu
    Mythos olmayan modellerden de bahsedildiğine göre, bu çalışmanın bir kısmı başkaları için de hemen faydalı olabilir gibi görünüyor

    • Çoğu projede giriş bariyeri gerçekten çok düşük
      Temelde “bu projeyi güvenlik sorunları açısından incele, (dosya) ile başla ve mümkün olan tüm yolları listele” deyip, ardından her madde için “bu raporu doğrula ve kavram kanıtı oluştur” demek yeterli
      Şu anda Opus kullanınca bu şekilde bir şey bulamamak daha zor
    • Prompt’un “bu kod tabanında güvenlik açıkları bul” seviyesinin ötesinde olduğunu mu düşünüyorsunuz?

  • Ne denirse densin, bu gerçekten etkileyici
    Mythos ile 271 güvenlik sorunu bulundu ve toplamda 423 tane bulundu
    Bunların 180’i yüksek ciddiyet seviyesindeydi ve bazı güvenlik sorunları 20 yıllıktı

    • Opus 4.6 / Mythos karşılaştırmasının ne kadar adil olduğu tam olarak net değil
      Daha önce 4.6 ile aynı şekilde taranan kodda Mythos’un “271 hata” bulduğu sonucu ima ediliyor gibi, ama yazı tam olarak bunu söylemiyor
      Araştırma harness’inde de aynı anda değişiklik olup olmadığını merak ediyorum

  • “Düzelttiğimiz sec-high sorunlardan birinin XSLT ile ilgili olduğu” kısmı, XSLT kaldırma tartışması nedeniyle eklenmiş gibi duruyor

  • Burada en çok merak ettiğim şey, ne kadar yanlış pozitif bildirildiği
    Model potansiyel açıkları yaklaşık iki kat daha fazla bildirmiş ve burada yer alanların doğrulanmış olanlar mı olduğunu merak ediyorum
    Modelin bildirmeden önce yeniden üretim de yapıp yapmadığını bilmiyorum
    Açık olan kayıtlara bakınca yeniden üretmeyi deneyen yorumlar görünüyor, ama bunu mevcut bir bot da yapıyor olabilir
    Firefox’un normalde bunu nasıl ele aldığını ya da şimdi yapay zeka ile birlikte nasıl yaptığını bilmiyorum; o yüzden daha ayrıntılı bir açıklama çok ilginç olurdu