Money Tree Browser yang Menampilkan Bounty Bug Chromium

 (lyra.horse)
2 poin oleh GN⁺ 2024-01-07 | 1 komentar | Bagikan ke WhatsApp
  • Chromium Money Tree Browser memetakan reward Chrome VRP ke riwayat perubahan per direktori dan file di repositori Chromium, sehingga memungkinkan Anda menelusuri di bagian mana pada pohon kode reward keamanan terkumpul
  • Nilai reward dibagi berdasarkan jumlah file yang diubah; jika perbaikan bug dengan reward $1.000 mengubah 5 file, masing-masing file mendapat alokasi $200
  • Agregasi tingkat teratas ditampilkan sebagai root $9,873,277 / 10,944 kasus, chromium $9,014,838 / 10,218 kasus, chrome $2,568,260 / 2,574 kasus
  • Berbagai area seperti chrome/browser/ui/views, extensions, media, safe_browsing, enterprise, Android, net, device, gpu, storage, base, iOS, pdf terlihat dipecah hingga tingkat file, dan V8 juga memiliki porsi besar dengan $858,439 / 726 kasus
  • Ada catatan bahwa data dan UI berada dalam kondisi “very very hacked together”, dan cakupannya juga hanya sampai awal November 2023, jadi lebih tepat dilihat sebagai peta eksplorasi daripada catatan akuntansi yang presisi

Cara membagi nilai reward ke pohon kode

  • Ini adalah browser yang menautkan reward bug bounty Chrome VRP ke pohon file dan direktori pada codebase Chromium
    • Jika perbaikan keamanan tertentu mengubah beberapa file, nilai reward dibagi berdasarkan jumlah file dan dialokasikan ke tiap file
    • Keterkaitan ini lebih ditujukan untuk menelusuri “kode mana yang sering berubah bersama reward keamanan”
  • Dari agregasi tingkat teratas saja sudah terlihat distribusi reward yang cukup besar di seluruh Chromium
    • root: $9,873,277 / 10,944 kasus
    • chromium: $9,014,838 / 10,218 kasus
    • chrome: $2,568,260 / 2,574 kasus
    • chrome/browser: $2,250,643 / 1,920 kasus

Distribusi per direktori yang menonjol

  • Di bawah chrome/browser/ui/views, distribusi reward dipilah cukup rinci per unit fitur UI pengguna
    • views: $514,665 / 441 kasus
    • tabs: $56,705 / 30 kasus
    • eye_dropper: $47,000 / 7 kasus
    • bookmarks: $46,697 / 31 kasus
    • payments: $43,623 / 60 kasus
    • media_router: $36,395 / 12 kasus
    • tab_sharing: $30,591 / 9 kasus
  • Area terkait Chrome extensions juga muncul berulang sebagai kelompok besar
    • extensions: $157,507 / 262 kasus
    • extensions/api: $115,471 / 161 kasus
    • api/tabs: $42,705 / 48 kasus
    • api/debugger: $28,488 / 35 kasus
    • api/downloads: $15,225 / 13 kasus
    • Area extensions terpisah juga diagregasikan sebesar $132,615 / 213 kasus, mencakup renderer, guest_view/web_view, API file_system, dan lainnya
  • V8 tampak sebagai area turunan tunggal terbesar dalam catatan yang diberikan
    • V8 keseluruhan: $858,439 / 726 kasus
    • v8/src: $626,845 / 503 kasus
    • v8/test: $209,030 / 195 kasus
    • v8/src/compiler: $151,267 / 85 kasus
    • v8/src/heap: $91,891 / 64 kasus
    • v8/src/builtins: $68,133 / 30 kasus
    • v8/test/mjsunit: $164,644 / 113 kasus
  • Di sisi chrome/browser, titik kontak pengguna seperti UI, tab, autofill, password, DevTools, dan menu konteks renderer terlihat menonjol
    • chrome/browser/autofill: $114,656 / 40 kasus
    • chrome/browser/tabs: $92,316 / 25 kasus
    • passwords: $51,060 / 10 kasus
    • chrome_content_browser_client.cc: $51,512 / 11 kasus
    • devtools: $48,255 / 35 kasus
    • renderer_context_menu: $47,842 / 16 kasus
    • printing: $42,225 / 14 kasus
    • payments: $41,252 / 10 kasus
  • Area media, keamanan, enterprise, dan platform juga teragregasi dalam nilai besar
    • media: $134,523 / 65 kasus, sementara area chrome/browser/media terpisah sebesar $89,008 / 34 kasus
    • safe_browsing: $80,161 / 31 kasus
    • enterprise: $59,000 / 38 kasus
    • ash: $130,389 / 161 kasus, disusul bagian ash terpisah sebesar $56,867 / 55 kasus
    • mojo: $112,725 / 26 kasus
    • net: $97,558 / 175 kasus
    • device: $61,770 / 32 kasus
    • gpu: $51,155 / 30 kasus
    • storage: $48,303 / 66 kasus
    • base: $36,013 / 27 kasus
  • Android dan iOS juga memiliki distribusi reward yang dipisah pada kode platform masing-masing
    • Area Java, resource, dan test Android chrome/browser: $94,441 / 159 kasus
    • Path Java Android: $62,571 / 91 kasus
    • Android fullscreen: $18,707 / 11 kasus, dengan FullscreenHtmlApiHandler.java sebesar $18,540 / 10 kasus
    • iOS: $33,625 / 86 kasus
    • ios/chrome/browser/web: $11,663 / 4 kasus
    • ios/chrome/browser/ui: $9,884 / 24 kasus

