🥇 Schrödinger द्वारे विश्वसनीय डाउनलोड. इंटेल बूट गार्ड

आम्ही पुन्हा खालच्या पातळीवर जाण्याचा आणि x86-सुसंगत संगणक प्लॅटफॉर्मसाठी फर्मवेअरच्या सुरक्षिततेबद्दल बोलण्याचा प्रस्ताव देतो. या वेळी, अभ्यासाचा मुख्य घटक म्हणजे इंटेल बूट गार्ड (इंटेल BIOS गार्डमध्ये गोंधळून जाऊ नये!) - हार्डवेअर-समर्थित विश्वसनीय BIOS बूट तंत्रज्ञान जे संगणक प्रणाली विक्रेता उत्पादन टप्प्यावर कायमचे सक्षम किंवा अक्षम करू शकतो. बरं, संशोधनाची रेसिपी आम्हाला आधीच परिचित आहे: रिव्हर्स इंजिनिअरिंग वापरून या तंत्रज्ञानाच्या अंमलबजावणीचे बारीक तुकडे करा, त्याच्या आर्किटेक्चरचे वर्णन करा, ते कागदोपत्री नसलेल्या तपशीलांनी भरून टाका, चवीनुसार आणि मिसळण्यासाठी अटॅक व्हेक्टरसह सीझन करा. बर्‍याच विक्रेत्यांच्या उत्पादनात वर्षानुवर्षे क्लोन केलेला बग संभाव्य आक्रमणकर्त्याला या तंत्रज्ञानाचा वापर करून सिस्टीममध्ये छुपी रूटकिट तयार करण्यास अनुमती देतो ज्याला काढून टाकले जाऊ शकत नाही (अगदी प्रोग्रामरसह देखील) या कथेमध्ये इंधन जोडूया.

तसे, लेख कॉन्फरन्समधील “ऑन गार्ड ऑफ रूटकिट्स: इंटेल बूटगार्ड” या अहवालांवर आधारित आहे झिरो नाईट्स 2016 आणि 29 वी बैठक DefCon रशिया (दोन्ही सादरीकरणे येथे).

इंटेल 64 आर्किटेक्चरसह संगणक प्लॅटफॉर्मसाठी फर्मवेअर

प्रथम, या प्रश्नाचे उत्तर द्या: इंटेल 64 आर्किटेक्चरसह आधुनिक संगणक प्लॅटफॉर्मचे फर्मवेअर काय आहे? अर्थात, UEFI BIOS. पण असे उत्तर अचूक असणार नाही. या आर्किटेक्चरची डेस्कटॉप (लॅपटॉप) आवृत्ती दाखवणारे चित्र पाहू या.

आधार हा दुवा आहे:

प्रोसेसर (CPU, सेंट्रल प्रोसेसिंग युनिट), ज्यामध्ये मुख्य कोर व्यतिरिक्त, अंगभूत ग्राफिक्स कोर (सर्व मॉडेलमध्ये नाही) आणि मेमरी कंट्रोलर (IMC, इंटिग्रेटेड मेमरी कंट्रोलर) आहे;
चिपसेट (PCH, प्लॅटफॉर्म कंट्रोलर हब), ज्यामध्ये परिधीय उपकरणांशी संवाद साधण्यासाठी आणि उपप्रणाली व्यवस्थापित करण्यासाठी विविध नियंत्रक असतात. त्यापैकी सुप्रसिद्ध इंटेल मॅनेजमेंट इंजिन (एमई) आहे, ज्यामध्ये फर्मवेअर (इंटेल एमई फर्मवेअर) देखील आहे.

लॅपटॉपला, वरील व्यतिरिक्त, अंगभूत कंट्रोलर (ACPI EC, प्रगत नियंत्रण आणि पॉवर इंटरफेस एम्बेडेड कंट्रोलर) आवश्यक आहे, जो पॉवर सबसिस्टम, टचपॅड, कीबोर्ड, Fn की (स्क्रीन ब्राइटनेस, आवाज आवाज) च्या ऑपरेशनसाठी जबाबदार आहे. , कीबोर्ड बॅकलाइट इ. ) आणि इतर गोष्टी. आणि त्याचे स्वतःचे फर्मवेअर देखील आहे.

तर, वरील फर्मवेअरची संपूर्णता संगणक प्लॅटफॉर्म (सिस्टम फर्मवेअर) चे फर्मवेअर आहे, जे सामान्य एसपीआय फ्लॅश मेमरीवर संग्रहित आहे. या मेमरीच्या वापरकर्त्यांना ती कुठे आहे याबद्दल गोंधळ होऊ नये म्हणून, या मेमरीमधील सामग्री खालील क्षेत्रांमध्ये विभागली गेली आहे (आकृतीमध्ये दर्शविल्याप्रमाणे):

UEFI BIOS;
ACPI EC फर्मवेअर (स्कायलेक प्रोसेसर मायक्रोआर्किटेक्चर (2015) सह एक वेगळा प्रदेश दिसला, परंतु जंगलात आम्ही अद्याप त्याच्या वापराची उदाहरणे पाहिली नाहीत, म्हणून अंगभूत कंट्रोलरचे फर्मवेअर अद्याप UEFI BIOS मध्ये समाविष्ट आहे) ;
इंटेल एमई फर्मवेअर;
अंगभूत GbE (Gigabit इथरनेट) नेटवर्क अडॅप्टरचे कॉन्फिगरेशन (MAC पत्ता इ.);
फ्लॅश डिस्क्रिप्टर्स हे फ्लॅश मेमरीचे मुख्य क्षेत्र आहेत ज्यात इतर प्रदेशांसाठी पॉइंटर असतात, तसेच त्यांना प्रवेश करण्यासाठी परवानग्या असतात.

SPI बस मास्टर, चिपसेटमध्ये तयार केलेला एक SPI कंट्रोलर, ज्याद्वारे ही मेमरी ऍक्सेस केली जाते, क्षेत्रांमध्ये प्रवेश मर्यादित करण्यासाठी जबाबदार आहे (निर्दिष्ट परवानग्यांनुसार). जर परवानग्या इंटेलच्या शिफारस केलेल्या (सुरक्षेच्या कारणास्तव) मूल्यांवर सेट केल्या असतील, तर प्रत्येक SPI फ्लॅश वापरकर्त्यास त्यांच्या प्रदेशात पूर्ण प्रवेश (वाचणे/लिहाणे) आहे. आणि बाकीचे एकतर केवळ वाचनीय किंवा दुर्गम आहेत. एक सुप्रसिद्ध वस्तुस्थिती: बर्‍याच सिस्टम्सवर, CPU ला UEFI BIOS आणि GbE मध्ये पूर्ण प्रवेश असतो, फक्त फ्लॅश वर्णनकर्त्यांना वाचण्याचा प्रवेश असतो आणि Intel ME प्रदेशात अजिबात प्रवेश नाही. का अनेकांवर, आणि सर्वांवर नाही? जे सुचवले आहे ते आवश्यक नाही. आम्ही लेखात नंतर आपल्याला अधिक तपशीलवार सांगू.

संगणक प्लॅटफॉर्म फर्मवेअरला बदलांपासून संरक्षण करण्यासाठी यंत्रणा

