Chrome, WebP yığın arabellek taşması açığını düzeltti

 (chromereleases.googleblog.com)
1 puan yazan GN⁺ 2023-09-13 | 1 yorum | WhatsApp'ta paylaş
  • Masaüstü Chrome Stable ve Extended Stable kanal güncellemeleri, WebP yığın arabellek taşması açığına yönelik düzeltmeyi içerecek şekilde yayımlandı
  • Yeni derlemeler Mac ve Linux’ta 116.0.5845.187, Windows’ta 116.0.5845.187/.188; birkaç günden birkaç haftaya yayılan kademeli bir dağıtımla uygulanacak
  • Bu sürümde 1 güvenlik düzeltmesi bulunuyor ve CVE-2023-4863 Critical olarak sınıflandırılıyor
  • Açık, Apple SEAR ve University of Toronto Munk School’dan The Citizen Lab tarafından 6 Eylül 2023’te bildirildi
  • Google, gerçek dünyada istismar örneklerinin bulunduğunu belirtti; düzeltme sürümü uygulanana kadar hata ayrıntılarına erişim kısıtlanabilir

Masaüstü Chrome kanalı güncellemesi

  • Stable ve Extended Stable kanalları, masaüstü için yeni derlemelere güncellendi
  • Platformlara göre Stable kanal sürümleri şöyle
    • Mac: 116.0.5845.187
    • Linux: 116.0.5845.187
    • Windows: 116.0.5845.187/.188
  • Extended Stable kanalı da ayrı sürümlerle dağıtılıyor
    • Windows: 116.0.5845.188
    • Mac: 116.0.5845.187
  • Güncelleme birkaç günden birkaç haftaya yayılan kademeli bir dağıtımla sunulacak
  • Bu derlemedeki değişikliklerin tam listesi log üzerinden görülebilir

Güvenlik düzeltmesi: CVE-2023-4863

  • Bu sürümde 1 güvenlik düzeltmesi yer alıyor
  • Harici bir araştırmacının katkı verdiği başlıca düzeltme aşağıdaki açıkla ilgili
    • Critical CVE-2023-4863: WebP’de yığın arabellek taşması
    • Hata numarası: 1479274
    • Bildiren: Apple Security Engineering and Architecture(SEAR), University of Toronto Munk School’dan The Citizen Lab
    • Bildirim tarihi: 6 Eylül 2023
    • Ödül tutarı: $NA

Gerçek dünyada istismar ve bilgi açıklama kısıtlaması

  • Google, CVE-2023-4863 exploit’inin gerçek ortamda mevcut olduğunu açıkladı
  • Hata ayrıntılarına ve bağlantılara erişim, kullanıcıların büyük çoğunluğu düzeltilmiş sürüme güncellenene kadar kısıtlanabilir
  • Aynı hata, başka projelerin de bağımlı olduğu bir üçüncü taraf kütüphanede bulunuyor ve henüz düzeltilmemişse kısıtlama sürdürülebilir

