WebP 0day analizi

 (blog.isosceles.com)
2 puan yazan GN⁺ 2023-09-23 | 1 yorum | WhatsApp'ta paylaş
  • Chrome kararlı güncellemesine dahil edilen tek güvenlik düzeltmesi CVE-2023-4863, WebP görüntü kütüphanesinde bir heap buffer overflow açığıdır ve Google, bunun gerçek ortamlarda çalışan bir exploit’inin zaten bulunduğunu açıkladı
  • Apple SEAR’ın 6 Eylül 2023 tarihli bildirimi, Apple’ın CVE-2023-41064 kaydı ve Citizen Lab’in BLASTPASS bulguları bir araya geldiğinde, bunun büyük olasılıkla aynı hata olduğu görülüyor
  • Açığın, WebP kayıpsız sıkıştırma biçimi VP8L’de Huffman tablosu oluşturma sürecinde önceden hesaplanan buffer boyutunu aşan yazmaya izin veren bir sorun olduğu analiz edildi
  • Bunun sıradan fuzzing ile kolay yakalanamamasının nedeni, art arda birden çok en büyük boyutlu Huffman tablosu ve belirli bir geçersiz tablonun oluşturulmasını gerektiren zor tetikleme koşulları
  • Upstream libwebp yaması yeterli görünüyor, ancak libwebp tarayıcılarda, işletim sistemlerinde ve uygulamalarda yaygın kullanıldığı için yamanın yayılması ve sandboxing kritik önem taşıyor

Chrome yamasının BLASTPASS ile bağlantılı görünmesinin nedeni

  • Google, 2023 Eylül başındaki Chrome kararlı güncellemesinde Apple Security Engineering and Architecture (SEAR) tarafından bildirilen CVE-2023-4863 açığını düzeltti
    • Açık, WebP görüntü kütüphanesinde bir heap buffer overflow’dur
    • Google, “CVE-2023-4863 exploit’inin gerçek ortamlarda bulunduğunu” bildiğini açıkladı
  • Aynı dönemde Citizen Lab, Washington DC merkezli bir sivil toplum kuruluşuna bağlı bir kişinin iPhone’unda şüpheli davranış tespit etti
    • BLASTPASS, iMessage zero-click zero-day exploit’i üzerinden NSO Group’un Pegasus casus yazılımının dağıtıldığı bir vakayla ilişkilendirildi
    • Citizen Lab teknik analiz sonuçlarını Apple’a ilettikten sonra Apple, 7 Eylül’deki güvenlik duyurusunda iki CVE yayımladı
  • Apple’ın ilk CVE’si CVE-2023-41061, PassKit ek dosyasına bir görüntü exploit’i yerleştirerek iMessage’in BlastDoor sandbox’ını atlama izleriyle örtüşüyor
    • Kötü amaçlı görüntü büyük olasılıkla sandbox’sız başka bir süreçte işlendi
  • İkinci CVE olan CVE-2023-41064, Apple ImageIO’da bir buffer overflow açığıdır
    • ImageIO, çeşitli görüntü biçimlerini tanımlayıp uygun decoder’a bağlayan Apple görüntü ayrıştırma framework’üdür
    • Teknik ayrıntılar verilmediği için CVE-2023-41064’ün hangi görüntü biçimini etkilediği doğrulanamıyor
  • Apple’ın yakın zamanda ImageIO’ya WebP desteği eklemesi, Apple güvenlik ekibinin 6 Eylül’de Chrome’a WebP açığını bildirmesi ve Google’ın 5 gün içinde acil yama çıkarıp bunu gerçek saldırılarda kullanılmış olarak işaretlemesi nedeniyle BLASTPASS ile CVE-2023-4863’ün aynı hata olma olasılığı yüksek görünüyor