अर्थात, कॉम्प्युटर प्लॅटफॉर्मचे फर्मवेअर संभाव्य तडजोडीपासून संरक्षित केले जावे, ज्यामुळे संभाव्य आक्रमणकर्त्याला त्यात पाऊल ठेवता येईल (ओएस अद्यतने/पुनर्स्थापना टिकून राहावे), त्यांचा कोड सर्वात विशेषाधिकार असलेल्या मोडमध्ये कार्यान्वित करणे इ. आणि SPI फ्लॅश मेमरी क्षेत्रांमध्ये प्रवेश प्रतिबंधित करणे अर्थातच पुरेसे नाही. म्हणून, फर्मवेअरला बदलांपासून संरक्षण करण्यासाठी, प्रत्येक ऑपरेटिंग वातावरणाशी संबंधित विविध यंत्रणा वापरल्या जातात.

अशा प्रकारे, इंटेल ME फर्मवेअर अखंडता आणि सत्यता नियंत्रित करण्यासाठी स्वाक्षरी केलेले आहे आणि प्रत्येक वेळी ME UMA मेमरीमध्ये लोड केल्यावर ME नियंत्रकाद्वारे तपासले जाते. या पडताळणी प्रक्रियेची आमच्याद्वारे आधीच चर्चा केली गेली आहे लेख, Intel ME उपप्रणालीला समर्पित.

आणि ACPI EC फर्मवेअर, एक नियम म्हणून, केवळ अखंडतेसाठी तपासले जाते. तथापि, ही बायनरी UEFI BIOS मध्ये समाविष्ट केल्यामुळे, हे जवळजवळ नेहमीच UEFI BIOS वापरत असलेल्या समान संरक्षण यंत्रणेच्या अधीन असते. चला त्यांच्याबद्दल बोलूया.

या यंत्रणा दोन वर्गांमध्ये विभागल्या जाऊ शकतात.

UEFI BIOS प्रदेशात संरक्षण लिहा

राइट-प्रोटेक्ट जम्परसह एसपीआय फ्लॅश मेमरीच्या सामग्रीचे भौतिक संरक्षण;
PRx चिपसेट रजिस्टर्सचा वापर करून CPU अॅड्रेस स्पेसमध्ये UEFI BIOS क्षेत्राच्या प्रोजेक्शनचे संरक्षण करणे;
चिपसेट रजिस्टर्समध्ये BIOS_WE/BLE आणि SMM_BWP बिट्स सेट करून संबंधित SMI व्यत्यय निर्माण आणि प्रक्रिया करून UEFI BIOS प्रदेशात लिहिण्याच्या प्रयत्नांना अवरोधित करणे;
या संरक्षणाची अधिक प्रगत आवृत्ती इंटेल BIOS गार्ड (PFAT) आहे.

या यंत्रणांव्यतिरिक्त, विक्रेते त्यांचे स्वतःचे सुरक्षा उपाय विकसित आणि अंमलात आणू शकतात (उदाहरणार्थ, UEFI BIOS अद्यतनांसह कॅप्सूल साइन करणे).

हे लक्षात घेणे महत्त्वाचे आहे की विशिष्ट प्रणालीवर (विक्रेत्यावर अवलंबून), वरील सर्व संरक्षण यंत्रणा लागू केल्या जाऊ शकत नाहीत, ते अजिबात लागू केले जाऊ शकत नाहीत किंवा ते असुरक्षित पद्धतीने लागू केले जाऊ शकतात. आपण या यंत्रणा आणि त्यांच्या अंमलबजावणीसह परिस्थितीबद्दल अधिक वाचू शकता हा लेख. स्वारस्य असलेल्यांसाठी, आम्ही शिफारस करतो की तुम्ही UEFI BIOS सुरक्षेवरील लेखांची संपूर्ण मालिका वाचा कोडरश.

UEFI BIOS प्रमाणीकरण

जेव्हा आपण विश्वासार्ह बूट तंत्रज्ञानाबद्दल बोलतो, तेव्हा लक्षात येणारी पहिली गोष्ट म्हणजे सुरक्षित बूट. तथापि, आर्किटेक्चरली ते UEFI BIOS (ड्रायव्हर्स, बूटलोडर्स इ.) च्या बाहेरील घटकांची सत्यता सत्यापित करण्यासाठी डिझाइन केलेले आहे, फर्मवेअर स्वतःच नाही.

म्हणून, Intel, Bay Trail microarchitecture (2012) सह SoCs मध्ये, हार्डवेअर नॉन-डिसेबल सिक्योर बूट (व्हेरिफाईड बूट) लागू केले, ज्यात वर नमूद केलेल्या सुरक्षित बूट तंत्रज्ञानाशी काहीही साम्य नाही. नंतर (2013), ही यंत्रणा सुधारली गेली आणि हॅसवेल मायक्रोआर्किटेक्चरसह डेस्कटॉपसाठी इंटेल बूट गार्ड नावाने प्रसिद्ध केली गेली.

इंटेल बूट गार्डचे वर्णन करण्यापूर्वी, इंटेल 64 आर्किटेक्चरमधील अंमलबजावणी वातावरण पाहू या, जे एकत्रितपणे, या विश्वसनीय बूट तंत्रज्ञानासाठी विश्वासाचे मूळ आहेत.

इंटेल सीपीयू

कॅप सूचित करतो की इंटेल 64 आर्किटेक्चरमध्ये प्रोसेसर हे मुख्य अंमलबजावणीचे वातावरण आहे. ते विश्वासाचे मूळ का आहे? असे दिसून आले की त्याला असे बनवते ते खालील घटकांचा ताबा आहे:

मायक्रोकोड रॉम ही मायक्रोकोड संचयित करण्यासाठी नॉन-अस्थिर, नॉन-रिराईट करण्यायोग्य मेमरी आहे. असे मानले जाते की मायक्रोकोड हे सर्वात सोप्या सूचना वापरून प्रोसेसर कमांड सिस्टमची अंमलबजावणी आहे. मायक्रोकोडमध्येही घडते बग. त्यामुळे BIOS मध्ये तुम्ही मायक्रोकोड अपडेट्ससह बायनरी शोधू शकता (बूट दरम्यान आच्छादित, कारण रॉम ओव्हरराईट केले जाऊ शकत नाही). या बायनरींची सामग्री एन्क्रिप्ट केलेली आहे, जी विश्लेषणास मोठ्या प्रमाणात गुंतागुंत करते (म्हणूनच, मायक्रोकोडची विशिष्ट सामग्री केवळ विकसित केलेल्यांनाच ज्ञात आहे), आणि अखंडता आणि सत्यता नियंत्रित करण्यासाठी स्वाक्षरी केली आहे;
मायक्रोकोड अद्यतनांची सामग्री डिक्रिप्ट करण्यासाठी AES की;
मायक्रोकोड अद्यतनांच्या स्वाक्षरीची पडताळणी करण्यासाठी वापरल्या जाणार्‍या RSA सार्वजनिक कीचा हॅश;
RSA पब्लिक की हॅश, जो इंटेल-विकसित ACM (ऑथेंटिकेटेड कोड मॉड्यूल) कोड मॉड्यूल्सच्या स्वाक्षरीची पडताळणी करतो, ज्याला CPU BIOS अंमलबजावणीपूर्वी (हॅलो मायक्रोकोड) किंवा त्याच्या ऑपरेशन दरम्यान, काही घटना घडल्यावर लॉन्च करू शकते.

इंटेल ME

आमचा ब्लॉग या उपप्रणालीला समर्पित होता दोन लेख. हे एक्झिक्युटेबल वातावरण चिपसेटमध्ये तयार केलेल्या मायक्रोकंट्रोलरवर आधारित आहे आणि सिस्टीममध्ये सर्वात लपलेले आणि विशेषाधिकार आहे हे लक्षात ठेवूया.

