WebP 0day का विश्लेषण

 (blog.isosceles.com)
2 पॉइंट द्वारा GN⁺ 2023-09-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Chrome के stable update में शामिल एकमात्र security fix CVE-2023-4863 WebP image library में heap buffer overflow है, और Google ने बताया कि इसका exploit पहले से वास्तविक वातावरण में मौजूद है
  • Apple SEAR की 6 सितंबर 2023 की रिपोर्ट, Apple के CVE-2023-41064, और Citizen Lab के BLASTPASS संकेतों को साथ देखने पर यह उसी bug होने की प्रबल संभावना बनती है
  • विश्लेषण के अनुसार यह कमजोरी WebP lossless compression VP8L में Huffman table बनाते समय precomputed buffer size से बाहर write संभव होने की समस्या थी
  • सामान्य fuzzing के लिए इसे पकड़ना कठिन था क्योंकि इसके लिए कई maximum-size Huffman tables और एक खास invalid table को क्रम से बनाना पड़ता था, यानी कठिन trigger condition थी
  • upstream libwebp patch पर्याप्त दिखता है, लेकिन libwebp browser, operating system और apps में व्यापक रूप से इस्तेमाल होता है, इसलिए patch rollout और sandboxing महत्वपूर्ण हैं

Chrome patch का BLASTPASS से जुड़ाव क्यों है

  • Google ने सितंबर 2023 की शुरुआत में Chrome stable update में Apple Security Engineering and Architecture(SEAR) द्वारा रिपोर्ट की गई CVE-2023-4863 को fix किया
    • यह कमजोरी WebP image library में heap buffer overflow है
    • Google ने कहा कि उसे पता है कि “CVE-2023-4863 का exploit वास्तविक वातावरण में मौजूद है”
  • इसी समय Citizen Lab ने Washington DC स्थित एक civil society organization से जुड़े व्यक्ति के iPhone में संदिग्ध गतिविधि पाई
    • BLASTPASS iMessage zero-click zero-day exploit से जुड़ा मामला है, जिसका उपयोग NSO Group के Pegasus spyware को फैलाने में हुआ
    • Citizen Lab ने अपनी technical analysis Apple को देने के बाद, Apple ने 7 सितंबर की security advisory में दो CVE जारी किए
  • Apple का पहला CVE CVE-2023-41061 इस बात से जुड़ता है कि PassKit attachment के साथ image exploit जोड़कर iMessage के BlastDoor sandbox को bypass किया गया
    • ऐसा लगता है कि malicious image को किसी दूसरे non-sandboxed process में process किया गया
  • दूसरा CVE CVE-2023-41064 Apple ImageIO में buffer overflow vulnerability है
    • ImageIO Apple का image parsing framework है, जो कई image formats की पहचान कर सही decoder से जोड़ता है
    • तकनीकी विवरण न होने के कारण यह पुष्टि नहीं हो सकी कि CVE-2023-41064 किस image format को प्रभावित करता है
  • Apple ने हाल में ImageIO में WebP support जोड़ा था, Apple security team ने 6 सितंबर को Chrome को WebP vulnerability report की, और Google ने 5 दिनों के भीतर emergency patch जारी कर इसे actively exploited के रूप में चिह्नित किया; इन कारणों से BLASTPASS और CVE-2023-4863 के एक ही bug होने की संभावना अधिक है

libwebp patch ने vulnerability का स्थान कैसे दिखाया

  • Chrome security advisory के bug ID और libwebp open source commit को मिलाने पर Fix OOB write in BuildHuffmanTable patch को CVE-2023-4863 से जोड़ा जा सकता है
    • यह patch Apple की रिपोर्ट के अगले दिन, 7 सितंबर 2023 को बनाया गया
  • यह vulnerability WebP के lossless compression support VP8L में है
    • WebP lossless compression pixels को 100% सटीकता से store और restore करने के लिए Huffman coding का उपयोग करता है
    • आधुनिक implementation conceptual tree structure की जगह tables का उपयोग करके decoding को optimize करती है
  • vulnerable version fixed tables से मिले precomputed buffer size के आधार पर memory allocate करता था, और उसी space में सीधे Huffman table बनाता था
    • नए version में पहले pass में output table के लिए आवश्यक total size calculate किया जाता है, लेकिन actual write नहीं होती
    • अगर total size precomputed buffer से बड़ा हो, तो अब बड़ी allocation बनाई जाती है
  • मुख्य flow src/dec/vp8l_dec.c के ReadHuffmanCodes में allocate होने वाले huffman_tables और ReadHuffmanCode के अंदर VP8LBuildHuffmanTable/BuildHuffmanTable calls से जुड़ा है
    • Huffman tables पाँच segments में बँटे होते हैं, जिनकी alphabet sizes अलग-अलग होती हैं
    • overflow पैदा करने के लिए इन पाँचों tables को बहुत सावधानी से बनाना पड़ता है

