Chromium hata ödüllerini gösteren Money Tree Browser

 (lyra.horse)
2 puan yazan GN⁺ 2024-01-07 | 1 yorum | WhatsApp'ta paylaş
  • Chromium Money Tree Browser, Chrome VRP ödüllerini Chromium deposundaki dizin ve dosya bazlı değişiklik geçmişiyle eşleştirerek güvenlik ödüllerinin kod ağacında nerede biriktiğine göz atmayı sağlıyor
  • Ödül tutarı değiştirilen dosya sayısına bölünerek dağıtılıyor; örneğin 1.000 $ ödüllü bir hata düzeltmesi 5 dosyayı değiştirirse her dosyaya 200 $ atanıyor
  • En üst düzey toplamlar root için 9.873.277 $ / 10.944 kayıt, chromium için 9.014.838 $ / 10.218 kayıt, chrome için 2.568.260 $ / 2.574 kayıt olarak gösteriliyor
  • chrome/browser/ui/views, extensions, media, safe_browsing, enterprise, Android, net, device, gpu, storage, base, iOS, pdf gibi birçok alan dosya düzeyinde parçalanmış halde görünüyor; V8 de 858.439 $ / 726 kayıt ile büyük bir paya sahip
  • Veri ve arayüzün “very very hacked together” durumda olduğuna dair bir not var ve kapsam da Kasım 2023 başına kadar uzanıyor; bu yüzden bunu kesin bir muhasebe kaydından çok keşif amaçlı bir harita gibi görmek daha doğru

Ödül tutarını kod ağacına dağıtma yöntemi

  • Chrome VRP hata ödüllerini Chromium kod tabanının dosya ve dizin ağacına bağlayarak gösteren bir tarayıcı
    • Belirli bir güvenlik düzeltmesi birden fazla dosyayı değiştirirse ödül tutarı dosya sayısına bölünüp her dosyaya atanıyor
    • Bu eşleştirme daha çok “hangi kodun güvenlik ödülleriyle birlikte sık değiştiğini” incelemek için kullanılıyor
  • Yalnızca en üst düzey toplamlar bile Chromium genelinde kayda değer bir ödül dağılımı olduğunu gösteriyor
    • root: 9.873.277 $ / 10.944 kayıt
    • chromium: 9.014.838 $ / 10.218 kayıt
    • chrome: 2.568.260 $ / 2.574 kayıt
    • chrome/browser: 2.250.643 $ / 1.920 kayıt