गुप्तता असूनही, इंटेल एमई देखील विश्वासाचे मूळ आहे कारण त्यात आहे:

एमई रॉम - नॉन-अस्थिर, नॉन-रिराईटेबल मेमरी (कोणतीही अपडेट पद्धत प्रदान केलेली नाही) ज्यामध्ये स्टार्ट कोड आहे, तसेच RSA सार्वजनिक कीचा SHA256 हॅश आहे, जो इंटेल ME फर्मवेअरच्या स्वाक्षरीची पडताळणी करतो;
गुप्त माहिती साठवण्यासाठी AES की;
संगणक प्रणाली विक्रेत्याने निर्दिष्ट केलेल्या काही माहितीच्या कायमस्वरूपी संचयनासाठी चिपसेटमध्ये एकत्रित केलेल्या फ्यूजच्या संचाचा (FPFs, फील्ड प्रोग्रामेबल फ्यूज) प्रवेश.

इंटेल बूट गार्ड 1.x

एक छोटा अस्वीकरण. आम्ही या लेखात वापरत असलेले इंटेल बूट गार्ड तंत्रज्ञान आवृत्ती क्रमांक अनियंत्रित आहेत आणि त्यांचा इंटेलच्या अंतर्गत दस्तऐवजात वापरलेल्या क्रमांकाशी काहीही संबंध नसू शकतो. याव्यतिरिक्त, या तंत्रज्ञानाच्या अंमलबजावणीबद्दल येथे प्रदान केलेली माहिती उलट अभियांत्रिकी दरम्यान प्राप्त केली गेली होती, आणि इंटेल बूट गार्डच्या तपशीलाच्या तुलनेत चुकीची असू शकते, जी कधीही प्रकाशित होण्याची शक्यता नाही.

तर, इंटेल बूट गार्ड (BG) हे हार्डवेअर-समर्थित UEFI BIOS प्रमाणीकरण सत्यापन तंत्रज्ञान आहे. पुस्तकातील [प्लॅटफॉर्म एम्बेडेड सिक्युरिटी टेक्नॉलॉजी रिव्हील्ड, चाप्टर बूट विथ इंटिग्रिटी, किंवा बूट नॉट] मधील लहान वर्णनानुसार, ते विश्वसनीय बूट चेन म्हणून कार्य करते. आणि त्यातील पहिली लिंक CPU मधील बूट कोड (मायक्रोकोड) आहे, जो RESET इव्हेंटने ट्रिगर केला आहे (BIOS मधील RESET वेक्टरमध्ये गोंधळून जाऊ नये!). CPU ला SPI फ्लॅश मेमरी वर इंटेल (Intel BG स्टार्टअप ACM) द्वारे विकसित आणि स्वाक्षरी केलेले कोड मॉड्यूल सापडते, ते त्याच्या कॅशेमध्ये लोड करते, सत्यापित करते (सीपीयूमध्ये सार्वजनिक कीचा हॅश आहे जो ACM ची पडताळणी करतो हे आधीच नमूद केले आहे. स्वाक्षरी) आणि सुरू होते.

हे कोड मॉड्यूल UEFI BIOS - इनिशियल बूट ब्लॉक (IBB) चा एक लहान प्रारंभिक भाग सत्यापित करण्यासाठी जबाबदार आहे, ज्यामध्ये, UEFI BIOS च्या मुख्य भागाची पडताळणी करण्यासाठी कार्यक्षमता समाविष्ट आहे. अशा प्रकारे, इंटेल बीजी तुम्हाला ओएस लोड करण्यापूर्वी BIOS ची सत्यता पडताळण्याची परवानगी देते (जे सुरक्षित बूट तंत्रज्ञानाच्या देखरेखीखाली केले जाऊ शकते).

इंटेल बीजी तंत्रज्ञान दोन ऑपरेटिंग मोड प्रदान करते (आणि एक दुसर्‍यामध्ये व्यत्यय आणत नाही, म्हणजे दोन्ही मोड सिस्टमवर सक्षम केले जाऊ शकतात किंवा दोन्ही अक्षम केले जाऊ शकतात).

मोजलेले बूट

मापन केलेले बूट (एमबी) मोडमध्ये, प्रत्येक बूट घटक (CPU बूट रॉमपासून सुरू होणारा) TPM (विश्वसनीय प्लॅटफॉर्म मॉड्यूल) च्या क्षमतांचा वापर करून पुढील घटक “मोजतो”. ज्यांना माहिती नाही त्यांच्यासाठी मी समजावून सांगतो.

टीपीएममध्ये पीसीआर (प्लॅटफॉर्म कॉन्फिगरेशन रजिस्टर्स) आहेत, ज्यामध्ये हॅशिंग ऑपरेशनचा परिणाम सूत्रानुसार लिहिला जातो:

त्या. सध्याचे पीसीआर मूल्य मागील एकावर अवलंबून असते, आणि हे रजिस्टर्स फक्त सिस्टम रीसेट केल्यावरच रीसेट केले जातात.

अशाप्रकारे, MB मोडमध्ये, काही वेळेस, PCRs कोड किंवा डेटाचा एक अद्वितीय (हॅशिंग ऑपरेशनच्या क्षमतेमध्ये) ओळखकर्ता प्रतिबिंबित करतात जे "मोजले गेले होते." पीसीआर मूल्ये काही डेटा एन्क्रिप्शन (TPM_Seal) ऑपरेशनमध्ये वापरली जाऊ शकतात. यानंतर, त्यांचे डिक्रिप्शन (TPM_Unseal) तेव्हाच शक्य होईल जेव्हा लोडिंगच्या परिणामी पीसीआर मूल्ये बदलली नाहीत (म्हणजे, एकही "मोजलेला" घटक सुधारित केलेला नाही).

सत्यापित बूट

ज्यांना UEFI BIOS मध्ये सुधारणा करायला आवडते त्यांच्यासाठी सर्वात वाईट गोष्ट म्हणजे Verified Boot (VB) मोड, ज्यामध्ये प्रत्येक बूट घटक क्रिप्टोग्राफिकपणे पुढील घटकाची अखंडता आणि सत्यता सत्यापित करतो. आणि सत्यापन त्रुटीच्या बाबतीत, (एक) असे होते:

1 मिनिट ते 30 मिनिटांपर्यंत टाइमआउटद्वारे शटडाउन (जेणेकरून वापरकर्त्यास त्याचा संगणक का बूट होत नाही हे समजून घेण्यास वेळ मिळेल आणि शक्य असल्यास, BIOS पुनर्संचयित करण्याचा प्रयत्न करा);
तात्काळ शटडाउन (जेणेकरून वापरकर्त्यास समजण्यास वेळ नसेल, खूप कमी करा, काहीही);
शांत अभिव्यक्तीसह कार्य करणे सुरू ठेवणे (अशा परिस्थितीत जेव्हा सुरक्षिततेसाठी वेळ नसतो, कारण अधिक महत्त्वाच्या गोष्टी करायच्या आहेत).

कृतीची निवड निर्दिष्ट इंटेल बीजी कॉन्फिगरेशनवर (म्हणजे, तथाकथित अंमलबजावणी धोरणावर) अवलंबून असते, जी संगणक प्लॅटफॉर्म विक्रेत्याद्वारे खास डिझाइन केलेल्या स्टोरेजमध्ये कायमस्वरूपी रेकॉर्ड केली जाते - चिपसेट फ्यूज (FPFs). आम्ही या मुद्द्यावर नंतर अधिक तपशीलवार राहू.