File test dan hal yang perlu diperhatikan dalam interpretasi

  • Data test dan file regression test juga termasuk dalam distribusi reward
    • test: $147,193 / 311 kasus
    • test/data: $116,355 / 271 kasus
    • test/data/extensions/api_test: $59,337 / 166 kasus
    • V8 test/mjsunit/regress: $82,180 / 58 kasus
    • V8 test/mjsunit/compiler: $46,233 / 28 kasus
    • Ini karena jika perbaikan keamanan tercatat bersama perubahan file test, nilai reward juga didistribusikan ke file tersebut
  • Karena metode perhitungannya sederhana, angka uang tidak bisa langsung dibaca sebagai tingkat risiko atau penyebab kerentanan
    • Karena reward dibagi berdasarkan “jumlah file yang diubah”, nilai pada satu file tidak secara langsung menunjukkan risiko file itu sendiri
    • Ada catatan bahwa data dan UI berada dalam kondisi “very very hacked together”, dan pengguna diminta tidak mengharapkan UX yang baik atau data yang akurat
    • Cakupan data adalah hingga awal November 2023
  • Tautan diskusi terkait juga disediakan

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-07
Opini Hacker News

  • Ini cukup mirip dengan sesuatu yang sudah lama ingin saya buat. Rasanya akan berguna jika kemungkinan sebuah perubahan tertentu menimbulkan masalah dihitung berdasarkan riwayat perubahan yang merusak di masa lalu pada file yang sama atau area yang sama di dalam file
    Pada dasarnya, setiap perubahan diberi skor risiko, lalu skor itu ditampilkan untuk tiap PR agar reviewer tahu kode mana yang perlu dilihat lebih saksama, dan saat deploy perubahan berisiko juga disorot
    Bagian yang sulit adalah terus melacak area kode yang sama ketika posisi kode naik-turun karena penyisipan/penghapusan di bagian atas; algoritma yang hanya bergantung pada nomor baris akan bermasalah di sini
    Meski begitu, seperti contoh ini, bahkan pada level file saja tampaknya sudah cukup berguna

    • Saya sudah mengerjakan hal ini lebih dari 2 tahun. Kami melakukan analisis statis pada tiap perubahan dan juga menganalisis seluruh monorepo setiap hari, lalu memprosesnya pada level simbol
      Untuk perubahan berisiko tinggi, kami menjalankan lebih banyak test, bukan unit test, melainkan client test. Kadang ada 100 ribu client test yang bisa dipilih, jadi kami memberi peringkat lalu hanya menjalankan subset kecil
      Ini masalah yang sulit. Salah satu pengamatan menarik adalah bahwa memang ada satu atau dua simbol penyebab di dalam perubahan penyebab, tetapi konektivitas simbol itu sangat mirip dengan simbol non-penyebab dalam perubahan yang sama
      Selain itu, call graph yang berubah secara transitif setelah perubahan cukup besar; kedalaman 50 pun tidak jarang. Sulit mendapatkan banyak sinyal berguna selain tingkat irisan simbol yang terdampak secara transitif antara perubahan dan test
      Level file dan level build target terlalu kasar, sedangkan simbol AST bekerja dengan baik
    • Selain kode itu sendiri, penulisnya juga perlu dilihat. Saya pernah bekerja dengan seseorang yang memasukkan setidaknya satu bug setiap kali membuat PR
    • Saya sedang membaca buku tentang topik itu: https://pragprog.com/titles/atcrime/your-code-as-a-crime-sce...
    • Akan bagus jika menggabungkan lokasi kode, asal/penulis, dan analisis aliran data terhadap kode sensitif di sekitarnya. Ini layak dimasukkan ke tool review saya

  • Keren sekali. Namun sepertinya ada beberapa item yang terlewat. Saya cukup yakin setidaknya ada satu juga di third_party/ffmpeg
    Perbaikan seperti itu biasanya masuk ke upstream terlebih dahulu, jadi bisa sulit dilacak

    • Saya menggunakan komentar yang ditinggalkan Git Watcher pada bug Monorail

  • Kalau melihat kumpulan besar di bawah chrome/browser/ui, jadi terpikir betapa banyaknya use-after-free yang muncul pada data yang manfaat performa dari manajemen memori manualnya tidak terlalu penting. Misalnya [1] adalah masalah seputar lifecycle dialog “pilih file”
    Secara garis besar, untuk kode seperti ini tampaknya lebih baik selalu memakai pointer yang lebih pintar tetapi lebih lambat sebagai pertahanan. Tipe raw_ptr [3] di [2] tampak berusaha membantu hal seperti itu, dan mungkin crash di [2] sebenarnya adalah contoh pertahanan yang berhasil
    Sayangnya, di dalam proyek tidak ada cara yang memadai untuk beralih dialek secara lebih luas, misalnya antara “bagian ini adalah kode yang penting untuk performa dan telah direview dengan cermat” dan “bagian ini tidak sensitif terhadap performa, punya banyak state asinkron, dan mudah salah”. Saya bahkan pernah berpikir bahwa untuk yang terakhir, mencampurkan bahasa terpisah yang memiliki GC hampir layak dilakukan
    Sebagai catatan, saya pernah mengerjakan kode ini lama sekali, dan saya tidak akan terkejut jika lebih dari 0 bug ini dibuat oleh saya
    [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...

    • Itu sama seperti menjelaskan kata kunci unsafe di Rust
      Dan kode semacam ini secara harfiah merupakan salah satu motivasi awal lahirnya Rust. Dari awal, bahasa itu memang dirancang dengan mempertimbangkan implementasi browser
    • Pola menulis bagian yang kritis performa dalam C atau Rust dan membiarkan sisanya di Python kurang lebih adalah contohnya. Kabarnya binding Rust-Python sangat bagus, dan memudahkan menjaga correctness bahkan pada bagian yang kritis performa
      Sebaliknya, memanggil bahasa scripting dari bahasa yang cepat juga memungkinkan. Sekarang semua orang tergila-gila pada wasm, tetapi selama sekitar 20 tahun game komputer sudah memakai lua untuk tujuan itu. Game mungkin merupakan kategori terbesar dari software yang sensitif terhadap performa
    • Karena alasan yang sama, saya ingin menggunakan Oilpan GC di proses browser, tetapi saat itu orang-orang sisi browser sangat menentang penggunaan library blink
      Sebagian besar kode Chrome UI setidaknya ditulis sebagai Web UI. Jika sekarang, menurut saya typescript perlu dipertimbangkan untuk lebih banyak pekerjaan orkestrasi internal browser. Itu strategi yang sudah divalidasi oleh Electron
      Namun arus saat ini tampaknya memang mengarah ke MiraclePtr
    • raw_ptr sebenarnya adalah wrapper smart pointer yang memitigasi sebagian besar eksploitasi use-after-free: https://security.googleblog.com/2022/09/use-after-freedom-mi...

  • Saya sudah memindahkannya ke visualisasi treemap[1]: https://vrp-treemap.surge.sh/
    Library treemap-nya dibuat oleh veteran Chrome, evmar, yang juga ada di thread ini

  • Visualisasi yang sangat rapi. Saat membuka area, CPU memang agak banyak terpakai, tetapi akan bagus jika tim Chrome juga punya sesuatu yang serupa secara internal
    Dengan kata lain, ini terlihat sangat berguna untuk memahami attack surface

  • Ide yang benar-benar keren dan implementasinya juga bagus
    Apakah data mentahnya ada di suatu tempat? Sunburst atau treemap juga layak dicoba

  • Karena ini mungkin turun sampai level diff, rasanya menarik jika diberi bobot berdasarkan jumlah baris kode yang berubah. Misalnya, jika 10 baris berubah di file A dan 1 baris di file B, karena sebagian besar bug ada di file A, apakah 1/11 dari hadiahnya dialokasikan ke file A?
    Atau bisa juga didistribusikan berdasarkan jumlah baris yang berubah / jumlah total baris file. Dengan begitu, kita bisa melihat seberapa banyak bug di tiap file beserta tag nominal uang

    • Kalau begitu, efek yang diinginkan akan muncul. Kode seperti test kemungkinan sangat verbose, sedangkan kerentanan sebenarnya sering kali berakhir hanya pada beberapa karakter

  • Akan bagus juga jika menampilkan rata-rata nilai reward per file pada tiap node

  • Catatan kecil, tetapi sebaiknya file DEPS, AUTHORS, dan BUILD.gn tidak disertakan

  • Bagaimana dengan versi yang dinormalisasi berdasarkan jumlah baris kode?

    • Saya penasaran mengapa bertanya begitu. Menurut saya, dalam software dan keamanan, jumlah baris kode adalah metrik yang tidak terlalu bermakna
    • Atau bisa juga dinormalisasi berdasarkan jumlah kata yang dicurahkan untuk bug tersebut. Itu bisa dipakai sebagai indikator proksi untuk kompleksitas