Dizin bazında dikkat çeken dağılım

  • chrome/browser/ui/views altında, kullanıcı arayüzü işlevlerine göre ödül dağılımı ayrıntılı biçimde bölünmüş
    • views: 514.665 $ / 441 kayıt
    • tabs: 56.705 $ / 30 kayıt
    • eye_dropper: 47.000 $ / 7 kayıt
    • bookmarks: 46.697 $ / 31 kayıt
    • payments: 43.623 $ / 60 kayıt
    • media_router: 36.395 $ / 12 kayıt
    • tab_sharing: 30.591 $ / 9 kayıt
  • Chrome extensions ile ilgili alanlar da tekrar tekrar büyük kümeler halinde öne çıkıyor
    • extensions: 157.507 $ / 262 kayıt
    • extensions/api: 115.471 $ / 161 kayıt
    • api/tabs: 42.705 $ / 48 kayıt
    • api/debugger: 28.488 $ / 35 kayıt
    • api/downloads: 15.225 $ / 13 kayıt
    • Ayrı bir extensions alanı da 132.615 $ / 213 kayıt olarak hesaplanıyor; buna renderer, guest_view/web_view ve file_system API gibi bölümler dahil
  • V8, verilen notlarda en büyük tekil alt alan olarak görünüyor
    • V8 toplamı: 858.439 $ / 726 kayıt
    • v8/src: 626.845 $ / 503 kayıt
    • v8/test: 209.030 $ / 195 kayıt
    • v8/src/compiler: 151.267 $ / 85 kayıt
    • v8/src/heap: 91.891 $ / 64 kayıt
    • v8/src/builtins: 68.133 $ / 30 kayıt
    • v8/test/mjsunit: 164.644 $ / 113 kayıt
  • chrome/browser tarafında UI, sekmeler, otomatik doldurma, parolalar, DevTools ve renderer context menu gibi kullanıcı temas noktaları dikkat çekiyor
    • chrome/browser/autofill: 114.656 $ / 40 kayıt
    • chrome/browser/tabs: 92.316 $ / 25 kayıt
    • passwords: 51.060 $ / 10 kayıt
    • chrome_content_browser_client.cc: 51.512 $ / 11 kayıt
    • devtools: 48.255 $ / 35 kayıt
    • renderer_context_menu: 47.842 $ / 16 kayıt
    • printing: 42.225 $ / 14 kayıt
    • payments: 41.252 $ / 10 kayıt
  • Medya, güvenlik, kurumsal ve platform alanlarında da yüksek tutarlar görülüyor
    • media: 134.523 $ / 65 kayıt, ayrı chrome/browser/media alanı ise 89.008 $ / 34 kayıt
    • safe_browsing: 80.161 $ / 31 kayıt
    • enterprise: 59.000 $ / 38 kayıt
    • ash: 130.389 $ / 161 kayıt, ayrı bir ash bölümü de 56.867 $ / 55 kayıt ile devam ediyor
    • mojo: 112.725 $ / 26 kayıt
    • net: 97.558 $ / 175 kayıt
    • device: 61.770 $ / 32 kayıt
    • gpu: 51.155 $ / 30 kayıt
    • storage: 48.303 $ / 66 kayıt
    • base: 36.013 $ / 27 kayıt
  • Android ve iOS için de platforma özel kodlarda ödül dağılımı ayrı ayrı gösteriliyor
    • Android chrome/browser Java, kaynak ve test alanları: 94.441 $ / 159 kayıt
    • Android Java yolu: 62.571 $ / 91 kayıt
    • Android fullscreen: 18.707 $ / 11 kayıt, FullscreenHtmlApiHandler.java ise 18.540 $ / 10 kayıt
    • iOS: 33.625 $ / 86 kayıt
    • ios/chrome/browser/web: 11.663 $ / 4 kayıt
    • ios/chrome/browser/ui: 9.884 $ / 24 kayıt