libwebp yamasının işaret ettiği açık noktası

  • Chrome güvenlik duyurusundaki hata kimliği ile libwebp açık kaynak commit’i karşılaştırıldığında, Fix OOB write in BuildHuffmanTable yamasının CVE-2023-4863’e karşılık geldiği görülüyor
    • Yama, Apple bildiriminden bir gün sonra, 7 Eylül 2023’te oluşturuldu
  • Açık, WebP’nin kayıpsız sıkıştırma desteği olan VP8L içinde bulunuyor
    • WebP kayıpsız sıkıştırma, pikselleri %100 doğrulukla depolayıp geri yüklemek için Huffman coding kullanır
    • Modern uygulama, kavramsal ağaç yapısı yerine tablo kullanarak decoding’i optimize eder
  • Savunmasız sürüm, sabit tablolardan alınan önceden hesaplanmış buffer boyutu ile bellek ayırdıktan sonra Huffman tablosunu doğrudan bu alanda kuruyordu
    • Yeni sürümde ilk geçiş, çıktı tablosu için gereken toplam boyutu hesaplıyor ancak gerçek yazma işlemi yapmıyor
    • Toplam boyut önceden hesaplanan buffer’dan büyükse daha büyük bir allocation oluşturulacak şekilde değiştirildi
  • Temel akış, src/dec/vp8l_dec.c içindeki ReadHuffmanCodes fonksiyonunda ayrılan huffman_tables ile ReadHuffmanCode içindeki VP8LBuildHuffmanTable/BuildHuffmanTable çağrılarıdır
    • Huffman tabloları, farklı alfabet boyutlarına sahip 5 segmente ayrılır
    • Overflow oluşturmak için bu 5 tablonun tamamının hassas biçimde kurgulanması gerekir

Tetikleyici dosyanın oluşturulma süreci

  • WebP kayıpsız sıkıştırma, giriş piksellerinin frekans analizine göre sık görülen değerlere kısa bit dizileri, seyrek görülenlere uzun bit dizileri atar
    • Decoder’ın bit dizisi uzunluklarını her zaman ayırt edebilmesi için kodlar buna göre oluşturulur
    • Sıkıştırılmış görüntü, kodlarla değerler arasındaki eşlemeyi yeniden kurmak için istatistiksel bilgi ve kod atama bilgisi içermelidir
  • WebP, Huffman tablosunun kendisini de dosya boyutunu küçültmek için Huffman coding ile sıkıştırır
    • Bu yapı, açığın analiz ve tetikleme sürecini daha da karmaşık hale getirir
  • @mistymntncop, rastgele Huffman coding verisi yani code lengths içeren geçerli biçimde bir WebP üretmek için harness kodu sağladı
    • Bu harness ile hedef BuildHuffmanTable çağrısına rastgele code_lengths dizileri verilebildi
  • Elle yapılan deneylerde, BuildHuffmanTable içindeki histogram, num_open, num_nodes ve ReplicateValue için başlangıç konumunu izleyen key değeri arasındaki etkileşim son derece karmaşıktı
    • count[0] ile count[8] arasındaki root table, total_size üzerinde doğrudan büyük etki yaratmasa da sonraki iç durumu değiştirebilir
    • count[9] ile count[15] arasındaki second level tables, nihai total_size üzerinde doğrudan etkilidir
  • Mark Adler’in enough.c aracı, alfabet boyutu, root table boyutu ve azami kod uzunluğu için mümkün olan en büyük Huffman tree lookup table histogramını üretir
    • Yorumlara göre libwebp’deki kTableSize bu araçla hesaplanan değerlerden alınmıştır
    • Bu araçla önceden hesaplanan buffer boyutu yeniden üretilebildi ve @mistymntncop aracının, “enough” tarafından üretilen code lengths ile huffman_tables allocation’ını %100 doldurduğu da doğrulandı

Gerçek overflow’un oluştuğu koşullar

  • enough aracı, geçerli ve tam kodlar için azami değeri hesaplar
    • Küçük tablolardan biri olan sembol boyutu 40, root table 8 bit ve azami kod uzunluğu 15 için azami boyut 410’dur
    • BuildHuffmanTable tarafından geçerli kabul edilen kodlar arasında 410’dan büyük boyut üreten bir örnek bulunamadı
  • Overflow, yalnızca geçerli Huffman ağaçlarıyla değil, son aşamada geçersiz bir Huffman ağacı eklendiğinde ortaya çıkar
    • Önce 4 geçerli Huffman ağacıyla azami boyutta çıktı tablosu oluşturulur
    • Son tabloya geçersiz bir Huffman ağacı konduğunda, nihai tutarlılık kontrolünden önce ReplicateValue sınır dışına yazabilir
  • Yeniden üretim için savunmasız libwebp commit’i 7ba44f80f3b94fc0138db159afea770ef06532a0 checkout edilip AddressSanitizer etkinleştirildikten sonra, @mistymntncopun PoC koduyla bad.webp üretiliyor ve bu dosya dwebp ile decode ediliyor
    • AddressSanitizer, BuildHuffmanTable içinde heap-buffer-overflow raporluyor
    • Raporlanan yazma işlemi, 11816 baytlık bölgenin hemen arkasındaki adreste gerçekleşiyor
  • huffman_tables üzerinde overflow yaratan birden fazla giriş mevcut
    • Bulunan code lengths örnekleri arasında, huffman_tables allocation sonundan 400 bayt sonrasına kadar yazan vakalar var
    • Yazılan değerler üzerindeki kontrol kısmi olsa da exploit mümkün görünüyor
  • Geçersiz girdideki Huffman ağacı kısmen dengesizdir ve dengesiz dalın bir bölümünde çocuğu olmayan çok sayıda iç düğüm bulunur
    • Bu yapı, geçerli bir ağaçla erişilemeyecek key indeksleri oluşturur