trigger file बनाने की प्रक्रिया

  • WebP lossless compression input pixels की frequency analysis के आधार पर अक्सर आने वाले values को छोटे bit sequences और कम आने वाले values को लंबे bit sequences देता है
    • code इस तरह बनाए जाते हैं कि decoder हमेशा bit sequence lengths को अलग-अलग पहचान सके
    • compressed image में mapping को दोबारा बनाने के लिए statistical information और code assignment information शामिल करनी पड़ती है
  • WebP file size घटाने के लिए Huffman table को भी Huffman coding से compress करता है
    • इसी संरचना के कारण vulnerability का analysis और trigger बनाना जटिल हो जाता है
  • @mistymntncop ने ऐसा harness code दिया जो arbitrary Huffman coding data, यानी code lengths, के साथ valid-format WebP बना सकता है
    • इस harness से target BuildHuffmanTable call को arbitrary code_lengths array दिया जा सका
  • manual experiments में BuildHuffmanTable के अंदर histogram, num_open, num_nodes, और ReplicateValue की start position को track करने वाले key value के बीच interaction बहुत जटिल था
    • count[0] से count[8] तक का root table सीधे total_size पर बड़ा असर नहीं डालता, लेकिन बाद की internal state बदल सकता है
    • count[9] से count[15] तक के second level tables अंतिम total_size को सीधे प्रभावित करते हैं
  • Mark Adler का enough.c alphabet size, root table size, और maximum code length के लिए संभव maximum Huffman tree lookup table का histogram output करता है
    • libwebp के kTableSize पर टिप्पणी में लिखा है कि यह मान इसी tool से calculate किए गए हैं
    • इस tool से precomputed buffer size को reproduce किया जा सका, और @mistymntncop के tool से यह भी पुष्टि हुई कि “enough” द्वारा बनाए गए code lengths huffman_tables allocation को 100% तक भर देते हैं

वास्तविक overflow किन शर्तों में होता है

  • enough tool valid और complete codes के लिए maximum value calculate करता है
    • छोटे tables में से एक, symbol size 40, root table 8-bit, और maximum code length 15 के लिए maximum size 410 है
    • BuildHuffmanTable जिन codes को valid मानता है, उनमें 410 से बड़ा size बनाने वाला कोई मामला नहीं मिला
  • overflow केवल valid Huffman tree से नहीं, बल्कि अंतिम चरण में invalid Huffman tree डालने पर होता है
    • पहले 4 valid Huffman trees से maximum-size output table बनाया जाता है
    • अंतिम table में invalid Huffman tree डालने पर final consistency check से पहले ReplicateValue bounds के बाहर write कर सकता है
  • reproduction के लिए vulnerable libwebp commit 7ba44f80f3b94fc0138db159afea770ef06532a0 checkout करके AddressSanitizer चालू किया जाता है, फिर @mistymntncop के PoC code से bad.webp बनाकर dwebp से decode किया जाता है
    • AddressSanitizer BuildHuffmanTable में heap-buffer-overflow report करता है
    • report के अनुसार write 11816-byte region के ठीक बाद वाले address पर होती है
  • huffman_tables को overflow कराने वाले कई inputs मौजूद हैं
    • मिले हुए code lengths में ऐसे मामले भी हैं जो huffman_tables allocation के अंत से 400 bytes आगे तक write करते हैं
    • write होने वाले value पर control आंशिक ही हो, तब भी exploit संभव दिखता है
  • invalid input का Huffman tree आंशिक रूप से unbalanced है, और unbalanced branch के एक हिस्से में ऐसे बहुत से internal nodes होते हैं जिनके कोई children नहीं होते
    • यह संरचना ऐसे key indexes बनाती है जिन तक valid tree से पहुँचना संभव नहीं

