CVE-2023-40547 – HTTP हेडर्स पर गलत तरीके से भरोसा करने से बचें

मूल लेख ↗ Hacker News चर्चा ↗

एक गंभीर vulnerability (CVE-2023-40547) shim bootloader में, जो Linux Secure Boot के लिए उपयोग होता है, HTTP `Content-Length` headers पर भरोसा करने पर out-of-bounds writes की अनुमति देती है, जिससे network-boot और कुछ local या MITM scenarios में attackers Secure Boot को bypass कर सकते हैं। Commenters shim का Secure Boot chain में स्थान, firmware स्तर पर HTTP/HTTPS handling क्यों मुश्किल है, और यह bug दुर्लभ HTTP boot path में होने के बावजूद क्यों गंभीर है, समझाते हैं। यह thread Microsoft के UEFI signing keys पर नियंत्रण, GPLv3 की anti‑tivoization requirements, और क्या Secure Boot वास्तव में users की रक्षा करता है या मुख्यतः vendor control लागू करता है, जैसी दीर्घकालिक चिंताओं पर भी लौटती है.

कमज़ोरी और संदर्भ

  • बग shim के HTTP boot कोड में है: यह Content-Length हेडर के आधार पर एक बफ़र आवंटित करता है, लेकिन वास्तविक प्राप्त body लंबाई के आधार पर कॉपी करता है, जिससे यदि हेडर झूठ बोलता है तो out‑of‑bounds write संभव हो जाता है।
  • यह उन shim builds में मौजूद है जिनमें HTTP boot support शामिल है; shim मुख्यतः एक Microsoft‑signed Secure Boot loader के रूप में उपयोग होता है, जो फिर Machine Owner Keys (MOK) के माध्यम से अपनी नीति लागू करता है।
  • पहले आए उन headlines को सुधारा गया जिनमें “हर Linux bootloader” कहा गया था: यह shim का बग है, जो लगभग 8 साल पहले introduce हुआ था।

Attack surface और severity

  • यह केवल explicit HTTP boot तक सीमित नहीं है:
    • Local: privileged malware EFI System Partition या EFI variables को overwrite कर सकता है और HTTP boot को force कर सकता है या shim→GRUB2→shim को HTTP के ज़रिए chain कर सकता है।
    • Adjacent network: PXE boot और MITM को HTTP shim loading में chain किया जा सकता है।
    • Remote: HTTP boot का उपयोग करने वाले victim के विरुद्ध HTTP boot पर MITM।
  • कुछ लोगों का तर्क है कि एक बार attacker EFI vars/ESP बदल सकता है, तो अन्य attacks (जैसे MOKs जोड़ना, पुराने signed binaries का उपयोग) पहले से ही संभव हैं; दूसरे जवाब देते हैं कि Secure Boot का उद्देश्य ही ऐसे tampering को सहना है।
  • “Critical” rating पर असहमति: कुछ इसे आवश्यक defense‑in‑depth मानते हैं, जबकि अन्य सोचते हैं कि यदि server या local system पहले से बहुत अधिक compromised है तो इसका महत्व कम है।

HTTP बनाम HTTPS और implementation details

  • HTTPS malicious servers को नहीं रोकता; यह मुख्यतः MITM को रोकता है।
  • कई commenters नोट करते हैं कि UEFI/boot code proper HTTPS certificate validation छोड़ सकता है (CA store size, update और revocation complexities, time skew), जिससे HTTPS पर भी MITM वास्तविक हो जाता है।
  • HTTP semantics पर बहस: HTTP/1.1 में Content-Length को authoritative माना जाता है; यदि कोई implementation इसके बजाय एक अलग “bodyLength” measurement पर भरोसा करती है, तो दोनों का सावधानी से reconciliation होना चाहिए—इसी mismatch से यह bug उत्पन्न हुआ।