कॉन्फिगरेशन व्यतिरिक्त, विक्रेता दोन RSA 2048 की व्युत्पन्न करतो आणि दोन डेटा स्ट्रक्चर्स तयार करतो (आकृतीमध्ये दर्शविलेले):

विक्रेत्याचा रूट की मॅनिफेस्ट (KEYM, OEM रूट की मॅनिफेस्ट), ज्यामध्ये या मॅनिफेस्टोचा SVN (सुरक्षा आवृत्ती क्रमांक), पुढील जाहीरनाम्याच्या सार्वजनिक कीचा SHA256 हॅश, RSA सार्वजनिक की (म्हणजेच सार्वजनिक भाग) विक्रेत्याची रूट की) या जाहीरनाम्याची स्वाक्षरी आणि स्वाक्षरी स्वतः सत्यापित करण्यासाठी;
IBB मॅनिफेस्ट (IBBM, इनिशियल बूट ब्लॉक मॅनिफेस्ट), ज्यामध्ये या मॅनिफेस्टोचा SVN, IBB चा SHA256 हॅश, या मॅनिफेस्टोच्या स्वाक्षरीची आणि स्वाक्षरीची पडताळणी करण्यासाठी सार्वजनिक की आहे.

OEM रूट की पब्लिक की ची SHA256 हॅश इंटेल BG कॉन्फिगरेशन प्रमाणेच चिपसेट फ्यूज (FPFs) मध्ये कायमस्वरूपी रेकॉर्ड केली जाते. जर इंटेल बीजी कॉन्फिगरेशनने या तंत्रज्ञानाचा समावेश केला असेल, तर आतापासून केवळ OEM रूट कीच्या खाजगी भागाचा मालक या सिस्टमवर BIOS अपडेट करू शकतो (म्हणजे, या मॅनिफेस्टची पुनर्गणना करण्यात सक्षम असेल), उदा. विक्रेता

चित्र पाहताना, इतक्या लांब पडताळणी साखळीच्या गरजेबद्दल लगेच शंका उद्भवतात - ते एक मॅनिफेस्ट वापरू शकले असते. गोष्टी क्लिष्ट का?

किंबहुना, इंटेल अशा प्रकारे विक्रेत्याला त्याच्या उत्पादनांच्या वेगवेगळ्या ओळींसाठी आणि एक रूट की म्हणून भिन्न IBB की वापरण्याची संधी प्रदान करते. जर IBB की चा खाजगी भाग (ज्याने दुसरा मॅनिफेस्ट स्वाक्षरी केलेला आहे) लीक झाला, तर घटनेचा परिणाम फक्त एका उत्पादन लाइनवर होईल आणि जोपर्यंत विक्रेता नवीन जोडी तयार करत नाही आणि पुढील BIOS अपडेटमध्ये पुनर्गणना केलेले मॅनिफेस्ट समाविष्ट करत नाही.

परंतु जर रूट की (ज्यासह प्रथम मॅनिफेस्टवर स्वाक्षरी केली आहे) तडजोड केली असेल, तर ती बदलणे शक्य होणार नाही; त्यासाठी कोणतीही रद्द करण्याची प्रक्रिया प्रदान केलेली नाही. या कीच्या सार्वजनिक भागाचा हॅश एकदाच आणि सर्वांसाठी FPF मध्ये प्रोग्राम केला जातो.

इंटेल बूट गार्ड कॉन्फिगरेशन

आता इंटेल बीजी कॉन्फिगरेशन आणि ते तयार करण्याची प्रक्रिया जवळून पाहू. तुम्ही Intel System Tool Kit (STK) मधील फ्लॅश इमेज टूल युटिलिटीच्या GUI मधील संबंधित टॅब पाहिल्यास, तुमच्या लक्षात येईल की Intel BG कॉन्फिगरेशनमध्ये विक्रेत्याच्या रूट कीच्या सार्वजनिक भागाचा हॅश समाविष्ट आहे, दोन अस्पष्ट मूल्ये इ. इंटेल बीजी प्रोफाइल.

या प्रोफाइलची रचना:

typedef struct BG_PROFILE
{
	unsigned long Force_Boot_Guard_ACM : 1;
	unsigned long Verified_Boot : 1;
	unsigned long Measured_Boot : 1;
	unsigned long Protect_BIOS_Environment : 1;
	unsigned long Enforcement_Policy : 2; // 00b – do nothing
                                              // 01b – shutdown with timeout
                                              // 11b – immediate shutdown
	unsigned long : 26;
};

सर्वसाधारणपणे, इंटेल बीजी कॉन्फिगरेशन ही एक अतिशय लवचिक संस्था आहे. उदाहरणार्थ, Force_Boot_Guard_ACM ध्वजाचा विचार करा. ते काढून टाकल्यावर, SPI फ्लॅशवरील BG स्टार्टअप ACM मॉड्यूल आढळले नाही, तर विश्वसनीय बूट होणार नाही. ती अविश्वासू असेल.

आम्ही आधीच वर लिहिले आहे की VB मोडसाठी अंमलबजावणी धोरण कॉन्फिगर केले जाऊ शकते जेणेकरून सत्यापन त्रुटी असल्यास, एक अविश्वसनीय डाउनलोड होईल.

अशा गोष्टी विक्रेत्यांच्या निर्णयावर सोडा...

GUI युटिलिटी खालील "रेडीमेड" प्रोफाइल प्रदान करते:

संख्या
मोड
वर्णन

0
नाही_FVME
इंटेल बीजी तंत्रज्ञान अक्षम

1
VE
VB मोड सक्षम आहे, कालबाह्यतेनुसार बंद

2
VME
दोन्ही मोड सक्षम आहेत (VB आणि MB), कालबाह्यतेनुसार बंद

3
VM
सिस्टीम बंद न करता दोन्ही मोड सक्षम केले आहेत

4
FVE
VB मोड सक्षम, त्वरित शटडाउन

5
FVME
दोन्ही मोड सक्षम, त्वरित बंद

आधीच नमूद केल्याप्रमाणे, इंटेल बीजी कॉन्फिगरेशन सिस्टम विक्रेत्याने चिपसेट फ्यूज (FPFs) मध्ये एकदा आणि सर्वांसाठी लिहिले पाहिजे - चिपसेटमधील माहितीचे एक लहान (असत्यापित माहितीनुसार, फक्त 256 बाइट्स) हार्डवेअर स्टोरेज, जे प्रोग्राम केले जाऊ शकते. इंटेलच्या उत्पादन सुविधांच्या बाहेर (म्हणूनच फील्ड प्रोग्राम करण्यायोग्य फ्यूज).

कॉन्फिगरेशन संचयित करण्यासाठी हे उत्तम आहे कारण:

डेटा संचयित करण्यासाठी एक-वेळ-प्रोग्राम करण्यायोग्य क्षेत्र आहे (नक्की जेथे Intel BG कॉन्फिगरेशन लिहिले आहे);
फक्त Intel ME ते वाचू शकते आणि प्रोग्राम करू शकते.

तर, विशिष्ट प्रणालीवर इंटेल बीजी तंत्रज्ञानासाठी कॉन्फिगरेशन सेट करण्यासाठी, विक्रेता उत्पादनादरम्यान खालील गोष्टी करतो:

फ्लॅश इमेज टूल युटिलिटी (इंटेल एसटीके कडून) वापरून, ते इंटेल ME क्षेत्रामध्ये (FPFs साठी तथाकथित तात्पुरता मिरर) व्हेरिएबल्सच्या स्वरूपात दिलेल्या इंटेल बीजी कॉन्फिगरेशनसह फर्मवेअर प्रतिमा तयार करते;
फ्लॅश प्रोग्रामिंग टूल युटिलिटी (इंटेल एसटीके कडून) वापरून, ते ही प्रतिमा सिस्टमच्या एसपीआय फ्लॅश मेमरीवर लिहिते आणि तथाकथित बंद करते. मॅन्युफॅक्चरिंग मोड (या प्रकरणात, संबंधित कमांड इंटेल एमईला पाठविली जाते).

या ऑपरेशन्सच्या परिणामस्वरुप, इंटेल ME ME प्रदेशातील FPF साठी मिररपासून FPF मध्ये निर्दिष्ट मूल्ये कमिट करेल, SPI फ्लॅश डिस्क्रिप्टर्समधील रिझोल्यूशन इंटेलने शिफारस केलेल्या मूल्यांवर सेट करेल (च्या सुरूवातीस वर्णन केले आहे. लेख) आणि सिस्टम रीसेट करा.

इंटेल बूट गार्ड अंमलबजावणीचे विश्लेषण

विशिष्ट उदाहरण वापरून या तंत्रज्ञानाच्या अंमलबजावणीचे विश्लेषण करण्यासाठी, आम्ही Intel BG तंत्रज्ञानाच्या ट्रेससाठी खालील प्रणाली तपासल्या:

प्रणाली
शेरा

गिगाबाइट GA-H170-D3H
Skylake, समर्थन आहे

Gigabyte GA-Q170-D3H
Skylake, समर्थन आहे

Gigabyte GA-B150-HD3
Skylake, समर्थन आहे

MSI H170A गेमिंग प्रो
स्कायलेक, आधार नाही

लेनोवो ThinkPad 460
Skylake, समर्थित, तंत्रज्ञान सक्षम

लेनोवो योग 2 प्रो
Haswell, समर्थन नाही

Lenovo U330p
Haswell, समर्थन नाही

"सपोर्ट" द्वारे आमचा अर्थ इंटेल बीजी स्टार्टअप ACM मॉड्यूलची उपस्थिती, वर नमूद केलेले मॅनिफेस्ट आणि BIOS मधील संबंधित कोड, म्हणजे. विश्लेषणासाठी अंमलबजावणी.

उदाहरण म्हणून, ऑफिसमधून डाउनलोड केलेले एक घेऊ. Gigabyte GA-H170-D3H (आवृत्ती F4) साठी SPI फ्लॅश मेमरीची विक्रेता वेबसाइट प्रतिमा.

इंटेल CPU बूट रॉम

सर्व प्रथम, इंटेल बीजी तंत्रज्ञान सक्षम असल्यास प्रोसेसरच्या क्रियांबद्दल बोलूया.

डिक्रिप्टेड मायक्रोकोडचे नमुने शोधणे शक्य नव्हते, त्यामुळे खाली वर्णन केलेल्या क्रिया कशा अंमलात आणल्या जातात (मायक्रोकोड किंवा हार्डवेअरमध्ये) हा खुला प्रश्न आहे. तथापि, हे खरं आहे की आधुनिक इंटेल प्रोसेसर या क्रिया "करू शकतात".

RESET स्थितीतून बाहेर पडल्यानंतर, प्रोसेसर (फ्लॅश मेमरीची सामग्री आधीच अॅड्रेस स्पेसमध्ये मॅप केलेली आहे) FIT (फर्मवेअर इंटरफेस टेबल) टेबल शोधते. हे शोधणे सोपे आहे; त्याचा निर्देशक FFFF FFC0h पत्त्यावर लिहिलेला आहे.

विचाराधीन उदाहरणामध्ये, मूल्य FFD6 9500h या पत्त्यावर स्थित आहे. या पत्त्यावर प्रवेश करून, प्रोसेसर FIT सारणी पाहतो, ज्याची सामग्री रेकॉर्डमध्ये विभागली जाते. पहिली नोंद खालील संरचनेचे शीर्षलेख आहे:

typedef struct FIT_HEADER
{
	char           Tag[8];     // ‘_FIT_   ’
	unsigned long  NumEntries; // including FIT header entry
	unsigned short Version;    // 1.0
	unsigned char  EntryType;  // 0
	unsigned char  Checksum;
};

काही अज्ञात कारणास्तव, चेकसम नेहमी या सारण्यांमध्ये मोजले जात नाही (फील्ड शून्य सोडले आहे).

उर्वरित नोंदी विविध बायनरींकडे निर्देश करतात ज्यांना BIOS कार्यान्वित करण्यापूर्वी पार्स/अंमलबजावणी करणे आवश्यक आहे, उदा. लेगसी RESET वेक्टर (FFFF FFF0h) वर स्विच करण्यापूर्वी. अशा प्रत्येक नोंदीची रचना खालीलप्रमाणे आहे.

typedef struct FIT_ENTRY
{
	unsigned long  BaseAddress;
	unsigned long  : 32;
	unsigned long  Size;
	unsigned short Version;     // 1.0
	unsigned char  EntryType;
	unsigned char  Checksum;
};

एंट्रीटाइप फील्ड तुम्हाला ही एंट्री कोणत्या ब्लॉकचा प्रकार सांगते. आम्हाला अनेक प्रकार माहित आहेत:

enum FIT_ENTRY_TYPES
{
	FIT_HEADER = 0,
	MICROCODE_UPDATE,
	BG_ACM,
	BIOS_INIT = 7,
	TPM_POLICY,
	BIOS_POLICY,
	TXT_POLICY,
	BG_KEYM,
	BG_IBBM
};

आता हे उघड आहे की एक प्रविष्टी इंटेल बीजी स्टार्टअप ACM बायनरीच्या स्थानाकडे निर्देश करते. या बायनरीची शीर्षलेख रचना इंटेल (ACM, मायक्रोकोड अद्यतने, Intel ME कोड विभाग, ...) द्वारे विकसित केलेल्या कोड मॉड्यूल्ससाठी वैशिष्ट्यपूर्ण आहे.

typedef struct BG_ACM_HEADER
{
	unsigned short ModuleType;     // 2
	unsigned short ModuleSubType;  // 3
	unsigned long  HeaderLength;   // in dwords
	unsigned long  : 32;
	unsigned long  : 32;
	unsigned long  ModuleVendor;   // 8086h
	unsigned long  Date;           // in BCD format
	unsigned long  TotalSize;      // in dwords
	unsigned long  unknown1[6];
	unsigned long  EntryPoint;
	unsigned long  unknown2[16];
	unsigned long  RsaKeySize;     // in dwords
	unsigned long  ScratchSize;    // in dwords
	unsigned char  RsaPubMod[256];
	unsigned long  RsaPubExp;
	unsigned char  RsaSig[256];
};

प्रोसेसर ही बायनरी त्याच्या कॅशेमध्ये लोड करतो, त्याची पडताळणी करतो आणि चालवतो.

इंटेल बीजी स्टार्टअप ACM

या एसीएमच्या कार्याचे विश्लेषण केल्यामुळे, हे स्पष्ट झाले की ते पुढील गोष्टी करते:

इंटेल ME कडून इंटेल बीजी कॉन्फिगरेशन प्राप्त होते, चिपसेट फ्यूज (FPFs) मध्ये लिहिलेले;
KEYM आणि IBBM मॅनिफेस्ट शोधते आणि त्यांची पडताळणी करते.

