Chromium बग बाउंटी दिखाने वाला Money Tree Browser

 (lyra.horse)
2 पॉइंट द्वारा GN⁺ 2024-01-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chromium Money Tree Browser Chrome VRP rewards को Chromium repository के directory और file-level modification history से map करता है, ताकि देखा जा सके कि security rewards code tree में कहाँ जमा हुए हैं
  • reward amount को बदली गई files की संख्या से divide करके allocate किया जाता है; अगर $1,000 reward वाले bug fix में 5 files बदली गईं, तो हर file को $200 assign होता है
  • top-level aggregate root $9,873,277 / 10,944 cases, chromium $9,014,838 / 10,218 cases, chrome $2,568,260 / 2,574 cases के रूप में दिखता है
  • chrome/browser/ui/views, extensions, media, safe_browsing, enterprise, Android, net, device, gpu, storage, base, iOS, pdf जैसे कई areas file level पर टूटे हुए दिखते हैं, और V8 भी $858,439 / 726 cases के साथ बड़ा हिस्सा रखता है
  • data और UI के बारे में चेतावनी है कि वे “very very hacked together” स्थिति में हैं, और scope भी नवंबर 2023 की शुरुआत तक है, इसलिए इसे accurate accounting material की बजाय exploration map के रूप में देखना बेहतर है

reward amount को code tree पर बांटकर चढ़ाने का तरीका

  • यह एक browser है जो Chrome VRP bug bounty rewards को Chromium codebase के file और directory tree से जोड़कर दिखाता है
    • अगर कोई specific security fix कई files बदलता है, तो reward amount को files की संख्या से divide करके हर file को assign किया जाता है
    • यह connection ज़्यादा इस काम के लिए है कि “कौन-सा code security rewards के साथ अक्सर बदला गया” यह सरसरी तौर पर देखा जा सके
  • सिर्फ top-level aggregate देखने पर भी Chromium में rewards का बड़ा distribution सामने आता है
    • root: $9,873,277 / 10,944 cases
    • chromium: $9,014,838 / 10,218 cases
    • chrome: $2,568,260 / 2,574 cases
    • chrome/browser: $2,250,643 / 1,920 cases

ध्यान खींचने वाला directory-wise distribution

  • chrome/browser/ui/views के नीचे user UI features के unit-level reward distribution काफ़ी बारीकी से बंटे हुए हैं
    • views: $514,665 / 441 cases
    • tabs: $56,705 / 30 cases
    • eye_dropper: $47,000 / 7 cases
    • bookmarks: $46,697 / 31 cases
    • payments: $43,623 / 60 cases
    • media_router: $36,395 / 12 cases
    • tab_sharing: $30,591 / 9 cases
  • Chrome extensions से जुड़े areas भी बड़े chunks के रूप में बार-बार दिखते हैं
    • extensions: $157,507 / 262 cases
    • extensions/api: $115,471 / 161 cases
    • api/tabs: $42,705 / 48 cases
    • api/debugger: $28,488 / 35 cases
    • api/downloads: $15,225 / 13 cases
    • एक अलग extensions area भी $132,615 / 213 cases के रूप में aggregate हुआ है, जिसमें renderer, guest_view/web_view, file_system API आदि शामिल हैं
  • V8 दिए गए notes में सबसे बड़ा single sub-area लगता है
    • V8 total: $858,439 / 726 cases
    • v8/src: $626,845 / 503 cases
    • v8/test: $209,030 / 195 cases
    • v8/src/compiler: $151,267 / 85 cases
    • v8/src/heap: $91,891 / 64 cases
    • v8/src/builtins: $68,133 / 30 cases
    • v8/test/mjsunit: $164,644 / 113 cases
  • chrome/browser तरफ UI, tabs, autofill, passwords, DevTools, renderer context menu जैसे user touchpoints ध्यान खींचते हैं
    • chrome/browser/autofill: $114,656 / 40 cases
    • chrome/browser/tabs: $92,316 / 25 cases
    • passwords: $51,060 / 10 cases
    • chrome_content_browser_client.cc: $51,512 / 11 cases
    • devtools: $48,255 / 35 cases
    • renderer_context_menu: $47,842 / 16 cases
    • printing: $42,225 / 14 cases
    • payments: $41,252 / 10 cases
  • media, security, enterprise और platform areas में भी बड़ी amounts aggregate हुई हैं
    • media: $134,523 / 65 cases, अलग chrome/browser/media area $89,008 / 34 cases है
    • safe_browsing: $80,161 / 31 cases
    • enterprise: $59,000 / 38 cases
    • ash: $130,389 / 161 cases, एक अलग ash section भी $56,867 / 55 cases के साथ आगे आता है
    • mojo: $112,725 / 26 cases
    • net: $97,558 / 175 cases
    • device: $61,770 / 32 cases
    • gpu: $51,155 / 30 cases
    • storage: $48,303 / 66 cases
    • base: $36,013 / 27 cases
  • Android और iOS में भी अलग platform code में reward distribution बंटता है
    • Android chrome/browser Java, resources और test areas: $94,441 / 159 cases
    • Android Java path: $62,571 / 91 cases
    • Android fullscreen: $18,707 / 11 cases, FullscreenHtmlApiHandler.java $18,540 / 10 cases
    • iOS: $33,625 / 86 cases
    • ios/chrome/browser/web: $11,663 / 4 cases
    • ios/chrome/browser/ui: $9,884 / 24 cases