Yamanın overflow’u engelleme biçimi

  • İlk bakışta yama, heap overflow’u önlemek için buffer’ı gereken boyuta göre dinamik olarak büyütüyormuş gibi görünüyordu
  • Gerçekte yamalı sürümün ilk geçişi BuildHuffmanTable çalıştırarak gereken toplam boyutu hesaplıyor ancak tabloya yazmıyor
    • Overflow’a neden olan geçersiz girdi için BuildHuffmanTable, bu ilk geçişte başarısız olup 0 döndürüyor
    • İlk geçiş yazma yapmadığından, geçersiz ağaç kısmen işlense bile sınır dışı yazma oluşmuyor
  • Aynı overflow’u tetikleyen geçerli ve tam kod örneği bulunamadığı için bu yama yeterli görünüyor

Fuzzing’in bunu yakalamasının neden zor olduğu

  • libwebp uzun süredir Google OSS-Fuzz içinde fuzz ediliyordu ve WebP kayıpsız desteği de kapsamlı biçimde fuzzing’e tabi tutuluyordu
  • Temel zorluk hem formatın hem de tetikleme koşullarının karmaşık olması
    • Milyarlarca olasılık arasından önce alfabet boyutları 280 ve 256 için azami boyutta 4 Huffman tablosu kurulması gerekiyor
    • Ardından alfabet boyutu 40 için çok belirli bir biçimde geçersiz bir Huffman tablosu oluşturulmalı
    • Herhangi bir adımda tek bir bit bile yanlış olursa görüntü decoder’ı hata verip güvenli şekilde sonlanır
  • Google, WebP 0day düzeltmesinden sonra WebP Huffman rutinlerine özel yeni bir fuzzer yayımladı
    • Bu fuzzer çalıştırıldığında da CVE-2023-4863 bulunamadı
  • Standart bit-flip mutasyonları, code coverage geri bildirim döngüsü ve AFL++’ın CmpLog gibi girdi-durum temelli yaklaşımlar da bu uç duruma giderken gerekli ara adımları geçmekte zorlanıyor
    • Quarkslab’ın TritonDSE gibi dinamik sembolik yürütme teknikleri işe yarayabilir, ancak bu doğrulanmış değil
  • Bu durum FreeType’taki Load_SBit_Png açığıyla aynı karakterde değil
    • Load_SBit_Png, fuzzing harness’inin API kullanım biçimini yeterince yansıtmaması nedeniyle bulunamamıştı
    • CVE-2023-4863 ise harness eksikliğinden çok, açığın kendi kısıtları nedeniyle fuzzing’in zorlaştığı bir örneğe daha yakın

Etki alanı ve müdahale durumu

  • Citizen Lab, gerçek ortamda kullanılan gelişmiş bir exploit yakaladı ve Apple ile Chrome birkaç gün içinde milyarlarca kullanıcıya güncelleme dağıtmış görünüyor
  • Android o sırada hâlâ etkilenme ihtimali taşıyordu
    • Android’in BitmapFactory bileşeni, Apple ImageIO gibi görüntü decoding işlemini yürütür ve libwebp desteği sağlar
    • O tarihte Android güvenlik duyurusunda CVE-2023-4863 düzeltmesi yer almıyordu, ancak düzeltme AOSP’ye merge edilmişti
    • Android etkileniyorsa bu durum Signal veya WhatsApp gibi uygulamalarda uzaktan exploit’e yol açabilir
    • Düzeltmenin Ekim güvenlik bülteninde gelmesi bekleniyordu
  • Upstream libwebp yaması doğru uygulanmış görünüyor ve gerekli yerlere yayılıyor
  • libwebp çok geniş kullanım alanına sahip olduğu için yamanın her yere yeterince ulaşması zaman alabilir
  • Görüntü decoding gibi zero-click uzaktan exploit saldırı yüzeyine yakın karmaşık parser kodlarında, yalnızca fuzzing ile güvenliği garanti etmek zor; proaktif kaynak kod incelemesi ve uygun sandboxing yatırımı gerekiyor