patch overflow को कैसे रोकता है

  • शुरू में यह लगा कि patch आवश्यक size के अनुसार buffer को dynamically बढ़ाकर heap overflow रोकता है
  • वास्तव में patched version का पहला pass BuildHuffmanTable चलाते हुए आवश्यक total size calculate करता है, लेकिन table में write नहीं करता
    • जो invalid input overflow कराता था, उसमें पहले pass के दौरान BuildHuffmanTable fail होकर 0 return करता है
    • पहले pass में write नहीं होने के कारण invalid tree partial process होने पर भी out-of-bounds write नहीं होती
  • valid और complete codes में ऐसा कोई मामला नहीं मिला जो वही overflow कराए, इसलिए यह patch पर्याप्त दिखता है

fuzzing के लिए इसे पकड़ना कठिन क्यों था

  • libwebp लंबे समय से Google OSS-Fuzz में fuzz हो रहा था, और WebP lossless support भी व्यापक रूप से fuzz किया जा रहा था
  • मुख्य कठिनाई यह थी कि format भी जटिल था और trigger conditions भी
    • अरबों संभावनाओं में से alphabet size 280 और 256 के लिए पहले 4 maximum-size Huffman tables बनानी पड़ती हैं
    • इसके बाद alphabet size 40 के लिए बहुत खास आकार का invalid Huffman table बनाना पड़ता है
    • किसी भी चरण में 1 bit भी गलत होने पर image decoder error देकर सुरक्षित रूप से बंद हो जाता है
  • Google ने WebP 0day fix के बाद WebP Huffman routines के लिए dedicated नया fuzzer जारी किया
    • उस fuzzer को चलाने पर भी CVE-2023-4863 नहीं मिला
  • standard bit-flip mutation, code coverage feedback loop, और AFL++ के CmpLog जैसे input-state आधारित तरीकों से भी इस extreme state तक पहुँचने के लिए जरूरी intermediate steps पार करना कठिन है
    • Quarkslab के TritonDSE जैसी dynamic symbolic execution techniques में संभावना हो सकती है, हालांकि इसकी पुष्टि नहीं हुई
  • यह FreeType की Load_SBit_Png vulnerability जैसी प्रकृति की नहीं है
    • Load_SBit_Png इसलिए नहीं मिली थी क्योंकि fuzzing harness API usage pattern को पर्याप्त रूप से reflect नहीं कर रहा था
    • CVE-2023-4863 में harness की कमी से अधिक, vulnerability की अपनी constraints के कारण fuzzing कठिन थी

प्रभाव का दायरा और response status

  • Citizen Lab ने वास्तविक वातावरण में उपयोग किए गए advanced exploit को capture किया, और Apple तथा Chrome ने कुछ ही दिनों में अरबों users तक updates पहुँचाए प्रतीत होते हैं
  • उस समय Android पर प्रभाव की संभावना अभी बाकी थी
    • Android का BitmapFactory Apple ImageIO की तरह image decoding संभालता है और libwebp को support करता है
    • उस समय Android security advisory में CVE-2023-4863 fix शामिल नहीं था, लेकिन fix AOSP में merge हो चुका था
    • यदि Android प्रभावित होता, तो Signal या WhatsApp जैसे apps में remote exploit की संभावना बन सकती थी
    • उम्मीद थी कि अक्टूबर security advisory में यह fix आएगा
  • upstream libwebp patch सही तरीके से लागू किया गया लगता है और जहाँ जरूरत है वहाँ फैल रहा है
  • libwebp बहुत जगह इस्तेमाल होता है, इसलिए patch पूरी तरह फैलने में समय लग सकता है
  • image decoding जैसी zero-click remote exploit attack surface के करीब आने वाले complex parser code की security केवल fuzzing से सुनिश्चित करना कठिन है, और proactive source code review तथा उचित sandboxing में निवेश आवश्यक है

