SBAT क्या है और अचानक हर कोई इसमें दिलचस्पी क्यों ले रहा है

SBAT(Secure Boot Advanced Targeting) की परिभाषा

• जब UEFI Secure Boot पहली बार निर्धारित किया गया था, तब इससे जुड़े सभी लोग कुछ हद तक भोले थे
• Secure Boot का मूल सुरक्षा मॉडल यह है कि kernel-स्तर के privilege environment में चलने वाले हर code को चलने से पहले verify किया जाना चाहिए
• इसमें ऐसे signed components को revoke करने का तरीका शामिल है जिनमें vulnerability पाई गई हो
• लेकिन Secure Boot ecosystem में काम करने वाले सभी Linux distribution अपने-अपने bootloader binary बनाते हैं, इसलिए vulnerability की पहचान होने पर revoke किए जाने वाले binaries की संख्या बहुत अधिक हो जाती है
• hash स्टोर करने के लिए जगह सीमित होने के कारण SBAT विकसित किया गया

SBAT कैसे काम करता है

• boot chain के सभी महत्वपूर्ण components signed binary में शामिल security generation घोषित करते हैं
• vulnerability की पहचान होने और उसे ठीक कर दिए जाने पर उस generation को बढ़ा दिया जाता है
• updates के जरिए minimum generation परिभाषित की जा सकती है
• boot component chain में अगले item को देखकर उसके नाम और generation number की तुलना firmware variable में स्टोर मान से करता है और तय करता है कि उसे चलाना है या नहीं
• कई individual hash revoke करने के बजाय, एक ही update push किया जा सकता है जो यह कहे कि किसी निश्चित संख्या से कम security generation वाले grub versions पर भरोसा नहीं किया जा सकता

हालिया समस्या की वजह

• Microsoft ने Windows update जारी किया ताकि एक निश्चित स्तर से कम security generation वाले grub versions पर भरोसा न किया जाए
• ऐसा इसलिए किया गया क्योंकि उन grub versions में वास्तविक security vulnerabilities थीं जो Windows Secure Boot chain को compromise कर सकती थीं
• समस्या यह थी कि कुछ Linux distributions ने अभी तक grub का नया security version उपलब्ध नहीं कराया था
• Microsoft का इरादा SBAT update को केवल Windows-only systems पर लागू करने का था, लेकिन यह योजना के मुताबिक काम नहीं कर पाया

सारांश

• Microsoft ने vulnerable grub versions का उपयोग करके Windows पर हमला न हो सके, इसके लिए Windows update जारी किया
• इस update को dual-boot systems पर लागू नहीं होना चाहिए था, लेकिन ऐसा नहीं हुआ
• कुछ Linux distributions ने grub code और SBAT security generation को update नहीं किया था
• नतीजतन, कुछ उपयोगकर्ता अपने systems को boot नहीं कर पाए

दोष किसका है

• Microsoft को dual-boot setup की सही पहचान सुनिश्चित करने के लिए अधिक testing करनी चाहिए थी
• लेकिन signed bootloader उपलब्ध कराने वाले distributions को भी उन्हें update करना चाहिए और security generation बढ़ानी चाहिए
• क्योंकि यह दूसरे operating systems पर हमला करने के लिए एक vector उपलब्ध करा सकता है

निष्कर्ष

• यह दुर्भाग्यपूर्ण है कि वे end users पीड़ित बने जो अचानक अपनी पसंद का OS boot नहीं कर पाए
• ऐसा कभी नहीं होना चाहिए
• भले ही UEFI Secure Boot अधिकांश end users के लिए फायदेमंद न लगे, लेकिन बाद में यह पता चलना कि इसकी जरूरत थी, उससे बचने के लिए Microsoft का इसे default रूप से enable रखना समझ में आता है
• dual-boot systems पर update से बचने की असफल कोशिश को छोड़कर, Microsoft के इस निर्णय से सहानुभूति रखी जा सकती है

GN⁺ की राय

• यह घटना दिखाती है कि security और user experience के बीच संतुलन बनाना कितना कठिन है
• Microsoft और Linux distributions दोनों ही उपयोगकर्ताओं की सुरक्षा के लिए पूरी कोशिश कर रहे हैं, लेकिन इस प्रक्रिया में user experience की कीमत चुकानी पड़ सकती है
• dual-boot system इस्तेमाल करने वाले उपयोगकर्ताओं के लिए ऐसी समस्याओं का सामना करने की संभावना अधिक है
• इसलिए dual-boot इस्तेमाल करने वालों के लिए यह महत्वपूर्ण है कि वे दोनों operating systems को latest version पर रखें और नियमित रूप से update करें
• लंबी अवधि में Linux और Windows communities के बीच बेहतर सहयोग और समन्वय की जरूरत दिखती है