Teknik bilgi paylaşımındaki asimetri

  • Üreticiler teknik ayrıntıları yeterince paylaşmadığında savunma ekiplerinin açığın etkisini doğrulaması zorlaşıyor
  • Saldırganlar N-day açıkları izleyip exploit etmeye güçlü biçimde motive olduklarından, ayrıntılar yayımlanmasa da genellikle ciddi biçimde yavaşlamıyorlar
  • Savunmacılar ise bu düzeyde teknik analiz yapacak kaynağa çoğu zaman sahip değil
  • Temel saldırı davranışı bilgisi bile gizlendiğinde, saldırganların açık ve exploit hakkında savunmacılardan daha fazla içgörüye sahip olduğu bir asimetri ortaya çıkıyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-23
Hacker News yorumları

  • Bu hata en çok 2015’teki Timsort hatasına benziyor gibi görünüyor [1]
    Timsort, CPython’dan çıkan akıllı bir hibrit sıralama algoritmasıydı; OpenJDK dâhil birçok uygulama bunu neredeyse kaynak düzeyinde çeviri olarak benimsedi. Sıralı run yığınını tutuyor ve yapısı gereği olası en büyük yığın boyutu için yeterince küçük sonlu bir üst sınır olduğuna dair bir kanıt vardı; ancak özgün CPython uygulaması kanıtla tam örtüşmediği için nadir durumlarda yığın taşması mümkün oluyordu. Bu yüzden CPython’da ciddi bir güvenlik hatasıydı; Java ise bu durumda istisna fırlattığından OpenJDK’da aynı türden bir güvenlik sorunu değildi.
    Benzer şekilde bu WebP hatası da maksimum tablo boyutunun biçimsel olarak kanıtlanmış olmasına rağmen, gerçek kaynak koda giren değerle uyuşmamasından kaynaklandı. Bu tür hataları doğrulamak da incelemek de zor. Bir kanıt var ve kaynak da o kanıtla uyumlu görünüyor; bu yüzden her şeyin yolunda olduğunu düşünmek kolay. İnsan incelemesinden ziyade erişilebilir biçimsel doğrulamaya ve bellek güvenli dillerin kullanımına güçlü biçimde ihtiyaç olduğunun bir işareti gibi görünüyor. Tip sistemleri de biçimsel doğrulamanın zayıf bir biçimi olarak görülebilir.
    [1] http://envisage-project.eu/wp-content/uploads/2015/02/sortin...

    • Bu tür işler performans açısından kritik olduğundan özellikle WUFFS ile yazılmalı. WUFFS, Java gibi sınır kontrolleri üretmek ya da Rust’ın çalışma zamanında indeksin aralık içinde olup olmadığı belirsiz olduğunda kontrol etmesi gibi davranmak yerine, araç indeksin aralık içinde olduğunu doğrulayamıyorsa programın kendisini reddeder.
      https://github.com/google/wuffs
      Aynı kontrolleri açıkça yazarak bu gereksinimi karşılamak da mümkün; ancak yüksek performanslı yazılım olduğu için kontrole gerek olmadığına inanıyorsanız, WUFFS aracının kodu kabul etmediği noktada yanıldığınızı fark etme olasılığınız yüksek. Tam biçimsel doğrulamadan daha zayıf olsa da program güvenliği amacı açısından büyük bir iyileştirme ve bir insanın “LGTM” demesinden çok daha iyi.
    • “Tip sistemleri zayıf bir biçimsel doğrulama olarak görülebilir” ifadesi tip sisteminin türüne bağlı. Yakınlarda Idris’e baktım; hem genel amaçlı bir programlama dili hem de kanıtlar için kullanılabiliyor gibi görünüyor.

  • Bu yazıda “şu anda neyi yamalamalıyız” dışında da birkaç ilginç nokta vardı. Zafiyetin yerini ve düzeltmeyi bilseniz bile bir exploit PoC’yi yeniden üretmek epey çalışma gerektirebilir; ayrıca bir görüntü kod çözücünün içindeki kayıpsız sıkıştırma açıcı, fuzzing’e karşı oldukça dayanıklı olabilir. Güvenlik alanındakiler için bunlar bariz olabilir ama uzman olmayan biri olarak okuması keyifliydi.

    • Bu tür bir sorunun çözümü fuzzing değil, söz konusu kodu bir tümör gibi kesip çıkarmaktır. Bu yüzden OS’nin ya da tarayıcının çeşitli yerleri bozulacaksa, sorunlu formatı işleyen, güçlü şekilde sandbox’a alınmış bellek güvenli tek bir format dönüştürücü yazmak yeterli. Bazı uç durumlarda kullanışsız kalan bir iPhone ya da tarayıcı, fuzzing yapılıp yapılmadığından bağımsız olarak zafiyet barındırması neredeyse garanti olan böyle bir koddan daha iyidir bence. İyimser bir ifade ama bu hikâyenin burada bitmeyeceğinden eminim.

  • Net yanıt bulamadığım birkaç soru var. 1) Brave gibi diğer Chrome tabanlı tarayıcılar da etkileniyor mu? 2) Masaüstü Chrome da etkileniyor mu, yoksa sorun yalnızca mobilde mi? 3) WebP’yi neden hiç duymamış olabilirim? Dünyadan kopuk muydum, yoksa bu mobil öncelikli bir teknoloji mi merak ediyorum.

    • Güzel sorular. Diğer Chromium tabanlı tarayıcıların da bu hatadan etkilenme olasılığı yüksek. Brave gibi Chromium güvenlik güncellemelerini iyi takip eden çok tarayıcı var; ama Samsung SBrowser gibi epey geriden gelen örnekler de mevcut.
      Masaüstü Chrome da hem Linux hem Windows’ta etkilenmişti. Chrome kendi libwebp’sini paketlediği için Linux dağıtımı henüz yama geçmemiş olsa bile Chrome güncelse en azından tarayıcı saldırıları açısından sorun yok.
      Büyük tarayıcılar ve işletim sistemleri şaşırtıcı ölçüde çok sayıda az bilinen görüntü formatını destekliyor. Örneğin MacOS’te KTX2 (Khronos Texture Container), Android’de ise DNG (Adobe Digital Negative) yüklenebiliyor. Saldırganların keşfedebileceği ilginç ve yüksek maruziyetli çok sayıda saldırı yüzeyi var.
    • WebP destekleyen her şey etkilenir. Yalnızca Chrome ya da Electron değil; tüm tarayıcılar, masaüstü ve mobil, ayrıca tarayıcı dışı yazılımlar da buna dâhil. Görüntü görüntüleyiciler, grafik programları, e-posta istemcileri, küçük resim gösteren dosya yöneticileri bile kapsamda.
      Hata codec kitaplığında ve WebP, uygulaması fiilen tekilleşmiş bir ekosistem olduğu için herkes aynı kitaplığı kullanıyor; dolayısıyla herkesin yama geçmesi gerekiyor.
      Google 10 yıl önce WebP’yi öne çıkardı ama uzun süre Chrome’a özgü kaldığı için fazla güç kazanamadı. Doğru düzgün standartlaştırılmış da değildi, ancak açık kaynaklıydı. Düşük kaliteli görüntüleri JPEG’den daha iyi sıkıştırıyor; fakat yüksek kaliteli görüntülerde renklerin akma ve bulanıklaşma eğilimi var. İronik biçimde WebP yaygın şekilde desteklenmeye başladığında, AVIF ve JPEG XL tarafından teknik olarak zaten eskimeye başlamıştı.
    • Neredeyse kesin olarak WebP görüntüleri indirip görmüşsünüzdür; ancak birçok web sitesi aynı URL’den birden fazla format sunduğu için fark etmemiş olmanız çok olası. Genelde HTTP reverse proxy formatı otomatik dönüştürür; son 10 yıl içindeki bir tarayıcı kullanıyorsanız indirdiğiniz dosyanın uzantısı “.png” gibi görünse bile WebP alıyor olabilirsiniz. Modern görüntü düzenleyicilerin hepsi WebP desteklediğinden farkı anlamak zor.
    • WebP, masaüstü Chrome’da uzun zamandır destekleniyordu. JPEG’in yerini almayı hedefleyen onlarca format ortaya çıktı ve kayboldu; WebP’yi öne çıkaran esas nokta çoğunlukla Google’ın etkisi oldu. Google, Duck/On2’yi satın alınca pek çok video sıkıştırma teknolojisi elde etti ve bunların bir kısmı WebP’ye girdi.
    • Tüm tarayıcılar etkileniyor ve Firefox da güvenlik güncellemesi yayımladı. WebP, JPEG alternatifi olarak giderek popülerleşiyor; web’den indirdiğiniz görüntülerin gittikçe daha sık WebP olarak geldiğini düşününce henüz karşılaşmamış olmanız şaşırtıcı.

  • Android cihazınız destek sonu durumundaysa, şu anda fiilen ortalıkta dolaşan bir 0 tıklama exploite maruz kalmış sayılır mısınız? Yoksa SMS uygulamasını, Chrome’u, WhatsApp’ı, Signal’i vb. güncellemek başlıca giriş yollarını yeterince kapatır mı, merak ediyorum.

    • Bu hata için Android exploit’inin zaten var olup olmadığı kesin değil. Asıl exploit iMessage üzerinden iOS içindi, ama geliştirilmiş olma ihtimali oldukça yüksek. Bugünlerde Android için bu tür exploit’lere talep çok yüksek ve yakın zamanda akıl almaz fiyatlardan söz edildiğini duydum.
      Destek sonu cihazlarda Chrome’u güncellerseniz Chrome sorunu düzelir, ancak Signal veya WhatsApp gibi uygulamaları düzeltmek için Android OS yükseltmesi gerekir. Chrome kendi libwebp’sini paketliyor, fakat mesajlaşma uygulamaları ve Gmail gibi yüksek maruziyetli uygulamalar görüntüleri göstermek için işletim sisteminin sağladığı arayüzleri kullanıyor. Güvenlik desteği alan Android cihazlar için ekim başından itibaren güncellemelerin çıkmasını bekliyorum.
    • Platformun görüntü kod çözme kütüphanesi, Play Store üzerinden güncellenen sistem modüllerinden biri olmalı. Gerçekten böyle olup olmadığını doğrulayabilecek biri var mı, merak ediyorum.
    • Bazı mesajlaşma uygulamalarında gelen görüntüleri otomatik indirmeme veya önizlememe seçeneği var; bu ayarı açmak iyi bir önlem olabilir. Google Messages’ta bu özellik var.
    • Android güvenlik güncellemelerinin kapsamı dışındaysa, endişeleneceğiniz tek şey bu değil. Ben önce daha kolay istismar edilebilenlerden endişelenirdim.
    • iOS’ta iMessage yüksek yetkilere sahip olduğu için bu özellikle büyük bir sorun. Android’de ise bu tür uygulamaların hepsi sandbox içinde.

  • “huffman_tables’ı gerçekten overflow’a uğratan çok sayıda girdi var” ifadesi daha genel bir sorun gibi görünüyor. Yazılım A, arama tablosu B’yi oluşturuyor ve bu tablo giriş veri akışını işlemek için kullanılıyor.
    Artık güvenlik veya doğruluğa az da olsa önem veren bir geliştiricinin iki şeyden birini garanti etmesi gerekir: A) yazılım, hiçbir giriş verisi arama tablosunu yanlış kullanamaz veya başarısızlığa uğratamaz şekilde yazılmıştır ya da B) yalnızca kontrollü bir ortamda, örneğin iki iletişim tarafının da güvenildiği noktadan noktaya iletişimde kullanılır ve akışın arama tablosunu asla yanlış kullanmayacağı ya da anormalliğe yol açmayacağı garanti edilir.
    B, küçük bir grup veya ofis dışında neredeyse imkânsızdır; internet ölçeğinde ise gerçekten imkânsızdır, dolayısıyla geriye yalnızca A kalır. Geleceğin yazılım mühendisliğinde genelleştirilmiş iyi uygulama şu olmalı: Herhangi bir nedenle arama tablosu kullanılıyorsa, geliştirici bu tablonun tüm veri türlerinde doğru çalıştığını garanti etmeli ya da hatalı veriyi tabloya ulaşmadan önce tespit edip uygun şekilde işlemelidir.
    Ciddi bir güvenlik araştırmacısı olsam ve vaktim olsa, geçmişte arama tablolarıyla herhangi bir şekilde ilişkili tüm güvenlik açıklarının listesini toplayıp tek tek okur, ortak noktalarını karşılaştırırdım. Muhtemelen bir örüntü vardır. Ardından veri akışlarında arama tablosu kullanan tüm yazılımları tarayıp zafiyet denetimi yapardım; ama bu tek bir kişinin ömrü boyunca yapabileceği bir iş değil, bir takım sporu.

  • NSO’nun bu hatayı bulmasında kaynak kodunun açık olması ne kadar yardımcı olmuş olabilir? Kod yalnızca binary blob olsaydı, modern decompiler’lar tek başına kodu anlayıp böyle anlaşılması güç bir hatayı bulmaya yeter miydi, merak ediyorum.

    • Blob’lar saldırganları durdurmaz. Başarılı bir exploit yazmak için zaten derlenmiş binaryyi anlamak gerekir.

  • Bunun görüntü formatının “yeni” bir parçası olmaması şaşırtıcı. Huffman sıkıştırması 70 yıldan uzun süredir var; kanonik Huffman da ondan yalnızca birkaç on yıl daha genç, hatta JPEG bile Huffman kullanıyor. On yıllardır var olan bir teknoloji ve uygulanma biçimini anlatan sayısız yazı var; artık birçok uygulamada hataları ayıklanmış olması gereken bir teknoloji gibi görünüyor.
    Daha önce JPEG spesifikasyonunu okuyup bir decoder da yazmış olduğum için WebP spesifikasyonuna baktım: https://developers.google.com/speed/webp/docs/webp_lossless_...
    Önemli kısım 6. bölümde. İlk göze çarpan şey, kodun nasıl kurulduğunun JPEG spesifikasyonundaki kadar açık olmaması. JPEG’de süreçle ilgili okunması kolay çok sayıda akış diyagramı var. WebP, LZH/deflate(zlib)’a benziyor ve bir “spesifikasyon”dan çok, açıklama eklenmiş bazı kaynak kod parçalarının derlemesi gibi duruyor.
    GIF, JPEG, PNG’den sonra bir WebP decoder da yazmayı düşünüyorum, ama yukarıdaki “spesifikasyon”a bakınca neredeyse yazma diyor gibi hissettiriyor.

    • Spesifikasyonda gerçekten örnek eksik olduğuna katılıyorum, ancak kanonik Huffman ağacı kullanıldığı için yalnızca kod uzunluklarının gönderilmesinin yeterli olduğunu açıkça belirtiyor. Gerçek ağacı belirlemek için yeterince açık olduğunu düşünüyorum. Ters sözlük sırası kullanan kanonik Huffman uygulaması olduğunu sanmıyorum.
      Huffman ağacı uygulamalarında çok farklı ödünleşimler olduğu için, eski bir teknoloji diye hatalarının tamamen ayıklandığını söylemek zor. Charles Bloom, 1997 tarihli Huffman optimizasyonu üzerine belirleyici makalenin [1] bile 2010 itibarıyla iyi bilinmediğini ve birçok optimizasyonun yeniden keşfedilip sonra unutulduğunu söylemişti. Bu yüzden verimsiz uygulamaların çok olması muhtemel.
      [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffm...
    • Başvurulacak koda ihtiyacınız varsa https://github.com/golang/image/tree/master/vp8l adresinde 1200 satırdan kısa bir WebP-Lossless decoder var.

  • Artık görüntüye bakarken bile güvenlik endişesi duymadan edemiyoruz gibi.

    • Yazılım üreticisi görüntü render ederken biraz daha yavaş bir kütüphane kullanırsa, en ciddi güvenlik endişesi olan uzaktan kod çalıştırmadan kaçınabilir. C ile yazılmış kütüphanelerden kaçınmak uzaktan kod çalıştırmayı neredeyse ortadan kaldırabilir ve kullanıcıları da daha güvenli hale getirir.
    • Yanlış hatırlıyor olabilirim ama PNG ve JPG’de de en az bir kez benzer bir şey olmuştu sanki.
      Güvenli olmayan bir dil olan C’yi kullanmanın tipik büyüme sancıları gibi geliyor. Tarayıcı hızı nedeniyle cazip olduğunu anlıyorum, ancak sektörün C kullanmaya başladığından beri tekrarladığı aynı hataları teşvik eden yaklaşımdan uzaklaşmasını isterim.
      Daha hızlı diye perçin yerine kendinden kılavuzlu vidalarla köprü yapmak gibi. Köprü sarkmaya başlayınca daha fazla vida takmak yeterliymiş gibi.

  • “İyi haber şu ki Apple ve Chrome, bu meselenin aciliyetine uygun şekilde harika tepki verdi” denmesi pek ikna edici değil. Bu sorunu yalnızca Chrome’a özgü olarak sınıflandıran Google’dı. Sadece son 7 güne bakıldığında bile tüm büyük Linux dağıtımlarının güncelleme yayınlaması gerekti ve Red Hat buna 9,6 puan verdi. 1 milyardan fazla kez pull edilmiş Python Docker imajları, Puppeteer, WordPress, Node.js vb. de etkilendi; buna rağmen CRBug hâlâ gizli
    BleepingComputer gibi siteler, araştırmadan gördükleri gibi haber yaptı; bu konuyu üçüncü tarafmış gibi ele alan birçok güvenlik şirketi de aynı şeyi yaptı. Karşı tarafın durum tespiti yapmadığını biliyorsanız güven inşa etmek gerçekten zor
    Adam Caudill, 1Password’ün erken dönemde yama yaptığı örnekle birlikte “Whose CVE is it anyway?”[0] başlıklı iyi bir yazı yazdı ve burada bahsedilen sorunu iyi yakaladı. Citizen Lab iki meselenin bağlantılı olup olmadığına yanıt vermeyi reddetti ama bazı şeyleri görmek için dahi olmaya gerek yok
    [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/

    • Burada Apple ve Chrome’un özellikle önemli olmasının nedeni, gerçek dünyada istismar edilen hedeflerin bunlar olması ve en fazla kullanıcıya sahip doğrudan saldırı yüzeyini barındırmaları
      Yazar da başka birçok sistemin yama yapması gerektiğini söylüyor. Ancak 1 milyar kez pull edilmiş Python Docker imajlarının kaç tanesi güvenilmeyen WebP görüntülerini render ediyor? Node vb. için de aynı. Elbette hızlıca yamalanmaları gerekir ama iOS/Android/Chrome ile aynı seviyede değiller

  • Dünya çapında yüz milyonlarca kişi bu kütüphaneden etkileniyor; kullandıkları her cihaz ve uygulamayla etki katlanıyor
    C’yi seviyorum ama dünya çapında yüz milyonlarca kişinin kullandığı kütüphanelerde C kullanılmaması gerektiğini düşünüyorum. Bu tür temel kütüphanelerde risk oranı çok yüksek. C uzmanı olsanız bile bir gün hata yaparsınız
    Düzeltme bu gibi görünüyor https://github.com/webmproject/libwebp/commit/dce8397fec159c...
    “malloc fail” denmesi sinir bozucu. Slack, Discord, Teams ve tüm modern işletim sistemleri etkileniyor

    • Asıl düzeltme şu: https://github.com/webmproject/libwebp/commit/902bc919033134...
    • Aynı fikirdeyim. Rust yeni C olmalı. C ile kod yazabiliyor olmak, “performans”, “taşınabilirlik”, “eski sistem uyumluluğu” gibi gerekçelerle büyük miktarda karmaşık kod üretmeye hakkınız olduğu anlamına gelmez
      C/C++ ve dinamik diller, tanımsız davranış ve ince hatalar için yüzeyi büyütür; en zeki geliştiriciler için bile lint etmek zor ve yükü ağırdır. Temel kütüphaneler seL4’ye benzer bir yaklaşımla biçimsel olarak doğrulanmalı
      Bir başka sorun da FOSS genelinde yayılmış amatörlük ve titizlik, kalite, doğruluk ile güvenliğin önemsenmemesi. Bugünkü gibi kumun üzerine imparatorluk kurma yaklaşımı aptalca
    • Burada ya da yakın commit’lerde tek bir test bile yok. Akıl alır gibi değil