हे मॅनिफेस्ट शोधण्यासाठी, ACM FIT टेबल देखील वापरते, ज्यामध्ये संरचना डेटा दर्शवण्यासाठी दोन एंट्री प्रकार आहेत (वरील FIT_ENTRY_TYPES पहा).

चला जाहीरनामा जवळून पाहू. पहिल्या मॅनिफेस्टच्या संरचनेत, आम्हाला अनेक अस्पष्ट स्थिरांक दिसतात, दुसऱ्या मॅनिफेस्टमधील सार्वजनिक कीचा हॅश आणि सार्वजनिक OEM रूट की नेस्टेड स्ट्रक्चर म्हणून स्वाक्षरी केलेली आहे:

typedef struct KEY_MANIFEST
{
	char           Tag[8];          // ‘__KEYM__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned char  : 8;             // 1
	unsigned short : 16;            // 0Bh
	unsigned short : 16;            // 20h == hash size?
	unsigned char  IbbmKeyHash[32]; // SHA256 of an IBBM public key
	BG_RSA_ENTRY   OemRootKey;
};

typedef struct BG_RSA_ENTRY
{
	unsigned char  : 8;             // 10h
	unsigned short : 16;            // 1
	unsigned char  : 8;             // 10h
	unsigned short RsaPubKeySize;   // 800h
	unsigned long  RsaPubExp;
	unsigned char  RsaPubKey[256];
	unsigned short : 16;            // 14
	unsigned char  : 8;             // 10h
	unsigned short RsaSigSize;      // 800h
	unsigned short : 16;            // 0Bh
	unsigned char  RsaSig[256];
};

OEM रूट की सार्वजनिक की सत्यापित करण्यासाठी, आम्हाला आठवते की आम्ही फ्यूजचा SHA256 हॅश वापरतो, जो या टप्प्यावर इंटेल ME कडून आधीच प्राप्त झाला आहे.

चला दुसऱ्या जाहीरनाम्याकडे वळू. यात तीन संरचना आहेत:

typedef struct IBB_MANIFEST
{
	ACBP Acbp;         // Boot policies
	IBBS Ibbs;         // IBB description
	IBB_DESCRIPTORS[];
	PMSG Pmsg;         // IBBM signature
};

पहिल्यामध्ये काही स्थिरांक आहेत:

typedef struct ACBP
{
	char           Tag[8];          // ‘__ACBP__’
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 1
	unsigned char  : 8;             // 10h
	unsigned char  : 8;             // 0
	unsigned short : 16;            // x & F0h = 0
	unsigned short : 16;            // 0 < x <= 400h
};

दुसऱ्यामध्ये IBB चा SHA256 हॅश आणि IBB च्या सामग्रीचे वर्णन करणार्‍या वर्णनकर्त्यांची संख्या (म्हणजे, हॅश कशावरून मोजली जाते):

typedef struct IBBS
{
	char           Tag[8];            // ‘__IBBS__’
	unsigned char  : 8;               // 10h
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // 0
	unsigned char  : 8;               // x <= 0Fh
	unsigned long  : 32;              // x & FFFFFFF8h = 0
	unsigned long  Unknown[20];
	unsigned short : 16;              // 0Bh
	unsigned short : 16;              // 20h == hash size ?
	unsigned char  IbbHash[32];       // SHA256 of an IBB
	unsigned char  NumIbbDescriptors;
};

IBB वर्णनकर्ते एकामागून एक या संरचनेचे अनुसरण करतात. त्यांच्या सामग्रीचे खालील स्वरूप आहे:

typedef struct IBB_DESCRIPTOR
{
	unsigned long  : 32;
	unsigned long  BaseAddress;
	unsigned long  Size;
};

हे सोपे आहे: प्रत्येक वर्णनकर्त्यामध्ये IBB भागाचा पत्ता/आकार असतो. अशा प्रकारे, या वर्णनकर्त्यांनी (स्वत: वर्णनकर्त्यांच्या क्रमाने) निर्देशित केलेल्या ब्लॉक्सचे संयोजन म्हणजे IBB. आणि, एक नियम म्हणून, IBB हे SEC आणि PEI टप्प्यांच्या सर्व मॉड्यूल्सचे संकलन आहे.

दुसरा मॅनिफेस्ट IBB सार्वजनिक की (पहिल्या मॅनिफेस्टमधून SHA256 हॅशद्वारे सत्यापित) असलेल्या संरचनेद्वारे आणि या मॅनिफेस्टच्या स्वाक्षरीद्वारे पूर्ण केला जातो:

typedef struct PMSG
{
	char           Tag[8];            // ‘__PMSG__’
	unsigned char  : 8;               // 10h
	BG_RSA_ENTRY   IbbKey;
};

तर, UEFI BIOS कार्यान्वित होण्याआधीच, प्रोसेसर ACM लाँच करेल, जो SEC आणि PEI फेज कोडसह विभागातील सामग्रीची सत्यता सत्यापित करेल. पुढे, प्रोसेसर ACM मधून बाहेर पडतो, RESET वेक्टरचे अनुसरण करतो आणि BIOS कार्यान्वित करणे सुरू करतो.

सत्यापित PEI विभाजनामध्ये एक मॉड्यूल असणे आवश्यक आहे जे उर्वरित BIOS (DXE कोड) तपासेल. हे मॉड्यूल आधीपासून IBV (स्वतंत्र BIOS विक्रेता) किंवा स्वतः सिस्टम विक्रेत्याद्वारे विकसित केले जात आहे. कारण फक्त Lenovo आणि Gigabyte सिस्टीम आमच्या ताब्यात होत्या आणि त्यांना Intel BG सपोर्ट होता; चला या सिस्टीममधून काढलेला कोड पाहू.

UEFI BIOS मॉड्यूल LenovoVerifiedBootPei

Lenovo च्या बाबतीत, ते Lenovo ने विकसित केलेले LenovoVerifiedBootPei मॉड्यूल {B9F2AC77-54C7-4075-B42E-C36325A9468D} असल्याचे दिसून आले.

DXE साठी हॅश टेबल पाहणे (GUID द्वारे) आणि DXE सत्यापित करणे हे त्याचे कार्य आहे.

if (EFI_PEI_SERVICES->GetBootMode() != BOOT_ON_S3_RESUME)
{
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	if (!VerifyDxe())
		return EFI_SECURITY_VIOLATION;
}

Хеш таблица {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} имеет следующий формат:

typedef struct HASH_TABLE
{
	char          Tag[8];            // ‘$HASHTBL’
	unsigned long NumDxeDescriptors;
	DXE_DESCRIPTORS[];
};

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long Offset;
	unsigned long Size;
};

UEFI BIOS मॉड्यूल BootGuardPei

Gigabyte च्या बाबतीत, ते AMI द्वारे विकसित केलेले BootGuardPei मॉड्यूल {B41956E1-7CA2-42DB-9562-168389F0F066} असल्याचे दिसून आले, म्हणून, Intel BG समर्थनासह कोणत्याही AMI BIOS मध्ये उपस्थित आहे.

त्याचे ऑपरेटिंग अल्गोरिदम काहीसे वेगळे आहे, तथापि, ते त्याच गोष्टीवर उकळते:

int bootMode = EFI_PEI_SERVICES->GetBootMode();

if (bootMode != BOOT_ON_S3_RESUME &&
    bootMode != BOOT_ON_FLASH_UPDATE &&
    bootMode != BOOT_IN_RECOVERY_MODE)
{
	HOB* h = CreateHob();
	if (!FindHashTable())
		return EFI_NOT_FOUND;
	WriteHob(&h, VerifyDxe());
	return h;
}