तकनीकी जानकारी के खुलासे की असमानता

  • जब vendor पर्याप्त technical details जारी नहीं करते, तो defenders के लिए vulnerability impact को verify करना कठिन हो जाता है
  • attackers के पास N-day vulnerabilities को track और exploit करने की मजबूत प्रेरणा होती है, और details न होने पर भी वे बहुत धीमे नहीं पड़ते
  • defenders के पास अक्सर इस स्तर की technical analysis करने के लिए पर्याप्त resources नहीं होते
  • अगर बुनियादी attack behavior information भी छिपा दी जाए, तो ऐसी असमानता पैदा होती है जिसमें attackers के पास defenders से अधिक vulnerability और exploit insight होती है

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

1 टिप्पणियां

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

  • यह बग 2015 के Timsort बग से सबसे ज़्यादा मिलता-जुलता दिखता है [1]
    Timsort CPython से निकला एक स्मार्ट hybrid sorting algorithm है, और OpenJDK समेत कई implementations ने इसे लगभग source-level translation की तरह अपना लिया था। यह sorted runs का stack बनाए रखता है, और एक प्रमाण था कि संरचनात्मक रूप से संभव अधिकतम stack size के लिए पर्याप्त रूप से छोटा finite upper bound है, लेकिन मूल CPython implementation उस प्रमाण से ठीक-ठीक मेल नहीं खाता था, इसलिए दुर्लभ मामलों में stack overflow संभव था। इसलिए CPython में यह एक गंभीर security bug था, लेकिन Java में उस स्थिति में exception throw होता था, इसलिए OpenJDK में यह उसी तरह की security problem नहीं था
    इसी तरह यह WebP बग भी इसलिए हुआ कि maximum table size औपचारिक रूप से prove किया गया था, लेकिन actual source code में डाली गई value उससे मेल नहीं खाती थी। ऐसे bugs को verify करना और review करना दोनों मुश्किल है। Proof मौजूद है और source भी उस proof से मेल खाता लगता है, इसलिए आसानी से लगता है कि सब ठीक है। यह accessible formal verification और memory-safe languages के उपयोग की कड़ी ज़रूरत का संकेत लगता है, मानव review से भी ज़्यादा। Type system को भी formal verification के एक कमजोर रूप के तौर पर देखा जा सकता है
    [1] http://envisage-project.eu/wp-content/uploads/2015/02/sortin...

    • इस तरह का काम performance-critical होता है, इसलिए इसे खास तौर पर WUFFS में लिखा जाना चाहिए। WUFFS Java की तरह boundary checks emit नहीं करता, या Rust की तरह runtime पर index range में है या नहीं यह अस्पष्ट होने पर check नहीं करता; बल्कि अगर tool यह verify नहीं कर पाता कि index range में है, तो वह program को ही reject कर देता है
      https://github.com/google/wuffs
      उसी तरह के checks explicit रूप से लिखकर इस requirement को satisfy किया जा सकता है, लेकिन अगर आप मान रहे थे कि high-performance software होने के कारण checks की ज़रूरत नहीं है, तो WUFFS tool जहां code accept नहीं करेगा, वहां आपके गलत होने का पता चलने की संभावना बहुत ज़्यादा है। यह full formal verification से कमजोर है, लेकिन program safety के लक्ष्य के लिए बड़ा improvement है और किसी इंसान के “LGTM” कहने से कहीं बेहतर है
    • “Type system को कमजोर formal verification के रूप में देखा जा सकता है” यह type system के प्रकार पर निर्भर करता है। मैंने हाल ही में Idris देखा, और लगता है कि यह general-purpose programming language होने के साथ-साथ proofs के लिए भी इस्तेमाल किया जा सकता है

  • इस लेख में “अभी क्या patch करना चाहिए” के अलावा भी कुछ दिलचस्प बातें थीं। Vulnerability की जगह और fix पता होने पर भी exploit PoC reproduce करने में काफी काम लग सकता है, और image decoder के अंदर lossless decompressor fuzzing के खिलाफ काफी मजबूत हो सकता है। Security वाले लोगों के लिए यह शायद obvious हो, लेकिन non-expert के तौर पर पढ़ना दिलचस्प था

    • ऐसी समस्या का हल fuzzing नहीं, बल्कि उस code को tumor की तरह काटकर निकाल देना है। अगर इसकी वजह से OS या browser के कई हिस्से टूटते हैं, तो problem format को handle करने वाला एक strongly sandboxed, memory-safe format converter लिख देना चाहिए। कुछ edge cases में असुविधाजनक iPhone या browser मुझे ऐसे code से बेहतर लगता है जिसमें, fuzzing हो या न हो, vulnerabilities लगभग guaranteed हैं। यह optimistic बात है, लेकिन मुझे यकीन है कि यह कहानी यहीं खत्म नहीं होगी

  • कुछ सवाल हैं जिनका साफ जवाब नहीं मिल पा रहा। 1) Brave जैसे दूसरे Chrome-based browsers भी प्रभावित हैं? 2) Desktop Chrome भी प्रभावित है, या यह सिर्फ mobile की समस्या है? 3) मैंने WebP के बारे में कभी क्यों नहीं सुना? क्या मैं दुनिया से कटा हुआ था, या यह mobile-first technology है?

    • अच्छे सवाल हैं। दूसरे Chromium-based browsers भी इस bug से प्रभावित होने की काफी संभावना है। Brave जैसे कई browsers Chromium security updates को अच्छी तरह follow करते हैं, लेकिन Samsung SBrowser जैसे कुछ काफी पीछे रह जाते हैं
      Desktop Chrome भी Linux और Windows दोनों पर प्रभावित था। Chrome अपनी libwebp bundle करता है, इसलिए अगर Linux distribution ने अभी patch नहीं किया हो, तब भी Chrome updated है तो कम से कम browser attack के लिहाज से ठीक है
      प्रमुख browsers और operating systems आश्चर्यजनक रूप से कई अपरिचित image formats support करते हैं। उदाहरण के लिए, MacOS में KTX2(Khronos Texture Container) और Android में DNG(Adobe Digital Negative) load किया जा सकता है। Attackers के explore करने के लिए कई रोचक और high-exposure attack surfaces हैं
    • WebP support करने वाली हर चीज़ प्रभावित है। इसमें सिर्फ Chrome या Electron नहीं, बल्कि सभी browsers, desktop और mobile, और non-browser software भी शामिल हैं। Image viewers, graphics programs, email clients, यहां तक कि thumbnails दिखाने वाले file managers भी इसमें आते हैं
      Bug codec library में है, और WebP का ecosystem implementation के लिहाज से practically single-library है, इसलिए सभी वही library इस्तेमाल करते हैं और सभी को patch करना होगा
      Google ने 10 साल पहले WebP को push किया था, लेकिन लंबे समय तक यह Chrome-only रहा, इसलिए ज्यादा traction नहीं मिला। यह ठीक से standardize भी नहीं हुआ, हालांकि open source है। Low-quality images में यह JPEG से बेहतर compress करता है, लेकिन high-quality images में colors bleed और blur होने की tendency है। विडंबना यह है कि जब WebP widely supported होना शुरू हुआ, तब तक AVIF और JPEG XL की वजह से यह technically obsolete होने लगा था
    • लगभग निश्चित है कि आपने WebP images download करके देखी होंगी, लेकिन कई websites एक ही URL से अलग-अलग formats serve करती हैं, इसलिए शायद आपको पता नहीं चला। आम तौर पर HTTP reverse proxy format को automatically convert कर देता है, इसलिए पिछले 10 साल के browser में download file extension “.png” जैसा दिखे तब भी आपको WebP मिल सकता है। Modern image editors सभी WebP support करते हैं, इसलिए फर्क notice करना मुश्किल है
    • WebP बहुत पहले से desktop Chrome में supported था। JPEG replacement formats दर्जनों आए और गायब हो गए, और WebP में मुख्य बात यह थी कि इसके पीछे Google का प्रभाव था। Google ने Duck/On2 को acquire किया, जिससे उसे कई video compression technologies मिलीं, और उनमें से कुछ WebP में गईं
    • सभी browsers प्रभावित हैं, और Firefox ने भी security update जारी किया है। WebP JPEG replacement के रूप में लोकप्रिय हो रहा है, इसलिए web से download की जाने वाली images increasingly WebP के रूप में दिखती हैं; यह हैरानी की बात है कि आप अब तक इससे नहीं टकराए

  • अगर कोई Android डिवाइस सपोर्ट खत्म होने की स्थिति में है, तो क्या वह अभी असल में चल रहे 0-क्लिक एक्सप्लॉइट के संपर्क में है? या सिर्फ SMS ऐप, Chrome, WhatsApp, Signal वगैरह अपडेट करने से मुख्य इनपुट रास्ते पर्याप्त रूप से बंद हो जाते हैं?

    • यह पक्का नहीं है कि इस बग के लिए Android एक्सप्लॉइट पहले से मौजूद है या नहीं। मूल एक्सप्लॉइट iMessage के जरिए iOS के लिए था, लेकिन इसके पहले से विकसित हो जाने की संभावना काफी ज्यादा है। आजकल Android के लिए ऐसे एक्सप्लॉइट की मांग बहुत ज्यादा है, और हाल में इनके लिए बेहद ऊंची कीमतों की चर्चा सुनी है
      सपोर्ट खत्म हो चुके डिवाइसों पर भी Chrome अपडेट करने से Chrome वाली समस्या ठीक हो जाती है, लेकिन Signal या WhatsApp जैसे ऐप्स को ठीक करने के लिए Android OS upgrade की जरूरत होती है। Chrome अपना libwebp बंडल करता है, लेकिन messaging apps और Gmail जैसे ज्यादा exposed apps इमेज दिखाने के लिए OS द्वारा दिए गए interfaces का इस्तेमाल करते हैं। जिन Android डिवाइसों को security support मिल रहा है, उनके लिए अक्टूबर की शुरुआत से updates आने की उम्मीद है
    • प्लेटफॉर्म की image decoding library उन system modules में से एक होनी चाहिए जो Play Store के जरिए update होते हैं। क्या कोई पुष्टि कर सकता है कि वास्तव में ऐसा है या नहीं?
    • कुछ messaging apps में received images को auto-download या preview न करने का विकल्प होता है, इसलिए वह setting चालू करना एक अच्छा कदम हो सकता है। Google Messages में यह feature है
    • अगर Android security updates के दायरे से बाहर हो चुका है, तो चिंता की बात सिर्फ यही एक नहीं है। मैं पहले उन चीजों की चिंता करूंगा जिनका exploit करना ज्यादा आसान है
    • iOS में iMessage के पास high privileges होते हैं, इसलिए यह खास तौर पर बड़ी समस्या है। Android में ऐसे सभी apps sandbox के अंदर होते हैं

  • “असल में huffman_tables को overflow कराने वाले inputs बहुत हैं” यह ज्यादा सामान्य समस्या जैसा लगता है। संरचना ऐसी है कि software A lookup table B बनाता है, और वह table input data stream को process करने में इस्तेमाल होती है
    अब security या correctness की थोड़ी भी परवाह करने वाले developer को दो में से एक बात सुनिश्चित करनी होगी। A) software इस तरह लिखा गया हो कि कोई भी input data lookup table का misuse न कर सके या उसे fail न करा सके, या B) इसका इस्तेमाल केवल controlled environment में हो, जैसे point-to-point communication जहां दोनों communicating parties trusted हों, और यह guarantee हो कि stream कभी lookup table का misuse नहीं करेगी या abnormal behavior पैदा नहीं करेगी
    B छोटे group या office के अलावा लगभग असंभव है, और internet scale पर तो सचमुच असंभव है, इसलिए अंततः A ही बचता है। आगे की software engineering में generalized best practice यह होगी कि अगर किसी भी वजह से lookup table इस्तेमाल की जाती है, तो developer यह सुनिश्चित करे कि वह table सभी data types पर सही तरह काम करे, या invalid data को table तक पहुंचने से पहले detect करके उचित तरीके से handle करे
    अगर मैं serious security researcher होता और समय होता, तो past में lookup tables से किसी भी तरह संबंधित सभी security vulnerabilities की list इकट्ठी करके एक-एक पढ़ता और commonalities की तुलना करता। शायद कोई pattern मिलेगा। फिर data streams में lookup tables इस्तेमाल करने वाले सभी software को छानकर vulnerabilities audit करता, लेकिन यह किसी एक व्यक्ति के जीवनभर का काम नहीं, team sport है

  • NSO को यह bug खोजने में source code公开 ने कितनी मदद की होगी? अगर code केवल binary blob होता, तो क्या modern decompilers ही code को समझने और ऐसे obscure bug को खोजने के लिए पर्याप्त होते?

    • Blob attackers को नहीं रोकता। सफल exploit लिखने के लिए वैसे भी compiled binary को समझना पड़ता है

  • हैरानी की बात है कि यह image format का “new” हिस्सा नहीं है। Huffman compression 70 साल से ज्यादा पुराना है, और canonical Huffman भी उससे बस कुछ दशक कम पुराना है; यहां तक कि JPEG भी Huffman इस्तेमाल करता है। यह दशकों पुरानी तकनीक है और implementation methods पर अनगिनत लेख हैं, इसलिए अब तक तो कई implementations में इसके bugs साफ हो जाने चाहिए थे
    मैंने पहले JPEG specification पढ़ी थी और decoder भी लिखा था, इसलिए WebP specification देखी: https://developers.google.com/speed/webp/docs/webp_lossless_...
    महत्वपूर्ण बात section 6 में है। पहली नजर में जो दिखता है वह यह है कि code कैसे बनता है, यह JPEG specification के विपरीत स्पष्ट नहीं है। JPEG में process के बारे में पढ़ने में आसान flowcharts बहुत हैं। WebP LZH/deflate(zlib) जैसा दिखता है, और “specification” से ज्यादा comments वाले कुछ source code snippets का collection लगता है
    GIF, JPEG, PNG के बाद WebP decoder भी लिखने का मन था, लेकिन ऊपर की “specification” देखकर लगता है मानो यह लगभग न लिखने को कह रही हो

    • मैं मानता हूं कि specification में examples सचमुच कम हैं, लेकिन इसमें साफ लिखा है कि canonical Huffman tree इस्तेमाल होता है, इसलिए केवल code lengths भेजना काफी है। मुझे लगता है कि actual tree को specify करने के लिए यह पर्याप्त रूप से स्पष्ट है। reverse lexicographic order इस्तेमाल करने वाला canonical Huffman implementation शायद नहीं होगा
      Huffman tree implementations में कई अलग-अलग trade-offs होते हैं, इसलिए यह कहना मुश्किल है कि पुरानी तकनीक होने से सारे bugs साफ हो गए होंगे। Charles Bloom ने कहा था कि 1997 का Huffman optimization पर निर्णायक paper [1] भी 2010 तक ज्यादा जाना-पहचाना नहीं था, और कई optimizations फिर से खोजे गए और फिर भुला दिए गए। इसलिए inefficient implementations बहुत होने की संभावना है
      [1] https://cbloomrants.blogspot.com/2010/08/08-12-10-lost-huffm...
    • अगर reference code चाहिए, तो https://github.com/golang/image/tree/master/vp8l पर 1200 lines से कम का WebP-Lossless decoder है

  • अब तो लगता है कि images देखने तक में security की चिंता किए बिना काम नहीं चलता

    • अगर software vendor images render करते समय थोड़ी धीमी library इस्तेमाल करे, तो सबसे गंभीर security concern यानी remote code execution से बचा जा सकता है। C में लिखी libraries से बचने पर remote code execution लगभग खत्म किया जा सकता है और users भी ज्यादा सुरक्षित रहेंगे
    • हो सकता है मैं गलत याद कर रहा हूं, लेकिन PNG और JPG में भी कम से कम एक बार ऐसा कुछ हुआ था
      यह unsafe language C इस्तेमाल करने से होने वाली typical growing pains जैसा लगता है। Browser speed की वजह से इसका आकर्षण समझ आता है, लेकिन उम्मीद है कि industry उस तरीके से बाहर निकलेगी जो C इस्तेमाल शुरू करने के बाद से दोहराई जाती रही वही गलतियां बढ़ावा देता है
      यह तेज होने के कारण rivets की जगह self-tapping screws से पुल बनाने जैसा है। जब पुल झुकने लगे, तो और screws लगा दो—ऐसी सोच

  • “अच्छी बात यह है कि Apple और Chrome ने इस समस्या की तात्कालिकता के हिसाब से शानदार प्रतिक्रिया दी” कहना समझना मुश्किल है। इस समस्या को सिर्फ Chrome वाली श्रेणी में डालने वाला Google ही था। पिछले 7 दिनों को ही देखें तो सभी प्रमुख Linux distributions को अपडेट push करने पड़े, और Red Hat ने इसे 9.6 स्कोर दिया। 1 अरब से ज़्यादा बार pull की गई Python Docker images, Puppeteer, WordPress, Node.js वगैरह भी प्रभावित हुए, लेकिन CRBug अभी भी private है
    BleepingComputer जैसी साइटों ने बिना जांच के जो दिखा वही रिपोर्ट किया, और इस issue को third party की तरह treat करने वाली कई security firms ने भी ऐसा ही किया। जब आपको पता हो कि सामने वाले ने due diligence नहीं किया, तो trust बनाना सचमुच मुश्किल होता है
    Adam Caudill ने 1Password के शुरुआती patch के उदाहरण के साथ “Whose CVE is it anyway?”[0] नाम का अच्छा लेख लिखा, और उसमें यहां बताई जा रही समस्या को ठीक से पकड़ा है। Citizen Lab ने यह बताने से इनकार किया कि दोनों issues जुड़े हुए हैं या नहीं, लेकिन कुछ चीज़ें देखने के लिए जीनियस होना ज़रूरी नहीं है
    [0]: https://adamcaudill.com/2023/09/14/whose-cve-is-it-anyway/

    • यहां Apple और Chrome खास तौर पर इसलिए महत्वपूर्ण हैं क्योंकि असल दुनिया में exploit के target वही थे, और उनके पास सबसे ज़्यादा users वाला direct attack surface है
      लेखक भी कहता है कि कई दूसरे systems को patch करना चाहिए। लेकिन 1 अरब बार pull की गई Python Docker images में से कितनी untrusted WebP images render करती होंगी? Node आदि के लिए भी यही बात है। बेशक, उन्हें जल्दी patch करना चाहिए, लेकिन यह iOS/Android/Chrome वाली श्रेणी का नहीं है

  • दुनिया भर के करोड़ों लोग इस library से प्रभावित हैं, और हर किसी के इस्तेमाल किए जाने वाले devices और apps के हिसाब से इसका असर कई गुना बढ़ जाता है
    मुझे C पसंद है, लेकिन मेरा मानना है कि दुनिया भर में करोड़ों लोगों द्वारा इस्तेमाल की जाने वाली libraries में C का इस्तेमाल नहीं होना चाहिए। ऐसी core libraries में risk ratio बहुत ज़्यादा है। C expert भी कभी न कभी गलती कर ही देगा
    लगता है fix यह है https://github.com/webmproject/libwebp/commit/dce8397fec159c...
    “malloc fail” कहना निराशाजनक है। Slack, Discord, Teams, सभी modern OS तक प्रभावित हैं

    • असली fix यह है: https://github.com/webmproject/libwebp/commit/902bc919033134...
    • मेरा भी यही सोचना है। Rust को नया C बनना चाहिए। सिर्फ इसलिए कि C में code लिखा जा सकता है, इसका मतलब यह नहीं कि “performance”, “portability”, “legacy compatibility” जैसे कारणों से बड़े पैमाने पर complex code बना देना ठीक है
      C/C++ और dynamic languages undefined behavior और subtle bugs की सतह को बहुत बड़ा बना देती हैं, और सबसे होशियार developers के लिए भी इन्हें lint करना मुश्किल और बोझिल होता है। foundational libraries को seL4 जैसे तरीके से formal verification से गुजरना चाहिए
      एक और समस्या FOSS में फैली गैर-पेशेवरता, और rigor, quality, correctness, security के प्रति उपेक्षा है। मौजूदा तरीके से रेत पर साम्राज्य खड़ा करना मूर्खता है
    • यहां हो या पास के commits में, एक भी test नहीं है। यह हैरान करने वाला है