[GN⁺]

Hacker News राय

• हाल की Linux Unplugged एपिसोड में TPM का उपयोग करके Linux बूट प्रोसेस के लिए trust chain सेट करने का तरीका कवर किया गया था, Clevis के साथ यह बहुत दिलचस्प लगा
• Microsoft का इरादा यह था कि Windows Update, SBAT अपडेट सिर्फ Windows-only सिस्टम पर लागू करे, और dual boot सेटअप तब तक असुरक्षित बने रहें जब तक इंस्टॉल किए गए distro, grub को अपडेट न कर दें और SBAT अपडेट खुद वितरित न करें
  • EFI boot order पढ़ने पर तो साफ़ दिखना चाहिए कि पहले shim को boot करना है, इसलिए सोच रहा हूँ कि गड़बड़ कहाँ हुई
  • सोच रहा हूँ कि क्या यह उन dual boot सेटअप के मामलों में था जहाँ यूज़र firmware menu का उपयोग करके Linux या Windows चुनते हैं
  • यह Microsoft की तरफ़ से एक वैध fix लगता है, लेकिन communication अच्छा नहीं था
• जब shim या SB की सामान्य security check fail होती है, तो error message बहुत खराब लगते हैं; काश वे बताते कि ठीक-ठीक क्या fail हुआ और उसे कैसे ठीक करें
• मुझे लगता है कि MS द्वारा TPM2.0 को अनिवार्य करने और SBAT अपडेट लागू करने का एक कारण यह है कि rootkit-स्तर के malware व्यापक रूप से मौजूद हैं
• dual boot की वास्तविकता को लेकर, 10 साल पहले Win7/8/10 में suspend-to-hiberfile.sys समस्या और updates के कारण grub टूटने की समस्या बहुत थी
  • 10 साल पहले ही मैंने सिर्फ Linux इस्तेमाल करने का फैसला किया, और ज़रूरत पड़ने पर VM या एक अलग spare कंप्यूटर इस्तेमाल करता हूँ
  • उसके बाद मैंने distro पर Secure Boot को सफलतापूर्वक सेट करना, QEMU performance और passthrough को tune करना सीखा, और QEMU macOS VM भी चला लिया
  • XCode बनाए रखने के लिए हर कुछ महीनों में update करना झंझट है, लेकिन कुल मिलाकर संतुष्ट हूँ
• Linux इंस्टॉल करते समय Secure Boot को disable करना क्या पहली चीज़ नहीं होती?
• मुख्य सवाल यह है कि reject किया जा रहा grub पूरी तरह patch नहीं हुआ है, या distro ने "security generation" अपडेट किए बिना patch किया है
  • MS ने dual boot detection की कोशिश कैसे की, इसे लेकर बहुत जिज्ञासा है, और उम्मीद है कोई (मुझसे अधिक कुशल व्यक्ति) update में उस हिस्से का reverse engineering करेगा
• Microsoft ने dual boot सिस्टम इसलिए तोड़े क्योंकि वे दूसरे operating system पर attack करने वाला vector उपलब्ध नहीं कराना चाहते, और यह सामाजिक अनुबंध का उल्लंघन है
• सोच रहा हूँ कि क्या यह सिस्टम से Windows हटाकर Linux इंस्टॉल करने में बाधा डालता है, या Windows इंस्टॉल करने से TPM module स्थायी रूप से दूषित हो जाता है
• सोच रहा हूँ कि क्या Windows से grub अपडेट किया जा सकता है, या Secure Boot disable करके Linux boot करना, फिर upgrade करना और दोबारा enable करना पर्याप्त है
• पुराने कमजोर grub इंस्टॉलेशन को block करने पर MS का रुख़ तर्कसंगत लगता है, लेकिन मैं Windows का उपयोग सिर्फ games और एक पुराने legacy software के लिए करता हूँ, वह भी network access के बिना
  • जिस क्षण आप Windows update की अनुमति देते हैं, सब कुछ किस्मत पर छोड़ दिया जाता है
  • MS का registry keys इधर-उधर करना और "telemetry" (विज्ञापन और behavioral data scanning के लिए ML) थोपने के लिए यूज़र्स के साथ खेल खेलना बहुत कुछ बता देता है
  • यह Windows Pro में भी होता है, और मैं Win 10 इस्तेमाल कर रहा हूँ