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

• 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
• 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ı

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
• 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
  • 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

[GN⁺]

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