तो शोधत असलेल्या हॅश टेबल {389CC6F2-1EA8-467B-AB8A-78E769AE2A15} मध्ये खालील फॉरमॅट आहे:

typedef HASH_TABLE DXE_DESCRIPTORS[];

typedef struct DXE_DESCRIPTOR
{
	unsigned char BlockHash[32];     // SHA256
	unsigned long BaseAddress;
	unsigned long Size;
};

इंटेल बूट गार्ड 2.x

इंटेल बूट गार्डच्या आणखी एका अंमलबजावणीबद्दल थोडक्यात बोलूया, जे अपोलो लेक मायक्रोआर्किटेक्चर - ASRock J4205-IT सह Intel SoC वर आधारित नवीन प्रणालीमध्ये आढळले.

जरी ही आवृत्ती फक्त SoCs मध्ये वापरली जाईल (काबी लेक प्रोसेसर मायक्रोआर्किटेक्चरसह नवीन सिस्टम इंटेल बूट गार्ड 1.x वापरत आहेत), हे Intel SoC प्लॅटफॉर्मसाठी नवीन आर्किटेक्चर पर्यायाचा अभ्यास करण्यात खूप स्वारस्य आहे, ज्यामध्ये लक्षणीय बदल दिसून आले आहेत, उदाहरणार्थ:

BIOS आणि Intel ME क्षेत्र (किंवा त्याऐवजी Intel TXE, Intel SoC च्या परिभाषेनुसार) आता एक IFWI प्रदेश आहेत;
जरी इंटेल बीजी प्लॅटफॉर्मवर सक्षम केले असले तरी, FIT, KEYM, IBBM सारख्या संरचना फ्लॅश मेमरीमध्ये आढळल्या नाहीत;
TXE आणि ISH कोर (x86) व्यतिरिक्त, चिपसेटमध्ये तिसरा कोर जोडला गेला (पुन्हा एआरसी, मार्गाने) - PMC (पॉवर मॅनेजमेंट कंट्रोलर), पॉवर उपप्रणालीची कार्यक्षमता आणि कार्यप्रदर्शन निरीक्षणाशी संबंधित.

नवीन IFWI क्षेत्राची सामग्री खालील मॉड्यूल्सचा संच आहे:

बायस
नाव
वर्णन

0000 2000 तास
SMIP
विक्रेत्याने स्वाक्षरी केलेले ठराविक प्लॅटफॉर्म कॉन्फिगरेशन

0000 6000 तास
RBEP
इंटेल TXE फर्मवेअर कोड विभाग, x86, स्वाक्षरी केलेले इंटेल

0001 0000 तास
पीएमसीपी
इंटेल पीएमसी फर्मवेअर कोड विभाग, एआरसी, इंटेलवर स्वाक्षरी केली

0002 0000 तास
FTPR
इंटेल TXE फर्मवेअर कोड विभाग, x86, स्वाक्षरी केलेले इंटेल

0007 B000h
यूसीओडी
CPU साठी मायक्रोकोड अद्यतने, इंटेलने स्वाक्षरी केलेली

0008 0000 तास
IBBP
UEFI BIOS, SEC/PEI फेज, x86, विक्रेत्याने स्वाक्षरी केलेले

0021 8000 तास
आयएसएचसी
इंटेल ISH फर्मवेअर कोड विभाग, x86, विक्रेत्याने स्वाक्षरी केली आहे

0025 8000 तास
NFTP
इंटेल TXE फर्मवेअर कोड विभाग, x86, स्वाक्षरी केलेले इंटेल

0036 1000 तास
IUNP
अज्ञात

0038 1000 तास
ओबीबीपी
UEFI BIOS, DXE फेज, x86, स्वाक्षरी न केलेले

TXE फर्मवेअरच्या विश्लेषणादरम्यान, हे स्पष्ट झाले की RESET नंतर, TXE प्रोसेसरला CPU (FIT, ACM, RESET वेक्टर ...) साठी अॅड्रेस स्पेसची मूलभूत सामग्री तयार करेपर्यंत या स्थितीत ठेवते. शिवाय, TXE हा डेटा त्याच्या SRAM मध्ये ठेवतो, त्यानंतर तो प्रोसेसरला तिथे तात्पुरता प्रवेश देतो आणि तो RESET वरून “रिलीज” करतो.

रूटकिट्सपासून सावध रहा

बरं, आता "गरम" गोष्टींकडे वळू. आम्‍ही एकदा शोधून काढले की अनेक सिस्‍टमवर, SPI फ्लॅश डिस्क्रिप्टर्समध्‍ये SPI फ्लॅश मेमरीच्‍या प्रदेशात प्रवेश करण्‍याची परवानगी असते जेणेकरून या मेमरीचे सर्व वापरकर्ते कोणताही प्रदेश लिहू आणि वाचू शकतील. त्या. मार्ग नाही.

MEinfo युटिलिटी (इंटेल एसटीके कडून) तपासल्यानंतर, आम्ही पाहिले की या सिस्टम्सवरील उत्पादन मोड बंद नाही, म्हणून, चिपसेट फ्यूज (एफपीएफ) अपरिभाषित स्थितीत सोडले आहेत. होय, अशा प्रकरणांमध्ये Intel BG चालू किंवा बंद होत नाही.

आम्ही खालील प्रणालींबद्दल बोलत आहोत (इंटेल बीजी संदर्भात आणि लेखात नंतर काय वर्णन केले जाईल, आम्ही हसवेल प्रोसेसर मायक्रोआर्किटेक्चर आणि उच्च असलेल्या सिस्टमबद्दल बोलू):

सर्व गीगाबाइट उत्पादने;
सर्व MSI उत्पादने;
लेनोवो लॅपटॉपचे 21 मॉडेल आणि लेनोवो सर्व्हरचे 4 मॉडेल.

अर्थात, आम्ही या विक्रेत्यांना, तसेच इंटेलला शोध कळवला.

कडून पुरेशी प्रतिक्रिया आली लेनोवोज्याने समस्या ओळखली आणि एक पॅच सोडला.

गीगाबाइट त्यांनी असुरक्षिततेची माहिती स्वीकारली असे दिसते, परंतु त्यांनी कोणत्याही प्रकारे टिप्पणी केली नाही.

सह संवाद मारुतीच्या तुमची सार्वजनिक PGP की (त्यांना एनक्रिप्टेड फॉर्ममध्ये सुरक्षितता सल्ला पाठवण्यासाठी) आमच्या विनंतीवर पूर्णपणे थांबवले. त्यांनी सांगितले की ते "हार्डवेअर उत्पादक आहेत आणि पीजीपी की तयार करत नाहीत."

पण मुद्द्याकडे जाऊया. फ्यूज अनिर्दिष्ट स्थितीत सोडलेले असल्याने, वापरकर्ता (किंवा आक्रमणकर्ता) त्यांना स्वतंत्रपणे प्रोग्राम करू शकतो (सर्वात कठीण गोष्ट म्हणजे इंटेल एसटीके शोधा). हे करण्यासाठी, आपण खालील चरण पूर्ण करणे आवश्यक आहे.

1. Windows OS मध्ये बूट करा (सर्वसाधारणपणे, खाली वर्णन केलेल्या क्रिया लिनक्स अंतर्गत देखील केल्या जाऊ शकतात, जर आपण इच्छित OS साठी Intel STK चे analogue विकसित केले असेल). MEinfo युटिलिटी वापरून, या प्रणालीवर फ्यूज प्रोग्राम केलेले नाहीत याची खात्री करा.