Güvenlik hatası tespiti ve bildirim kanalları

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-13
Hacker News yorumları

  • Google Chrome’da WebP görselleri renderer process içinde decode edildiği için, exploit başarılı olsa bile en fazla sandbox içindeki renderer kodunun çalıştırılması mümkün olur
    Renderer çok karmaşık olduğundan her yıl çok sayıda exploit bulunuyor; ancak renderer’da kod çalıştırma elde edilse bile normal bir web sayfasının sahip olduğu yetkilerin çok ötesine geçilemiyor
    Özellikle yerel dosya sistemindeki dosyaları göremez ya da bırakamaz, başka domain’lerin cookie’lerini de okuyamaz

    • Elbette bununla birleştirilecek bir sandbox kaçış exploit’i varsa durum değişir
      Hemen en yüksek öncelik olmayabilir, ama böyle bir exploit halihazırda gerçek ortamda dolaşmıyorsa, çok rahatsız etmeyecek bir zamanda mümkün olduğunca hızlı patch’lenmeli
    • Modern internette kullanıcıların yüklediği inanılmaz miktarda görsel var; bu yüzden tek bir web sitesinin kullanıcı bağlamındaki yetkileri elde etmek bile yeterince büyük bir mesele
      Tek bir siteye ya da frontend’e bağlı olmaması açısından güçlendirilmiş XSS’e daha yakın
    • Lossless WebP kullanıyorum ve PNG’den çok daha verimli
      Ah, yanlış thread’e yazmışım; https://news.ycombinator.com/item?id=37479576 adresindeki “jpeg is good enough” ifadesine yanıt verecektim
    • Bu, renderer’ın web sitesine geri bilgi gönderemeyeceği anlamına mı geliyor?
      Ayrıca JavaScript’i kapatmış olsanız bile web sitesinin bir anda hâlâ kod çalıştırabilir hale gelmesi söz konusu değil mi?

  • Bu yüzden tarayıcı geliştiricilerinin yeni formatları benimsemekte yavaş davranmasına daha çok hak veriyorum
    WebP’nin JPEG’e göre avantajı çok büyük değil; esas olarak şeffaflık gibi konularda, onda da başarısı sınırlı kaldı
    Ama şimdi birden fazla yüksek öncelikli güvenlik açığına yol açtı ve libwebp’ye link’lenen her yerde önümüzdeki bir ay boyunca patch dağıtılması gerekecek
    Yeni şeyler yapmayalım demiyorum, ama geliştiricilerin maliyeti epey ciddi biçimde küçümsediğini düşünüyorum

    • Firefox’ta tüm process’e değil, tekil kütüphanelere uygulanabilen ek bir sandbox katmanı var: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
    • Adil olmak gerekirse geçmişte JPEG decoding kütüphanelerindeki sorunlar da kötü amaçlı yazılım dağıtım yolu olarak kullanılmıştı
      WebP ekosisteminin çok daha az olgun olduğu doğru, ama daha eski format işleme kodlarında da epey güvenlik sorunu olduğundan eminim
      Yine de mantık geçerli. Daha birkaç hafta önce internet kullanıcıları JPEG XL’in mümkün olduğunca hızlı benimsenmesi gerektiğini, bunun için tarayıcı geliştiricilerinin “referans decoder kodunu codebase’e dahil etmesinin” “neredeyse hiç maliyeti olmadığını” savunuyordu
    • Tarayıcılar yeni formatı benimsememiş olsaydı bu bug bulunur muydu?
      Diğer görsel formatları ve kütüphaneleri de muhtemelen bug dolu, ama büyük yazılımlarda kullanılmadıkları için kimse umursamıyor
      Özellikle bu tür bug’ları bulup istismar edebilecek kişiler için harcanan zamana karşılık getirisi kötü olduğu için
      Uzun süre kullanılmaması bug sayısını azaltmaz
    • Güvenlik açığının nedeni yeni görsel formatı değil, C/C++’ın bellek güvenliği eksikliği
      Görsel encoder ve decoder’lar ile diğer encoder/decoder’lar güvenli olmayan dilleri kullanmazsa bu tür bug’ların ortaya çıkma olasılığı azalır
    • WebP, JPEG’den çok daha karmaşık bir format ve karmaşıklık kusur yoğunluğuyla neredeyse doğrudan ilişkili
      Bundan ayrı olarak, kodu gerekenden fazla karmaşık hale getiren kültürün ve ayrıntıları doğru dürüst anlamayan geliştiricilerin de sorun olduğunu düşünüyorum

  • Bu düzeltme bugünkü Firefox 117.0.1 ve Fenix 117.1.0 sürümlerine dahil edildi: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

  • Not olarak, image crate içinde güvenli Rust ile yazılmış bir WebP decoder implementasyonu var: https://github.com/image-rs/image
    Uzun süre epey eksikti, ama geçen yıl birçok WebP özelliği implemente edildi
    Chromium’un artık Rust bağımlılıklarının kullanımına izin veren bir politikası olduğuna göre Chromium da bunu benimsemeye başlayamaz mı?

    • Chrome’da “yavaş olabilse de XYZ kütüphanesinin güvenli sürümünü kullan” gibi bir flag olsaydı, performans kaybını göze alıp hemen açardım
    • 2023’te bile web tarayıcısı gibi attack surface’i devasa olan bir hedefte yeni C/C++ kodu yazılmaya devam edilmesi bana akıl almaz geliyor

  • Soruna yol açan asıl commit: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...
    Bu hatayı düzelten commit: https://github.com/webmproject/libwebp/commit/902bc919033134...
    Asıl commit, Huffman decoder’ını optimize ediyordu. Bu decoder, iyi bilinen bir optimizasyon kullanarak N biti önceden okur; gerçekte kaç bit tüketmesi gerektiğine ve hangi sembolü decode etmesi gerektiğine karar verir. Ya da bu, birden fazla sembolün N bitlik önekiyse, kalan bitler için hangi tabloya bakılması gerektiğini belirler.
    Eski sürüm kısa semboller için lookup table kullanıyordu, ancak uzun semboller için grafik dolaşımı gerekiyordu. Yeni sürüm bunu bir lookup table dizisi kullanarak iyileştirdi. Her öğe (nbits, value) içerir; nbits tüketilecek bit sayısıdır, value ise genellikle semboldür. Ancak nbits N’i aşarsa, value tablo indeksi olarak yorumlanır ve nbits o alt ağaçtaki en uzun kod uzunluğu olarak yeniden yorumlanır. Bu yüzden takip eden her tablo 2^(nbits - N) öğeye sahip olmalıdır. Kök tablo her zaman 2^N öğe olarak sabittir.
    Yeni sürüm, sembol sayısına göre azami öğe sayısını (kTableSize) hesaplıyordu. Doğal olarak Huffman ağacı güvenilmeyen girdiden gelir ve nbits’in çok büyüdüğü durumlar kolayca hayal edilebilir. VP8 Lossless özellikle en fazla 15 bite izin verdiğinden, tüm LUT’ler ayrı ayrı yardımcı tablolara eşlenirse mümkün olan en büyük tablo 2^N + 2^15 öğe olur. Bunu oluşturmak için de çok fazla sembol gerekmez; her tablo için 16-N sembol yeterlidir.
    İlginç biçimde kodun kendisinde yalnızca tablo boyutunu hesaplayan bir mod vardı (root_table == NULL ile VP8LBuildHuffmanTable çağrısı), ama nedense kullanılmıyordu ve sabit bir maksimum boyut varsayılıyordu. Bu yüzden Huffman ağacı öğe sayısını maksimize edecek şekilde oluşturulduğunda ayrılan alanın dışına yazıyordu.
    Bunun neden olduğunu anlamak mümkün. Huffman decode aşaması, pek çok sıkıştırma formatında hesaplama maliyeti en yüksek kısımlardan biridir; küçük iyileştirmeler bile önemlidir. Yukarıdaki optimizasyon iyi bilinir, ancak uzun kod yollarının genelde nadir olduğu düşünülür ve optimizasyon önceliği düşüktür. Asıl commit mesajı bu varsayımı çürütüyordu ve bu yüzden merge edilebildi. Bellek güvenli bir dilin bu sorunu önleyip önlemeyeceğinden emin olmak zor. Çünkü nadiren de olsa burada taşma kontrollerinden özellikle kaçınmak isteyebileceğiniz bir durum söz konusu.
    [1] Ancak bellek bozulması sıkı döngüde değil, tablo oluşturma sırasında gerçekleştiği için kısmi taşma kontrolleri büyük fayda sağlayabilirdi. Gerçek düzeltme ReadSymbol fonksiyonunu hiç değiştirmedi. Yine de sıkı döngünün güvenliği gerekçelendirilmelidir; yanlış bir gerekçe her şeyi mahvedebilir.

    • Bu bileşen WUFFS ile yazılmalıydı.
      Sınır kontrolüne gerek olmadığı söyleniyorsa sorun yok. WUFFS çalışma zamanında sınır kontrolü üretmez.
      Ancak bu örnekte olduğu gibi yazılım sınırların dışına çıkıp hatalıysa, WUFFS’ta derlenmez.
      “Bu imkânsız” diye düşünebilirsiniz; WUFFS genel amaçlı bir programlama dili olsaydı haklı olurdunuz. Rice teoremine göre önemsiz olmayan anlamsal özellikler karar verilemezdir.
      Neyse ki WUFFS genel amaçlı bir dil değil. Çoğu yazılım WUFFS ile yazılamaz, ama görüntü codec’leri yazılabilir.
    • C programcısı olarak çalışmayalı 10 yıldan fazla oldu ve zaten çok iyi de değildim, ancak açıklamaya bakınca sınır kontrolünün sorunu yakalayacağına katılıyorum.
      Yine de bu tür sorunları yakalayan otomatik testlerin yazılıp yazılamayacağını merak ediyorum.
      Kendi uğraştığım kodlarda bazı hesaplamaları ayrı fonksiyonlara çıkarıp bağımsız test edebiliyorum. Burada performans nedeniyle zor olmuş olabilir, ama emin değilim.

  • BuildHuffmanTable içindeki sınır dışı yazma düzeltmesi
    https://github.com/webmproject/libwebp/commit/902bc919033134...

  • Apple tarafından bildirilmiş gibi görünüyor ve şu güvenlik güncellemesine çok benziyor: https://support.apple.com/en-us/HT213906

    • Apple ve “UoT Munk School’daki Citizen Lab” tarafından bildirildi; bağlantısı verilen sayfada aynen böyle yazıyor.
      Bu yüzden oldukça olası görünüyor. Apple, dahili olarak ImageIO içinde libwebp kullanıyor olabilir ya da benzer bir hata yapmış olabilir.
    • Geçen haftaki tepkiyle şimdiki tepkinin ne kadar farklı olduğunu görmek ilginç.

  • Görüntü codec’lerinin uzun bir güvenlik açığı geçmişi var.
    Gerçek görüntü işleme, bellek güvenli FORTRAN IV ile bile yazılabilecek kadar temiz doğrusal kod olabilir; ancak sıkıştırma devreye girince değişken uzunluklu veri yapıları, pointer takibi vb. çoğalır.
    Buna hızlı çalışması gerektiği baskısı da eklenir.

  • Bu Electron’ı da etkiliyor mu? Öyleyse hangi sürüm?

  • Bunu gerçekçi olarak istismar etmenin bir yolu var mı?
    Duyduğuma göre 64 bitte heap spraying artık pratik değilmiş
    Bellekte üzerine yazılabilecek, öngörülebilir bir nesne mi var?

    • Vahşi ortamda zaten istismar edildiğine göre cevap evet
      64 bitte bile kernel exploit’lerde heap spraying hâlâ kesinlikle kullanılıyor. V8 exploit’lerinde insanların hangi ilkel işlemleri kullandığını pek bilmiyorum