test files और interpretation में सावधानियां

  • test data और regression test files भी reward distribution में शामिल हैं
    • test: $147,193 / 311 cases
    • test/data: $116,355 / 271 cases
    • test/data/extensions/api_test: $59,337 / 166 cases
    • V8 test/mjsunit/regress: $82,180 / 58 cases
    • V8 test/mjsunit/compiler: $46,233 / 28 cases
    • वजह यह है कि अगर security fix test file changes के साथ record होता है, तो reward amount उन files को भी allocate हो जाती है
  • calculation method सरल है, इसलिए amount को सीधे risk level या vulnerability cause के रूप में पढ़ना मुश्किल है
    • reward amount को “modified files की संख्या” से divide किया जाता है, इसलिए किसी file की amount उस file के अपने risk को सीधे नहीं बताती
    • data और UI “very very hacked together” स्थिति में हैं, और अच्छा UX या accurate data expect न करने की चेतावनी दी गई है
    • data का scope नवंबर 2023 की शुरुआत तक है
  • संबंधित discussion link भी दिया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-07
Hacker News की राय

  • यह काफी हद तक वैसा है जैसा मैं लंबे समय से बनाना चाहता था। किसी खास बदलाव से समस्या पैदा होने की संभावना को, उसी फ़ाइल या फ़ाइल के उसी क्षेत्र में पहले हुए breaking changes के इतिहास के आधार पर निकालना उपयोगी लगता था
    मूल रूप से हर बदलाव को एक risk score देना, हर PR में वह score दिखाना ताकि reviewer जान सके कि किस code को ज़्यादा ध्यान से देखना है, और deployment के समय भी जोखिम वाले बदलावों को highlight करना
    मुश्किल हिस्सा यह है कि ऊपर insert/delete होने से code की जगह ऊपर-नीचे होती रहती है, तब भी उसी code क्षेत्र को लगातार track कैसे किया जाए; जो algorithm सिर्फ line number पर निर्भर करते हैं, वे यहीं टूट जाते हैं
    फिर भी इस example की तरह सिर्फ file level पर करना भी काफी उपयोगी हो सकता है

    • मैं 2 साल से ज़्यादा समय से इसी पर काम कर रहा हूँ। हर बदलाव का static analysis करता हूँ और पूरे monorepo का भी रोज़ analysis करके उसे symbol level पर process करता हूँ
      अधिक risk वाले बदलावों पर ज़्यादा tests चलाए जाते हैं, लेकिन unit tests नहीं, client tests। कभी-कभी चुनने के लिए 100,000 client tests होते हैं, इसलिए उन्हें rank करके सिर्फ एक छोटा subset चलाते हैं
      यह कठिन समस्या है। एक दिलचस्प observation यह है कि causative change में एक-दो causative symbols तो होते हैं, लेकिन उन symbols की connectivity उसी change के non-causative symbols से बहुत मिलती-जुलती होती है
      साथ ही change के बाद transitively बदला हुआ call graph काफी बड़ा होता है; depth 50 भी असामान्य नहीं है। change और test के बीच transitively प्रभावित symbols के overlap के अलावा बहुत सारे उपयोगी signals निकालना मुश्किल लगा
      file level और build target level बहुत मोटे थे, और AST symbol अच्छी तरह काम कर रहा है
    • सिर्फ code नहीं, author को भी देखना चाहिए। मेरे साथ काम कर चुके लोगों में एक व्यक्ति ऐसा था जो हर PR बनाते समय कम से कम एक bug डाल देता था
    • अभी मैं इसी विषय पर किताब पढ़ रहा हूँ: https://pragprog.com/titles/atcrime/your-code-as-a-crime-sce...
    • code location, provenance/author, और पास के sensitive code पर data flow analysis को साथ में देखना अच्छा रहेगा। यह मेरे review tool में डालने लायक है

  • बहुत शानदार। हालांकि लगता है कुछ entries missing हैं। मुझे पूरा भरोसा है कि third_party/ffmpeg में भी कम से कम एक था
    ऐसे fixes अक्सर पहले upstream में जाते हैं, इसलिए उन्हें track करना मुश्किल हो सकता है

    • Monorail bugs में Git Watcher द्वारा छोड़े गए comments का इस्तेमाल कर रहा हूँ

  • chrome/browser/ui के नीचे मौजूद बड़े collection को देखते हुए, यह सोचने पर मजबूर करता है कि ऐसे data में use-after-free कितनी बार आ जाता है जहाँ manual memory management के performance benefits बहुत मायने नहीं रखते। उदाहरण के लिए [1] “file picker” dialog की lifecycle के आसपास की समस्या है
    बड़े परिप्रेक्ष्य में, ऐसे code के लिए बचाव के तौर पर हमेशा थोड़े smart लेकिन धीमे pointers इस्तेमाल करना बेहतर लगता है। [2] में raw_ptr type [3] शायद इसी तरह मदद करने की कोशिश करता दिखा, और शायद [2] का crash असल में defense के सफल होने का example हो सकता है
    अफसोस है कि project के अंदर “यह हिस्सा performance-critical और carefully reviewed code है” और “यह हिस्सा performance-insensitive है और asynchronous state बहुत है, इसलिए गलती की संभावना ज्यादा है” जैसे व्यापक तरीके से dialect switch करने का कोई अच्छा उपाय नहीं है। मैंने कभी-कभी सोचा है कि बाद वाले हिस्से में GC वाली अलग language मिलाकर इस्तेमाल करना लगभग worthwhile हो सकता है
    संदर्भ के तौर पर, मैंने इस code पर बहुत पहले काम किया था, और अगर इन bugs में zero से ज़्यादा मेरे बनाए हुए हों तो मुझे हैरानी नहीं होगी
    [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...

    • यह Rust के unsafe keyword को समझाने जैसा है
      और इस तरह का code सचमुच Rust के बनने की मूल motivations में से एक था। आखिरकार यह language शुरू से browser implementation को ध्यान में रखकर design की गई थी
    • performance-critical हिस्सों को C या Rust में लिखना और बाकी को Python में रखना लगभग इसी का example है। सुना है Rust-Python bindings खास तौर पर अच्छी हैं, और performance-critical हिस्सों में भी correctness संभालना आसान बनाती हैं
      उलटा, fast language से scripting language को call करना भी संभव है। आजकल सब wasm पर उत्साहित हैं, लेकिन computer games लगभग 20 साल से lua को इसी काम के लिए इस्तेमाल करते आ रहे हैं। games शायद performance-sensitive software की सबसे बड़ी category हैं
    • इसी कारण browser process में Oilpan GC इस्तेमाल करना चाहता था, लेकिन उस समय browser side के लोग blink library के इस्तेमाल के सख्त खिलाफ थे
      Chrome UI code का ज्यादातर हिस्सा कम से कम Web UI में लिखा है। आज के समय में, मुझे लगता है browser के अंदर ज्यादा orchestration work के लिए typescript पर विचार करना चाहिए। यह Electron द्वारा validated strategy है
      हालांकि अभी trend सच में MiraclePtr की तरफ दिखता है
    • raw_ptr वास्तव में ज्यादातर use-after-free exploits को mitigate करने वाला smart pointer wrapper है: https://security.googleblog.com/2022/09/use-after-freedom-mi...

  • मैंने इसे treemap visualization में बदलकर देखा[1]: https://vrp-treemap.surge.sh/
    treemap library इस thread में मौजूद Chrome veteran evmar ने बनाई थी

  • बहुत साफ-सुथरा visualization है। sections expand करते समय CPU थोड़ा ज्यादा खाता है, लेकिन अच्छा होगा अगर Chrome team के अंदर भी कुछ ऐसा हो
    यानी attack surface समझने में यह वाकई उपयोगी लगता है

  • सचमुच शानदार idea और implementation भी अच्छा है
    raw data कहीं उपलब्ध है? sunburst या treemap भी try करने लायक हैं

  • यह शायद diff level तक गया होगा, इसलिए बदली गई code lines की संख्या से weight देना दिलचस्प हो सकता है। जैसे file A में 10 lines और file B में 1 line बदली, तो bug का ज्यादातर हिस्सा file A में है, इसलिए bounty का 1/11 file A को मिले?
    या बदली गई lines / file की कुल lines के आधार पर बाँट सकते हैं। तब हर file कितनी bug-heavy है, यह amount tag के साथ दिख सकता है

    • ऐसा करने पर desired effect मिलेगा। tests जैसे code बहुत verbose हो सकते हैं, लेकिन वास्तविक vulnerability अक्सर सिर्फ कुछ characters में खत्म हो जाती है

  • हर node पर file-wise average reward amount भी दिखाना अच्छा रहेगा

  • छोटी-सी nitpick, लेकिन DEPS, AUTHORS, BUILD.gn files को शामिल न करना बेहतर होगा

  • amount को lines of code से normalize करने वाला version कैसा रहेगा?

    • जिज्ञासा है कि आप ऐसा क्यों पूछ रहे हैं। मुझे लगता है software और security में lines of code कोई खास meaningful metric नहीं है
    • या फिर bugs पर खर्च किए गए words की संख्या से normalize कर सकते हैं। इसे complexity के proxy metric की तरह इस्तेमाल किया जा सकता है