2. फ्लॅश प्रोग्रामिंग टूल वापरून फ्लॅश मेमरीची सामग्री वाचा.

3. कोणत्याही UEFI BIOS संपादन साधनाचा वापर करून वाचलेली प्रतिमा उघडा, आवश्यक बदल करा (उदाहरणार्थ रूटकिट सादर करा), ME प्रदेशात विद्यमान KEYM आणि IBBM संरचना तयार/संपादित करा.

चित्र RSA कीचा सार्वजनिक भाग हायलाइट करते, ज्याचा हॅश इंटेल बीजी कॉन्फिगरेशनच्या उर्वरित भागांसह चिपसेट फ्यूजमध्ये प्रोग्राम केला जाईल.

4. फ्लॅश इमेज टूल वापरून, नवीन फर्मवेअर इमेज तयार करा (इंटेल बीजी कॉन्फिगरेशन सेट करून).

5. फ्लॅश प्रोग्रामिंग टूल वापरून फ्लॅश मेमरी करण्यासाठी एक नवीन प्रतिमा लिहा आणि MEinfo वापरून सत्यापित करा की ME क्षेत्रामध्ये आता Intel BG कॉन्फिगरेशन आहे.

6. मॅन्युफॅक्चरिंग मोड बंद करण्यासाठी फ्लॅश प्रोग्रामिंग टूल वापरा.

7. सिस्टम रीबूट होईल, त्यानंतर तुम्ही FPF आता प्रोग्राम केलेले असल्याची पडताळणी करण्यासाठी MEinfo वापरू शकता.

या क्रिया कायमचे या प्रणालीवर इंटेल बीजी सक्षम करा. क्रिया पूर्ववत केली जाऊ शकत नाही, याचा अर्थ:

केवळ रूट कीच्या खाजगी भागाचा मालक (म्हणजे, ज्याने इंटेल बीजी सक्षम केले आहे) या प्रणालीवर UEFI BIOS अद्यतनित करण्यास सक्षम असेल;
जर तुम्ही मूळ फर्मवेअर या प्रणालीवर परत केले, उदाहरणार्थ, प्रोग्रामर वापरून, ते चालूही होणार नाही (सत्यापन त्रुटीच्या बाबतीत अंमलबजावणी धोरणाचा परिणाम);
अशा UEFI BIOS मधून मुक्त होण्यासाठी, तुम्हाला प्रोग्रॅम केलेल्या FPF सह चिपसेट बदलणे आवश्यक आहे “क्लीन” (म्हणजे, जर तुम्हाला इन्फ्रारेड सोल्डरिंग स्टेशनमध्ये कारच्या किंमतीनुसार प्रवेश असेल तर चिपसेट पुनर्विक्री करा किंवा फक्त मदरबोर्ड बदला. ).

असे रूटकिट काय करू शकते हे समजून घेण्यासाठी, तुम्हाला UEFI BIOS वातावरणात तुमचा कोड कार्यान्वित करणे कशामुळे शक्य होते याचे मूल्यांकन करणे आवश्यक आहे. समजा, सर्वात विशेषाधिकारप्राप्त प्रोसेसर मोडमध्ये - SMM. अशा रूटकिटमध्ये खालील गुणधर्म असू शकतात:

OS च्या समांतरपणे कार्यान्वित (आपण SMI व्यत्यय निर्माण करण्यासाठी प्रक्रिया कॉन्फिगर करू शकता, जे टाइमरद्वारे ट्रिगर केले जाईल);
SMM मोडमध्ये असण्याचे सर्व फायदे आहेत (RAM आणि हार्डवेअर संसाधनांच्या सामग्रीमध्ये पूर्ण प्रवेश, OS वरून गुप्तता);
SMM मोडमध्ये लाँच केल्यावर रूटकिटचा प्रोग्राम कोड एनक्रिप्ट आणि डिक्रिप्ट केला जाऊ शकतो. केवळ SMM मोडमध्ये उपलब्ध असलेला कोणताही डेटा एन्क्रिप्शन की म्हणून वापरला जाऊ शकतो. उदाहरणार्थ, SMRAM मधील पत्त्यांच्या संचामधून हॅश. ही की मिळवण्यासाठी, तुम्हाला SMM मध्ये जावे लागेल. आणि हे दोन प्रकारे केले जाऊ शकते. SMM कोडमध्ये RCE शोधा आणि त्याचा फायदा घ्या किंवा तुमचे स्वतःचे SMM मॉड्यूल BIOS मध्ये जोडा, जे आम्ही बूट गार्ड सक्षम केल्यामुळे अशक्य आहे.

अशाप्रकारे, ही भेद्यता आक्रमणकर्त्याला याची अनुमती देते:

सिस्टीममध्ये अज्ञात हेतूचे लपवलेले, न हटवता येणारे रूटकिट तयार करा;
तुमचा कोड इंटेल एसओसी मधील एका चिपसेट कोरवर कार्यान्वित करा, म्हणजे, इंटेल ISH वर (चित्राकडे काळजीपूर्वक पहा).

जरी इंटेल ISH उपप्रणालीची क्षमता अद्याप शोधली गेली नसली तरी, हे इंटेल ME साठी एक मनोरंजक आक्रमण वेक्टर असल्याचे दिसते.

निष्कर्ष

अभ्यासामुळे इंटेल बूट गार्ड तंत्रज्ञानाच्या ऑपरेशनचे तांत्रिक वर्णन प्राप्त करणे शक्य झाले. अस्पष्टता मॉडेलद्वारे इंटेलच्या सुरक्षिततेमधील काही रहस्ये वजा करा.
एक आक्रमण परिस्थिती सादर केली आहे जी तुम्हाला सिस्टममध्ये अनइन्स्टॉल करण्यायोग्य रूटकिट तयार करण्यास अनुमती देते.
आम्ही पाहिले की आधुनिक इंटेल प्रोसेसर BIOS चालू होण्यापूर्वीच बरेच प्रोप्रायटरी कोड कार्यान्वित करण्यास सक्षम आहेत.
Intel 64 आर्किटेक्चर असलेले प्लॅटफॉर्म विनामूल्य सॉफ्टवेअर चालवण्यासाठी कमी कमी योग्य होत आहेत: हार्डवेअर पडताळणी, मालकी तंत्रज्ञान आणि उपप्रणालींची वाढती संख्या (SOC चिपसेटमध्ये तीन कोर: x86 ME, x86 ISH आणि ARC PMC).

शमन

जे विक्रेते जाणूनबुजून मॅन्युफॅक्चरिंग मोड उघडे ठेवतात त्यांनी ते बंद करण्याचे सुनिश्चित केले पाहिजे. आतापर्यंत, त्यांचे फक्त डोळे बंद आहेत आणि नवीन काबी लेक सिस्टम हे दर्शवतात.

-closemnf पॅरामीटरसह फ्लॅश प्रोग्रामिंग टूल चालवून वापरकर्ते त्यांच्या सिस्टमवर इंटेल BG अक्षम करू शकतात (जे वर्णन केलेल्या भेद्यतेसाठी संवेदनाक्षम आहेत). प्रथम, तुम्ही (MEinfo वापरून) हे सुनिश्चित केले पाहिजे की ME प्रदेशातील Intel BG कॉन्फिगरेशन FPF मध्ये प्रोग्रामिंग केल्यानंतर हे तंत्रज्ञान बंद करण्याची तरतूद करते.

स्त्रोत: www.habr.com

Schrödinger च्या विश्वसनीय डाउनलोड. इंटेल बूट गार्ड