Chrome ने WebP heap buffer overflow भेद्यता को ठीक किया

 (chromereleases.googleblog.com)
1 पॉइंट द्वारा GN⁺ 2023-09-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • डेस्कटॉप Chrome Stable और Extended Stable चैनलों के लिए अपडेट जारी किया गया है, जिसमें WebP heap buffer overflow भेद्यता का सुधार शामिल है
  • नए बिल्ड Mac·Linux पर 116.0.5845.187 और Windows पर 116.0.5845.187/.188 हैं, और इन्हें कुछ दिनों से लेकर कुछ हफ्तों तक चरणबद्ध तरीके से लागू किया जाएगा
  • इस रिलीज़ में 1 सुरक्षा सुधार शामिल है, और CVE-2023-4863 को Critical श्रेणी में वर्गीकृत किया गया है
  • Apple SEAR और University of Toronto Munk School के The Citizen Lab ने 6 सितंबर 2023 को इस भेद्यता की रिपोर्ट की
  • Google ने कहा है कि वास्तविक दुरुपयोग के मामले मौजूद हैं, और फिक्स्ड वर्ज़न लागू होने तक बग की विस्तृत जानकारी तक पहुंच सीमित की जा सकती है

डेस्कटॉप Chrome चैनल अपडेट

  • Stable और Extended Stable चैनलों को डेस्कटॉप के लिए नए बिल्ड पर अपडेट किया गया है
  • प्लेटफ़ॉर्म के अनुसार Stable चैनल वर्ज़न इस प्रकार हैं
    • Mac: 116.0.5845.187
    • Linux: 116.0.5845.187
    • Windows: 116.0.5845.187/.188
  • Extended Stable चैनल भी अलग वर्ज़न के रूप में जारी किया गया है
    • Windows: 116.0.5845.188
    • Mac: 116.0.5845.187
  • अपडेट कुछ दिनों से लेकर कुछ हफ्तों में चरणबद्ध तरीके से जारी किया जाएगा
  • इस बिल्ड के पूरे बदलावों की सूची log में देखी जा सकती है

सुरक्षा सुधार: CVE-2023-4863

  • इस रिलीज़ में 1 सुरक्षा सुधार शामिल है
  • बाहरी शोधकर्ताओं के योगदान से किया गया प्रमुख सुधार निम्न भेद्यता है
    • Critical CVE-2023-4863: WebP में heap buffer overflow
    • बग नंबर: 1479274
    • रिपोर्ट करने वाले: Apple Security Engineering and Architecture(SEAR), University of Toronto Munk School का The Citizen Lab
    • रिपोर्ट की तारीख: 6 सितंबर 2023
    • इनाम राशि: $NA

वास्तविक दुरुपयोग और जानकारी प्रकटीकरण पर प्रतिबंध

  • Google ने कहा कि CVE-2023-4863 exploit वास्तविक वातावरण में मौजूद है
  • बग की विस्तृत जानकारी और संबंधित लिंक तक पहुंच तब तक सीमित रखी जा सकती है, जब तक अधिकांश उपयोगकर्ता फिक्स्ड वर्ज़न पर अपडेट नहीं कर लेते
  • यह प्रतिबंध उस स्थिति में भी जारी रह सकता है, यदि वही बग किसी third-party library में मौजूद हो जिस पर अन्य प्रोजेक्ट निर्भर करते हैं और जिसका सुधार अभी नहीं हुआ हो

सुरक्षा बग की पहचान और रिपोर्टिंग के रास्ते

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