Shim, Secure Boot, MOK, और revocation

  • सामान्य उपयोग shim → GRUB → kernel on local disk है; HTTP boot niche है, लेकिन मौजूद है।
  • Shim अगले stage binary को अपनी MOK list के विरुद्ध verify करता है; UEFI DBX के माध्यम से Secure Boot revocation vulnerable shim binaries को invalidate कर सकती है, लेकिन संभवतः कई systems कभी DBX update नहीं करते।
  • Measured boot और TPM, सिद्धांततः, disk decryption keys को specific boot components से bind कर सकते हैं, लेकिन इसे जटिल माना जाता है और सामान्य उपयोगकर्ताओं द्वारा शायद ही उपयोग किया जाता है।

GPLv3, anti‑tivoization, और Microsoft की signing policy

  • एक बड़ा subthread इस बात पर था कि Microsoft GRUB जैसे GPLv3 bootloaders को sign करने से क्यों बचता है:
    • GPLv3 के “Installation Information” clause का हवाला दिया गया: GPLv3 components वाले devices के distributors को वे methods/authorization keys प्रदान करने चाहिए जिनकी आवश्यकता उपयोगकर्ताओं को उस device पर modified versions install और run करने के लिए हो।
    • कुछ लोग शुरू में संदेह करते हैं कि यह signing keys पर लागू होता है, फिर मानते हैं कि भाषा (“authorization keys”) और anti‑tivoization पर FSF commentary इस interpretation का समर्थन करती है।
    • अन्य तर्क देते हैं कि users को अपने स्वयं के keys enroll करने देना (vendor private keys प्रदान करने के बजाय) license को satisfy करना चाहिए, और नोट करते हैं कि Secure Boot के खराब implementations जो user keys को block करते हैं, वही असली समस्या हैं।
    • इस पर बहस है कि signatures का copyright से कोई संबंध है या नहीं, और क्या केवल किसी binary को sign करना (बिना उसे distribute किए) GPL obligations trigger कर सकता है; विचार टकराते हैं, और legal status को अनिश्चित बताया गया है।
  • Shim MIT‑licensed है ताकि GPLv3 constraints से बचा जा सके, जिससे इसे Microsoft द्वारा sign किया जा सके जबकि यह अपनी trust policy (MOK) लागू करता रहे।

Secure Boot और ecosystem पर विचार

  • कुछ लोग Secure Boot को valid defense‑in‑depth मानते हैं, खासकर unencrypted ESPs पर “evil maid” attacks के विरुद्ध, और तर्क देते हैं कि vendors को keys पर user control की अनुमति देनी चाहिए।
  • अन्य लोग इसे तीखी आलोचना का विषय मानते हैं:
    • दावा करते हैं कि Secure Boot मुख्यतः vendor control (विशेषकर Microsoft की default key) को मज़बूत करता है और user security से अधिक DRM जैसा है।
    • ऐसे devices का हवाला देते हैं जहाँ Secure Boot बंद नहीं किया जा सकता या user keys जोड़ी नहीं जा सकतीं, और जहाँ Secure Boot सक्षम करने से usability issues आते हैं (जैसे hibernation, “scary” warnings, Linux friction)।
    • चिंता व्यक्त करते हैं कि PC platform एक walled garden की ओर बढ़ रहा है, और इसे पहले के antitrust issues से जोड़ते हैं।

Network boot और design choices

  • HTTP/PXE boot को कई लोगों ने “security nightmares” या कम से कम अत्यधिक जोखिमपूर्ण बताया, हालांकि अन्य लोग नोट करते हैं कि वे lab testing और provisioning के लिए उपयोगी हैं।
  • कुछ लोग प्रश्न करते हैं कि shim सीधे HTTP boot को implement ही क्यों करता है, बजाय इसे एक अलग, MOK‑signed EFI binary को delegate करने के।
  • ऐसी स्पष्ट header‑trust bug का code review में पास हो जाना आलोचना का विषय है; टिप्पणियों में इसे beginner mistake जैसी तुलना दी गई, और patch में छोटे साफ़-सफ़ाई वाले बदलावों (जैसे typo fixes) पर भी side remarks थे।