Test dosyaları ve yorumlarken dikkat edilmesi gerekenler

  • Test verileri ve regresyon test dosyaları da ödül dağılımına dahil ediliyor
    • test: 147.193 $ / 311 kayıt
    • test/data: 116.355 $ / 271 kayıt
    • test/data/extensions/api_test: 59.337 $ / 166 kayıt
    • V8 test/mjsunit/regress: 82.180 $ / 58 kayıt
    • V8 test/mjsunit/compiler: 46.233 $ / 28 kayıt
    • Bunun nedeni, güvenlik düzeltmeleri test dosyası değişiklikleriyle birlikte kaydedildiğinde ödül tutarının bu dosyalara da dağıtılması
  • Hesaplama yöntemi basit olduğu için tutarları doğrudan risk seviyesi ya da zafiyetin kaynağı olarak okumak zor
    • Ödül tutarı “değiştirilen dosya sayısına” bölündüğü için bir dosyaya düşen miktar o dosyanın kendi risk düzeyini doğrudan ifade etmiyor
    • Veri ve arayüz “very very hacked together” durumda; yani iyi bir kullanıcı deneyimi ya da tam isabetli veri beklenmemesi gerektiği özellikle belirtiliyor
    • Veri kapsamı Kasım 2023 başına kadar uzanıyor
  • İlgili tartışma bağlantısı da birlikte verilmiş

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-07
Hacker News görüşleri

  • Uzun zamandır yapmak istediğim şeye epey benziyor. Belirli bir değişikliğin sorun çıkarma olasılığını, aynı dosyada ya da dosya içindeki aynı bölgede geçmişte yaşanan yıkıcı değişiklik geçmişine göre hesaplamak faydalı olur diye düşünüyordum
    Temelde her değişikliğe bir risk puanı verip, bu puanı her PR’da göstererek gözden geçiren kişinin daha dikkatli bakması gereken kodu anlamasını sağlamak ve dağıtım sırasında da riskli değişiklikleri öne çıkarmak fikri
    Zor taraf, üst taraftaki ekleme/silmeler yüzünden kod konumu yukarı aşağı kayarken aynı kod bölgesini izlemeye devam etmek; yalnızca satır numarasına dayanan algoritmalar burada sorun çıkarıyor
    Yine de bu örnekte olduğu gibi sadece dosya düzeyinde bile yeterince faydalı görünüyor

    • 2 yılı aşkın süredir bunun üzerinde çalışıyorum. Her değişikliği statik olarak analiz ediyor, monorepo’nun tamamını da her gün analiz ediyoruz; ardından bunu sembol düzeyinde işliyoruz
      Riski yüksek değişikliklerde daha fazla test çalıştırıyoruz; birim testleri değil, istemci testleri çalıştırıyoruz. Bazen seçilebilecek istemci testi sayısı 100 bin oluyor; bu yüzden sıralayıp sadece küçük bir alt kümeyi çalıştırıyoruz
      Zor bir problem. İlginç gözlemlerden biri, kök neden olan değişiklikte gerçekten bir iki neden sembolü bulunmasına rağmen, bu sembollerin bağlantılılığının aynı değişiklik içindeki neden olmayan sembollere çok benzemesi
      Ayrıca değişiklikten sonra geçişli olarak değişen çağrı grafiği epey büyük; 50 derinlik bile nadir değil. Değişiklikle testler arasında geçişli olarak etkilenen sembollerin ne kadar örtüştüğü dışında pek işe yarar sinyal çıkarmakta zorlandık
      Dosya düzeyi ve derleme hedefi düzeyi çok kaba kaldı; AST sembolleri ise iyi çalışıyor
    • Sadece kodun kendisine değil, yazarına da bakmak gerekir. Birlikte çalıştığım kişilerden biri, ne zaman bir PR oluştursa içine en az bir hata koyuyordu
    • Şu anda tam bu konuda bir kitap okuyorum: https://pragprog.com/titles/atcrime/your-code-as-a-crime-sce...
    • Kod konumu, köken/yazar ve bitişikteki hassas koda ilişkin veri akışı analizini birlikte görmek güzel olurdu. İnceleme aracıma eklenebilecek türden

  • Çok güzel. Yalnız sanki bazı girdiler eksik. third_party/ffmpeg içinde de en az bir tane olduğundan eminim
    Bu tür düzeltmeler genelde önce upstream’e girdiği için takibi zor olabiliyor

    • Monorail hatalarına Git Watcher tarafından bırakılan yorumları kullanıyorum

  • chrome/browser/ui altındaki büyük kümeye bakınca, elle bellek yönetiminin performans avantajlarının pek önemli olmadığı verilerde use-after-free hatasının ne kadar sık çıktığını düşünmeden edemiyorsunuz. Örneğin [1], “dosya seç” iletişim kutusunun yaşam döngüsü etrafındaki bir sorun
    Büyük resimde, bu tür kodlarda savunma amacıyla daha akıllı ama daha yavaş işaretçileri her zaman kullanmak daha iyi gibi görünüyor. [2] içindeki raw_ptr türü [3] böyle bir yardım sağlamaya çalışıyor gibiydi; hatta [2]’deki çökme belki de gerçekten başarılı bir savunma örneğiydi
    Proje içinde, “burası performans açısından kritik ve dikkatle incelenmiş kod” ile “burası performansa duyarsız ama çok sayıda asenkron durum içerdiği için hata yapması kolay kod” gibi daha geniş bir şekilde lehçe değiştirebilmenin iyi bir yolu olmaması üzücü. Hatta ikincisi için GC’li ayrı bir dili karıştırmanın neredeyse değeceğini düşündüğüm olmuştu
    Bu arada bu kod üzerinde çok eskiden çalışmıştım; bu hatalardan sıfırdan fazla bir kısmını benim yazmış olmam da beni şaşırtmaz
    [1] https://bugs.chromium.org/p/chromium/issues/detail?id=120103...
    [2] https://bugs.chromium.org/p/chromium/issues/detail?id=132323...
    [3] https://source.chromium.org/chromium/chromium/src/+/main:bas...

    • Bu, Rust’taki unsafe anahtar sözcüğünü açıklamaya benziyor
      Ve bu tür kodlar, kelimenin tam anlamıyla Rust’ın ortaya çıkmasının asıl nedenlerinden biriydi. Dil zaten baştan tarayıcı uygulamalarını düşünerek tasarlanmıştı
    • Performans açısından kritik kısımları C veya Rust ile yazıp geri kalanını Python bırakmak neredeyse bunun bir örneği. Duyduğuma göre Rust-Python bağları özellikle iyi ve performans kritik bölümlerde bile doğruluğu korumayı daha kolaylaştırıyor
      Tersi yönde, hızlı bir dilden betik dilini çağırmak da mümkün. Bugün herkes wasm’e hayran ama bilgisayar oyunları zaten yaklaşık 20 yıldır bu amaçla lua kullanıyor. Oyunlar muhtemelen performansa duyarlı yazılımların en büyük kategorisi
    • Aynı nedenle tarayıcı sürecinde Oilpan GC kullanmak istemiştim, ama o dönemde tarayıcı tarafındaki insanlar blink kütüphanelerinin kullanımına ciddi şekilde karşı çıkıyordu
      Chrome UI kodunun çoğu zaten en azından Web UI ile yazılıyor. Bugün olsa, tarayıcı içindeki daha fazla orkestrasyon işi için typescript değerlendirilmeli diye düşünüyorum. Electron’ın doğruladığı bir strateji
      Ama şu anki yönelimin gerçekten MiraclePtr tarafında olduğu anlaşılıyor
    • raw_ptr, çoğu use-after-free istismarını gerçekten hafifleten bir akıllı işaretçi sarmalayıcısı: https://security.googleblog.com/2022/09/use-after-freedom-mi...

  • Bunu bir treemap görselleştirmesine dönüştürdüm[1]: https://vrp-treemap.surge.sh/
    Treemap kütüphanesini de bu başlıkta bulunan Chrome emektarı evmar yazmış

  • Çok temiz bir görselleştirme. Alanları genişletirken CPU’yu biraz fazla kullanıyor ama Chrome ekibinin içinde de benzer bir şey olsa harika olurdu
    Yani saldırı yüzeyini anlamak için gerçekten çok faydalı görünüyor

  • Gerçekten harika bir fikir ve uygulaması da iyi
    Ham veri bir yerde mevcut mu? Sunburst ya da treemap denemek de güzel olabilir

  • Bu muhtemelen diff düzeyine kadar indiğine göre, değişen kod satırı sayısıyla ağırlıklandırmak ilginç olabilir. Mesela dosya A’da 10 satır, dosya B’de 1 satır değiştiyse, hatanın büyük kısmı dosya A’dadır; dolayısıyla ödülün 1/11’i dosya A’ya atanır gibi mi?
    Ya da değişen satır sayısı / dosyanın toplam satır sayısı temelinde dağıtılabilir. Böylece her dosyanın ne kadar hatalı olduğunu parasal etiketle görebilirsiniz

    • Bunu yaparsanız arzulanan etki ortaya çıkar. Test gibi kodlar çok ayrıntılı ve uzun olabiliyor, ama asıl açık çoğu zaman birkaç karakterde bitebiliyor

  • Her düğümde dosya başına ortalama ödül tutarı da gösterilse güzel olur

  • Küçük bir not ama DEPS, AUTHORS ve BUILD.gn dosyalarını dahil etmemek daha iyi olabilir

  • Tutarı kod satırı sayısına göre normalize eden bir sürüm nasıl olur?

    • Bunu neden sorduğunuzu merak ettim. Çünkü yazılım ve güvenlikte kod satırı sayısının pek anlamlı bir ölçüt olmadığını düşünüyorum
    • Ya da hata için harcanan kelime sayısına göre normalize edebilirsiniz. Karmaşıklık için bir vekil gösterge olabilir çünkü