1 टिप्पणियां

 
GN⁺ 2023-09-13
Hacker News की रायें

  • Google Chrome में WebP इमेज renderer process में decode होती हैं, इसलिए exploit सफल भी हो जाए तो sandbox के भीतर renderer code execution तक ही सीमित रहता है
    renderer बहुत जटिल होता है, इसलिए हर साल कई exploits मिलते हैं, लेकिन renderer में code execution मिल जाने पर भी सामान्य web page के अधिकारों से बहुत आगे नहीं जाया जा सकता
    खासकर local filesystem की फाइलें देखी या छोड़ी नहीं जा सकतीं, और दूसरे domains की cookies भी नहीं पढ़ी जा सकतीं

    • बेशक, अगर इसके साथ जोड़ने के लिए कोई sandbox escape exploit हो तो बात बदल जाती है
      यह तुरंत सर्वोच्च प्राथमिकता वाली बात नहीं है, लेकिन अगर ऐसा exploit पहले से wild में चल नहीं रहा है, तो भी बहुत असुविधाजनक न होने वाले समय पर जितनी जल्दी हो सके patch कर देना चाहिए
    • आधुनिक internet पर users द्वारा upload की गई images की संख्या बहुत बड़ी है, इसलिए किसी एक website के user context के अधिकार पा लेना भी काफी बड़ा मामला है
      यह किसी एक site या frontend से बंधा नहीं है, इसलिए यह बेहतर/मजबूत XSS जैसा है
    • मैं lossless WebP इस्तेमाल कर रहा हूं और यह PNG से कहीं ज्यादा efficient है
      आह, मैंने गलत thread में reply कर दिया; मैं https://news.ycombinator.com/item?id=37479576 में “jpeg is good enough” का जवाब देना चाहता था
    • क्या इसका मतलब है कि renderer website को जानकारी वापस नहीं भेज सकता?
      और अगर JavaScript बंद भी कर रखा हो, तब भी क्या अचानक website अब भी code execute कर पाएगी?

  • इसलिए अब मुझे browser developers के नए formats अपनाने में धीमे रहने से ज्यादा सहानुभूति होने लगी है
    WebP के JPEG की तुलना में फायदे बहुत बड़े नहीं हैं, मुख्य रूप से transparency वगैरह, और उसमें भी सफलता सीमित रही
    लेकिन अब यह कई high-priority security holes तक पहुंच गया है, और जहां-जहां libwebp linked है वहां अगले एक महीने तक patches deploy करने पड़ेंगे
    मेरा मतलब यह नहीं कि कुछ नया न किया जाए, लेकिन मुझे लगता है developers लागत को काफी ज्यादा underestimate करते हैं

    • Firefox में एक अतिरिक्त sandbox layer है जिसे पूरे process पर नहीं, बल्कि अलग-अलग libraries पर apply किया जा सकता है: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
    • निष्पक्ष रूप से कहें तो अतीत में JPEG decoding libraries की समस्याएं भी malware delivery route के रूप में इस्तेमाल हुई हैं
      यह सही है कि WebP ecosystem कहीं कम mature है, लेकिन मुझे यकीन है कि पुराने format handling code में भी काफी security issues रहे होंगे
      फिर भी तर्क सही है। कुछ ही हफ्ते पहले तक netizens का माहौल था कि JPEG XL को जितनी जल्दी हो सके अपनाना चाहिए, और उसके लिए browser developer को बस “reference decoder code को codebase में शामिल कर देना” होगा, यानी “cost लगभग नहीं है”
    • अगर browsers ने नया format adopt नहीं किया होता, तो क्या ऐसा bug मिलता?
      दूसरे image formats और libraries भी संभवतः bugs से भरे होंगे, लेकिन बड़े software में इस्तेमाल नहीं होते, इसलिए कोई ध्यान नहीं देता
      खासकर उन लोगों के लिए जिनके पास ऐसे bugs ढूंढकर exploit करने की क्षमता है, समय के मुकाबले reward खराब है
      लंबे समय तक इस्तेमाल न होने से bugs कम नहीं होते
    • security hole की वजह नया image format नहीं, बल्कि C/C++ में memory safety की कमी है
      अगर image encoders और decoders, और दूसरे encoders/decoders unsafe languages का इस्तेमाल न करें, तो ऐसे bugs बनने की संभावना कम हो जाती है
    • WebP, JPEG से कहीं ज्यादा complex format है, और complexity का defect density से लगभग सीधा संबंध होता है
      इससे अलग, जरूरत से ज्यादा code को complex बनाने वाली culture और details को ठीक से न समझने वाले developers भी समस्या हैं

  • यह fix आज के Firefox 117.0.1 और Fenix 117.1.0 में शामिल है: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

  • संदर्भ के लिए, image crate में safe Rust में लिखा हुआ WebP decoder implementation है: https://github.com/image-rs/image
    लंबे समय तक यह काफी अधूरा था, लेकिन पिछले साल कई WebP features implement हुए
    Chromium के पास अब Rust dependencies के इस्तेमाल की अनुमति देने वाली policy है, तो क्या Chromium भी इसे adopt करना शुरू कर सकता है?

    • अगर Chrome में “धीमा हो सकता है, फिर भी XYZ library का safe version इस्तेमाल करें” जैसा flag हो, तो मैं performance loss सहकर तुरंत उसे on कर दूंगा
    • 2023 में भी web browser जैसे attack surface वाले विशाल targets में नया C/C++ code लगातार लिखा जा रहा है, यह बात बेतुकी लगती है

  • समस्या वाला मूल commit: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...
    इस bug को ठीक करने वाला commit: https://github.com/webmproject/libwebp/commit/902bc919033134...
    मूल commit ने Huffman decoder को optimize किया था। यह decoder एक जानी-मानी optimization का इस्तेमाल करके N bits पहले से पढ़ता है, और तय करता है कि असल में कितने bits consume करने हैं और कौन-सा symbol decode करना है। या अगर वह कई symbols का N-bit prefix है, तो बाकी bits के लिए किस table को reference करना है, यह तय करता है
    पुराने version में छोटे symbols के लिए lookup table इस्तेमाल होती थी, लेकिन लंबे symbols के लिए graph traversal चाहिए होता था। नए version ने lookup table array का इस्तेमाल करके सुधार किया। हर item में (nbits, value) होता है, जहाँ nbits consume किए जाने वाले bits की संख्या है और value आम तौर पर symbol होता है। लेकिन अगर nbits N से ज़्यादा हो, तो value को table index के रूप में interpret किया जाता है, और nbits को उस subtree में सबसे लंबे code length के रूप में फिर से interpret किया जाता है। इसलिए बाद की हर table में 2^(nbits - N) items होने चाहिए। root table हमेशा 2^N items पर fixed रहती है
    नए version ने symbols की संख्या के आधार पर अधिकतम item count (kTableSize) calculate किया था। जाहिर है Huffman tree untrusted input से आता है, और nbits के बहुत बड़ा हो जाने की कल्पना करना आसान है। VP8 Lossless खास तौर पर अधिकतम 15 bits तक allow करता है, इसलिए अगर सभी LUTs अपने-अपने अलग auxiliary table पर map हों, तो संभव अधिकतम table 2^N + 2^15 items की हो जाती है। इसे बनाने के लिए भी बहुत ज़्यादा symbols की जरूरत नहीं होती; हर table के लिए 16-N symbols काफी हैं
    दिलचस्प बात यह है कि code में सिर्फ table size calculate करने वाला mode (root_table == NULL के साथ VP8LBuildHuffmanTable call) मौजूद था, लेकिन किसी वजह से उसका इस्तेमाल नहीं हुआ और fixed maximum size assume कर लिया गया। इसलिए अगर Huffman tree को item count maximize करने के लिए बनाया जाए, तो allocated area से आगे write हो जाता है
    यह क्यों हुआ, समझ आता है। Huffman decoding stage कई compression formats में सबसे ज्यादा compute-heavy हिस्सों में से एक होता है, इसलिए छोटा improvement भी मायने रखता है। ऊपर वाली optimization well-known है, लेकिन लंबे code path आम तौर पर rare माने जाते हैं, इसलिए उनकी optimization priority कम रही। मूल commit message ने इस assumption को rebut किया और merge हो पाया। memory-safe language इस समस्या को रोक पाती या नहीं, यह भी पक्का कहना मुश्किल है। क्योंकि यह उन rare मामलों में से है जहाँ overflow checks को actively avoid करने का मन होता है
    [1] हालांकि memory corruption tight loop में नहीं, बल्कि table construction के दौरान होती है, इसलिए partial overflow checks काफी मददगार होते। actual fix ने ReadSymbol function को बिल्कुल नहीं बदला। फिर भी tight loop की safety को justify करना जरूरी है, और गलत justification सब कुछ बिगाड़ सकती है

    • इस component को WUFFS में लिखा जाना चाहिए था
      अगर यह बात सही है कि bounds checks की जरूरत नहीं है, तो ठीक है। WUFFS runtime bounds checks emit नहीं करता
      लेकिन अगर software, इस बार की तरह, bounds से बाहर जाकर गलत है, तो WUFFS में यह compile नहीं होगा
      आप सोच सकते हैं कि “यह असंभव है”, और अगर WUFFS एक general-purpose programming language होती तो यह सही बात होती। Rice's theorem के अनुसार कोई भी non-trivial semantic property undecidable होती है
      सौभाग्य से WUFFS general-purpose language नहीं है। ज्यादातर software WUFFS में नहीं लिखे जा सकते, लेकिन image codecs लिखे जा सकते हैं
    • C programmer के तौर पर काम छोड़े 10 साल से ज्यादा हो गए हैं और पहले भी मैं बहुत अच्छा नहीं था, लेकिन explanation देखकर मैं सहमत हूँ कि bounds checks इस problem को पकड़ लेते
      हालांकि यह भी सोचता हूँ कि क्या इस तरह की problem पकड़ने वाली automated tests बनाई जा सकती थीं
      जिस code पर मैं personally काम करता हूँ, उसमें कुछ calculations को अलग functions में निकालकर independently test किया जा सकता है। यहाँ performance की वजह से मुश्किल रहा होगा, लेकिन पक्का नहीं कह सकता

  • BuildHuffmanTable में out-of-bounds write का fix
    https://github.com/webmproject/libwebp/commit/902bc919033134...

    • इसके तुरंत बाद oss-fuzz से जुड़ा एक और commit होना भी दिलचस्प है: https://github.com/webmproject/libwebp/commit/95ea5226c87044...
      इसका मतलब हो सकता है कि Google ने यह bug खोजने के बाद libwebp के लिए fuzzer को optimize किया, और इसलिए अब और bugs मिल रहे हैं

  • लगता है इसे Apple ने report किया था, और यह इस security update से बहुत मिलता-जुलता दिखता है: https://support.apple.com/en-us/HT213906

    • इसे Apple और “UoT Munk School के Citizen Lab” ने report किया था, और linked page पर ठीक यही लिखा है
      इसलिए यह काफी likely लगता है। हो सकता है Apple internally ImageIO में libwebp इस्तेमाल कर रहा हो, या उसने मिलती-जुलती गलती की हो
    • पिछले हफ्ते और अभी की reaction कितनी अलग है, यह देखना दिलचस्प है

  • image codecs में vulnerabilities का लंबा इतिहास रहा है
    actual image processing इतनी साफ linear code हो सकती है कि उसे memory-safe FORTRAN IV में भी लिखा जा सके, लेकिन compression आते ही variable-length data structures, pointer chasing वगैरह बहुत बढ़ जाते हैं
    ऊपर से इसे तेजी से run कराने का pressure भी जुड़ जाता है

  • क्या इसका Electron पर भी असर है? अगर हाँ, तो किस version पर?

  • इसे practically exploit करने का कोई रास्ता है?
    सुना है कि 64-bit पर heap spray अब practical नहीं रहा
    क्या memory में ऐसा कोई predictable object है जिसे overwrite किया जा सके?

    • चूँकि इसे पहले से ही wild में exploit किया जा रहा है, तो जवाब हाँ है
      64-bit पर भी kernel exploits में heap spray अब भी साफ़ तौर पर इस्तेमाल होता है। V8 exploits में लोग कौन-से primitives इस्तेमाल करते हैं, यह मुझे ठीक से नहीं पता