Մենք առաջարկում ենք նորից իջնել ցածր մակարդակ և խոսել որոնվածի x86-ի հետ համատեղելի համակարգչային հարթակների անվտանգության մասին։ Այս անգամ հետազոտության հիմնական բաղադրիչը Intel Boot Guard-ն է (չշփոթել Intel BIOS Guard-ի հետ)՝ ապարատային աջակցվող BIOS-ի վստահելի բեռնման տեխնոլոգիա, որը համակարգչային համակարգի վաճառողը կարող է մշտապես միացնել կամ անջատել արտադրության փուլում: Դե, մենք արդեն գիտենք հետազոտության բաղադրատոմսը՝ մանր կտրատել այս տեխնոլոգիայի ներդրումը հակադարձ ճարտարագիտության միջոցով, նկարագրել դրա ճարտարապետությունը՝ լրացնելով այն չփաստաթղթավորված մանրամասներով, համեմել հարձակման վեկտորներով՝ համտեսելու և խառնելու համար: Եկեք կրակ ավելացնենք մի պատմության հետ այն մասին, թե ինչպես է տարիներ շարունակ մի քանի վաճառողների արտադրության մեջ կլոնավորված սխալը թույլ է տալիս պոտենցիալ հարձակվողին օգտագործել այս տեխնոլոգիան՝ ստեղծելու թաքնված rootkit, որը չի կարող հեռացվել (նույնիսկ ծրագրավորողի կողմից) համակարգում:
Ի դեպ, հոդվածը հիմնված է համաժողովի «On Guard for Rootkits. Intel BootGuard» զեկույցների վրա։ և 29-րդ հանդիպումը (երկու ներկայացումներն էլ ).
Intel 64 ճարտարապետությամբ համակարգչային պլատֆորմի որոնվածը
Սկսենք, եկեք պատասխանենք հարցին. ինչպիսի՞ն է Intel 64 ճարտարապետությամբ ժամանակակից համակարգչային հարթակի որոնվածը: Իհարկե, UEFI BIOS: Բայց այս պատասխանը ճշգրիտ չի լինի։ Եկեք նայենք նկարին, որը ցույց է տալիս այս ճարտարապետության աշխատասեղանի (նոութբուքի) տարբերակը:
Հիմքը հղումն է.
- Պրոցեսոր (CPU, Կենտրոնական պրոցեսորային միավոր), որը, բացի հիմնական միջուկներից, ունի ներկառուցված գրաֆիկական միջուկ (ոչ բոլոր մոդելներում) և հիշողության կարգավորիչ (IMC, Ինտեգրված հիշողության վերահսկիչ);
- Chipset (PCH, Platform Controller Hub), որը պարունակում է տարբեր կարգավորիչներ ծայրամասային սարքերի հետ փոխազդելու և ենթահամակարգերի կառավարման համար: Դրանց թվում է տխրահռչակ Intel Management Engine-ը (ME), որն ունի նաև որոնվածը (Intel ME firmware):
Նոթբուքերի համար, բացի վերը նշվածից, անհրաժեշտ է ինտեգրված վերահսկիչ (ACPI EC, Advanced Control and Power Interface Embedded Controller), որը պատասխանատու է էներգիայի ենթահամակարգի, touchpad-ի, ստեղնաշարի, Fn ստեղների (էկրանի պայծառությունը, ձայնի ծավալը, ստեղնաշարը) շահագործման համար: հետին լույս և այլն) ) և ավելին: Եվ նա ունի նաև իր որոնվածը:
Այսպիսով, վերը նշված որոնվածի համադրությունը համակարգչային հարթակի որոնվածն է (համակարգի որոնվածը), որը պահվում է ընդհանուր SPI ֆլեշ հիշողության վրա: Որպեսզի այս հիշողության օգտագործողները չշփոթվեն, թե որտեղ է ինչ-որ մեկը պառկած, այս հիշողության բովանդակությունը բաժանվում է հետևյալ շրջանների (ինչպես ցույց է տրված նկարում).
- UEFI BIOS;
- ACPI EC որոնվածը (առանձին շրջան հայտնվեց Skylake պրոցեսորի միկրոճարտարապետությամբ (2015 թ.), բայց բնության մեջ մենք դեռ չենք տեսել դրա օգտագործման օրինակներ, ուստի ներկառուցված վերահսկիչի որոնվածը դեռևս UEFI BIOS-ի մի մասն է);
- Intel ME որոնվածը;
- ներկառուցված GbE (Gigabit Ethernet) ցանցային ադապտերի կոնֆիգուրացիա (MAC հասցե և այլն);
- ֆլեշ նկարագրիչներ - ֆլեշ հիշողության հիմնական շրջան, որը պարունակում է ցուցիչներ դեպի այլ տարածաշրջաններ, ինչպես նաև դրանց մուտք գործելու թույլտվություններ:
Տարածաշրջանների հասանելիության տարբերակումը (ըստ նշված թույլտվությունների) իրականացվում է SPI ավտոբուսի վարպետի կողմից՝ չիպսեթում ներկառուցված SPI կարգավորիչը, որի միջոցով հասանելի է այս հիշողությունը: Եթե թույլտվությունները սահմանված են Intel-ի կողմից առաջարկված արժեքների վրա (անվտանգության նկատառումներով), ապա SPI ֆլեշ-ի յուրաքանչյուր օգտվող ունի լիարժեք մուտք (կարդալ/գրել) միայն իր տարածաշրջան: Մնացածները կա՛մ միայն կարդալու են, կա՛մ անհասանելի: Հայտնի փաստ. շատ համակարգերում պրոցեսորը լիարժեք մուտք ունի UEFI BIOS և GbE, կարդալու հասանելիություն միայն ֆլեշ նկարագրիչներին և ընդհանրապես մուտք չունի Intel ME տարածաշրջան: Ինչու՞ շատերը և ոչ բոլորը: Այն, ինչ առաջարկվում է, ընտրովի է: Մենք ձեզ ավելի ուշ կպատմենք հոդվածում:
Համակարգչային հարթակի որոնվածը փոփոխություններից պաշտպանելու մեխանիզմներ
Ակնհայտ է, որ համակարգչային պլատֆորմի որոնվածը պետք է պաշտպանված լինի հնարավոր փոխզիջումներից, ինչը թույլ կտա պոտենցիալ հարձակվողին տեղ գրավել դրանում (գոյատևել ՕՀ-ի թարմացումները / վերատեղադրումները), կատարել իրենց ծածկագիրը առավել արտոնյալ ռեժիմներով և այլն: Իսկ SPI ֆլեշ հիշողության շրջանների հասանելիության սահմանազատումը, իհարկե, բավարար չէ։ Հետևաբար, յուրաքանչյուր կատարողական միջավայրին հատուկ տարբեր մեխանիզմներ օգտագործվում են որոնվածը փոփոխություններից պաշտպանելու համար:
Այսպիսով, Intel ME որոնվածը ստորագրված է ամբողջականության և իսկության վերահսկման համար և ստուգվում է ME կարգավորիչի կողմից ամեն անգամ, երբ այն բեռնվում է ME UMA հիշողության մեջ: Այս ստուգման գործընթացն արդեն քննարկվել է մեր կողմից մեկում նվիրված Intel ME ենթահամակարգին:
Իսկ ACPI EC որոնվածը, որպես կանոն, ստուգվում է միայն ամբողջականության համար։ Այնուամենայնիվ, հաշվի առնելով այն փաստը, որ այս երկուականը ներառված է UEFI BIOS-ում, այն գրեթե միշտ ենթարկվում է նույն պաշտպանության մեխանիզմներին, որոնք օգտագործում է UEFI BIOS-ը: Եկեք խոսենք նրանց մասին:
Այս մեխանիզմները կարելի է բաժանել երկու կատեգորիայի.
Գրեք պաշտպանություն UEFI BIOS տարածաշրջանում
- SPI ֆլեշ հիշողության բովանդակության ֆիզիկական պաշտպանություն գրելու պաշտպանիչ jumper-ով;
- UEFI BIOS շրջանի պրոյեկցիայի պաշտպանություն պրոցեսորի հասցեների տարածքում՝ օգտագործելով չիպսեթի PRx ռեգիստրները.
- UEFI BIOS տարածաշրջանում գրելու փորձերի արգելափակում` ստեղծելով և մշակելով համապատասխան SMI ընդհատումը` չիպսեթի ռեգիստրներում BIOS_WE / BLE և SMM_BWP բիթերը դնելով.
- Այս պաշտպանության ավելի առաջադեմ տարբերակը Intel BIOS Guard-ն է (PFAT):
Այս մեխանիզմներից բացի, վաճառողները կարող են մշակել և իրականացնել իրենց անվտանգության միջոցները (օրինակ՝ UEFI BIOS-ի թարմացումներով պարկուճների ստորագրում):
Կարևոր է նշել, որ կոնկրետ համակարգի վրա (կախված վաճառողից) վերը նշված բոլոր պաշտպանական մեխանիզմները չեն կարող կիրառվել, դրանք կարող են ընդհանրապես չկիրառվել կամ կիրառվել խոցելի ձևով: Այս մեխանիզմների և դրանց ներդրման հետ կապված իրավիճակի մասին ավելին կարող եք կարդալ այստեղ . Հետաքրքրվողներին խորհուրդ ենք տալիս կարդալ UEFI BIOS-ի անվտանգության մասին հոդվածների ամբողջ շարքը .
UEFI BIOS նույնականացման ստուգում
Երբ մենք խոսում ենք վստահելի բեռնախցիկի տեխնոլոգիաների մասին, առաջին բանը, որ գալիս է մտքում, անվտանգ բեռնախցիկն է: Այնուամենայնիվ, ճարտարապետական առումով այն նախատեսված է UEFI BIOS-ից դուրս գտնվող բաղադրիչները (վարորդներ, բեռնիչներ և այլն) նույնականացնելու և ոչ թե բուն որոնվածը:
Հետևաբար, Intel-ը Bay Trail միկրոճարտարապետությամբ (2012) SoC-ներում ներդրեց ապարատային չփոխարկվող Secure Boot (Verified Boot), որը ոչ մի կապ չունի վերոհիշյալ Secure Boot տեխնոլոգիայի հետ: Ավելի ուշ (2013) այս մեխանիզմը բարելավվեց և Intel Boot Guard անունով թողարկվեց Haswell միկրոճարտարապետությամբ աշխատասեղանների համար:
Նախքան Intel Boot Guard-ը նկարագրելը, եկեք նայենք Intel 64 ճարտարապետության կատարողական միջավայրերին, որոնք համակցված այս վստահելի բեռնման տեխնոլոգիայի վստահության արմատներն են:
Intel պրոցեսոր
Cap-ը հուշում է, որ պրոցեսորը Intel 64 ճարտարապետության հիմնական կատարողական միջավայրն է: Ինչո՞ւ է դա նաև վստահության հիմքում: Ստացվում է, որ դա հետևյալ տարրերի տիրապետումն է, որ դա դարձնում է այդպիսին.
- Microcode ROM-ը չցնդող, չվերագրվող հիշողություն է միկրոկոդը պահելու համար: Ենթադրվում է, որ միկրոկոդը պրոցեսորի հրահանգների համակարգի իրականացումն է ամենապարզ հրահանգների վրա: Դա տեղի է ունենում նաև միկրոկոդի մեջ . Այսպիսով, BIOS-ում դուք կարող եք գտնել երկուականներ միկրոկոդի թարմացումներով (դրանք տեղադրվում են բեռնման ժամանակ, քանի որ ROM-ը չի կարող վերագրվել): Այս երկուականների բովանդակությունը կոդավորված է, ինչը մեծապես բարդացնում է վերլուծությունը (հետևաբար, միկրոկոդի կոնկրետ բովանդակությունը հայտնի է միայն այն մշակողներին), և ստորագրված է ամբողջականությունն ու իսկությունը վերահսկելու համար.
- AES բանալին՝ միկրոկոդի թարմացումների բովանդակությունը վերծանելու համար.
- RSA հանրային բանալու հեշ, որը ստուգում է միկրոկոդի թարմացումների ստորագրությունը.
- RSA հանրային բանալու հեշ, որը ստուգում է Intel-ի կողմից մշակված ACM (Authenticated Code Module) կոդի մոդուլների ստորագրությունը, որոնք պրոցեսորը կարող է գործարկել մինչև BIOS-ի գործարկումը (բարև միկրոկոդ) կամ դրա շահագործման ընթացքում, երբ տեղի են ունենում որոշ իրադարձություններ:
Intel ME
Մեր բլոգում այս ենթահամակարգը նվիրված էր . Հիշեցնենք, որ այս գործարկվող միջավայրը հիմնված է չիպսեթում ներկառուցված միկրոկոնտրոլերի վրա և ամենաթաքնվածն ու արտոնյալն է համակարգում:
Չնայած գաղտագողի, Intel ME-ն նաև վստահության արմատն է, քանի որ այն ունի.
- ME ROM - ոչ անկայուն, չվերագրվող հիշողություն (թարմացման մեթոդ չի տրամադրվում), որը պարունակում է մեկնարկային կոդը, ինչպես նաև RSA հանրային բանալու SHA256 հեշը, որը ստուգում է Intel ME որոնվածի ստորագրությունը.
- AES բանալին՝ գաղտնի տեղեկատվության պահպանման համար.
- մուտք դեպի մի շարք ապահովիչներ (FPFs, Field Programmable Fuses), որոնք ինտեգրված են չիպսեթի մեջ՝ որոշակի տեղեկատվության մշտական պահպանման համար, ներառյալ համակարգչային համակարգի վաճառողի կողմից նշված տեղեկատվությունը:
Intel Boot Guard 1.x
Փոքր հերքում: Intel Boot Guard տեխնոլոգիայի տարբերակների համարները, որոնք մենք օգտագործում ենք այս հոդվածում, կամայական են և կարող են որևէ կապ չունենալ Intel-ի ներքին փաստաթղթերում օգտագործվող համարակալման հետ: Բացի այդ, այստեղ տրված այս տեխնոլոգիայի ներդրման մասին տեղեկատվությունը ստացվել է հակադարձ ճարտարագիտության ժամանակ և կարող է պարունակել անճշտություններ՝ համեմատած Intel Boot Guard-ի բնութագրերի հետ, որոնք դժվար թե երբևէ հրապարակվեն:
Այսպիսով, Intel Boot Guard (BG) ապարատային աջակցությամբ UEFI BIOS նույնականացման տեխնոլոգիա է: Դատելով նրա փոքր նկարագրությունից գրքում [Platform Embedded Security Technology Revealed, Chapter Boot with Integrity, or Not Boot] գրքում, այն աշխատում է որպես վստահելի բեռնախցիկի շղթա: Եվ դրա առաջին հղումը պրոցեսորի ներսում գտնվող բեռնման կոդը (միկրոկոդ) է, որը գործարկվում է RESET իրադարձությունից (չշփոթել BIOS-ի RESET վեկտորի հետ): Պրոցեսորը գտնում է կոդային մոդուլը (Intel BG startup ACM), որը մշակվել և ստորագրվել է Intel-ի կողմից SPI ֆլեշ հիշողության վրա, բեռնում է այն իր քեշում, ստուգում է այն (վերևում արդեն նշվեց, որ պրոցեսորն ունի հանրային բանալու հեշ, որը ստուգում է ACM ստորագրությունը: ) և սկսվում է:
Կոդի այս մոդուլը պատասխանատու է UEFI BIOS-ի մի փոքր մեկնարկային մասի ստուգման համար՝ Initial Boot Block (IBB), որն, իր հերթին, պարունակում է UEFI BIOS-ի հիմնական մասի ստուգման գործառույթ: Այսպիսով, Intel BG-ն թույլ է տալիս ստուգել BIOS-ի իսկությունը նախքան ՕՀ-ն բեռնելը (որը կարող է իրականացվել Secure Boot տեխնոլոգիայի հսկողության ներքո):
Intel BG տեխնոլոգիան ապահովում է աշխատանքի երկու եղանակ (և մեկը մյուսին չի խանգարում, այսինքն՝ երկու ռեժիմները կարող են միացված լինել համակարգում, և երկուսն էլ կարող են անջատվել):
Չափված կոշիկ
Չափված բեռնման (ՄԲ) ռեժիմում բեռնման յուրաքանչյուր բաղադրիչ (սկսած պրոցեսորի բեռնման ROM-ից) «չափում է» հաջորդը` օգտագործելով Trusted Platform Module-ի (TPM) հնարավորությունները: Նրանց համար, ովքեր չգիտեն, թույլ տվեք բացատրել.
TPM-ն ունի PCR-ներ (պլատֆորմի կազմաձևման ռեգիստրներ), որոնք գրանցում են հեշինգի գործողության արդյունքը՝ համաձայն բանաձևի.
Նրանք. ընթացիկ PCR արժեքը կախված է նախորդից, և այդ գրանցամատյանները զրոյացվում են միայն այն ժամանակ, երբ համակարգը RESET է:
Այսպիսով, ՄԲ ռեժիմում, ժամանակի ինչ-որ պահի, PCR-ները արտացոլում են «չափված» կոդի կամ տվյալների եզակի (հեշ գործողության հնարավորությունների սահմաններում) նույնացուցիչը: PCR արժեքները կարող են օգտագործվել որոշ տվյալների (TPM_Seal) գործողության կոդավորման մեջ: Դրանից հետո դրանց վերծանումը (TPM_Unseal) հնարավոր կլինի միայն այն դեպքում, եթե բեռնման արդյունքում PCR արժեքները չեն փոխվել (այսինքն՝ ոչ մի «չափված» բաղադրիչ չի փոփոխվել):
Ստուգված բեռնախցիկ
Ամենասարսափելին նրանց համար, ովքեր սիրում են փոփոխել UEFI BIOS-ը, Verified Boot (VB) ռեժիմն է, որում յուրաքանչյուր բեռնման բաղադրիչ կրիպտոգրաֆիկ կերպով ստուգում է հաջորդի ամբողջականությունն ու իսկությունը: Իսկ ստուգման սխալի դեպքում (հետևյալներից մեկը) տեղի է ունենում.
- 1 րոպեից մինչև 30 րոպե ժամանակի անջատում (որպեսզի օգտագործողը ժամանակ ունենա հասկանալու, թե ինչու իր համակարգիչը չի բեռնվում և, հնարավորության դեպքում, կփորձի վերականգնել BIOS-ը);
- անհապաղ անջատում (այնպես, որ օգտագործողը ժամանակ չունենա հասկանալու և, ավելին, անելու);
- ուղիղ դեմքով աշխատանքի շարունակություն (այն դեպքը, երբ անվտանգության համար ժամանակ չկա, քանի որ կան ավելի կարևոր գործեր):
Գործողությունների ընտրությունը կախված է նշված Intel BG-ի կազմաձևից (մասնավորապես, այսպես կոչված, կատարողական քաղաքականությունից), որը մշտապես գրանցվում է համակարգչային պլատֆորմի վաճառողի կողմից հատուկ մշակված պահեստում՝ չիպսեթների ապահովիչներ (FPF): Այս կետի վրա մենք ավելի մանրամասն կանդրադառնանք ավելի ուշ:
Բացի կոնֆիգուրացիայից, վաճառողը ստեղծում է երկու RSA 2048 բանալի և ստեղծում է տվյալների երկու կառուցվածք (ցուցված է նկարում).
- Վաճառողի արմատական բանալու մանիֆեստը (KEYM, OEM Root Key Manifest), որը դնում է այս մանիֆեստի SVN-ը (անվտանգության տարբերակի համարը), հաջորդ մանիֆեստի հանրային բանալու SHA256 հեշը, RSA հանրային բանալին (այսինքն՝ հրապարակային մասը: վաճառողի արմատային բանալի)՝ ստուգելու այս մանիֆեստի ստորագրությունը և հենց ստորագրությունը.
- IBB Manifest (IBBM, Initial Boot Block Manifest), որը դնում է այս մանիֆեստի SVN-ը, IBB-ի SHA256 հեշը, այս մանիֆեստի ստորագրությունը ստուգելու հանրային բանալին և հենց ստորագրությունը:
OEM Root Key-ի SHA256 հեշը մշտապես գրված է չիպսեթի ապահովիչներում (FPF), ճիշտ ինչպես Intel BG-ի կոնֆիգուրացիան: Եթե Intel BG կոնֆիգուրացիան նախատեսում է այս տեխնոլոգիայի ընդգրկումը, ապա այսուհետ այս համակարգը միայն OEM Root Key-ի մասնավոր մասի սեփականատերը կարող է թարմացնել BIOS-ը (այսինքն՝ կարողանալ վերահաշվարկել այդ մանիֆեստները), այսինքն. վաճառող.
Երբ նայում եք նկարին, անմիջապես կասկածներ են առաջանում ստուգման այդքան երկար շղթայի անհրաժեշտության մասին. դուք կարող եք օգտագործել մեկ մանիֆեստ: Ինչու՞ բարդացնել:
Փաստորեն, Intel-ն այդպիսով վաճառողին հնարավորություն է տալիս օգտագործել տարբեր IBB ստեղներ տարբեր ապրանքային գծերի համար և մեկը որպես արմատ: Եթե IBB բանալիի մասնավոր հատվածը (որը ստորագրում է երկրորդ մանիֆեստը) արտահոսում է, միջադեպը կազդի միայն մեկ ապրանքի գծի վրա և միայն այնքան ժամանակ, մինչև վաճառողը չգեներացնի նոր զույգ և միացնի վերահաշվարկված մանիֆեստները BIOS-ի հաջորդ թարմացման մեջ:
Բայց եթե արմատային բանալին վտանգված է (որով ստորագրված է առաջին մանիֆեստը), այն հնարավոր չի լինի փոխարինել, չեղյալ համարելու կարգը նախատեսված չէ: այս բանալու հանրային մասի հեշը մեկընդմիշտ ծրագրավորվում է FPF-ներում:
Intel Boot Guard-ի կոնֆիգուրացիա
Այժմ եկեք ավելի սերտ նայենք Intel BG-ի կազմաձևին և դրա ստեղծման գործընթացին: Եթե նայեք Intel System Tool Kit-ից (STK) Flash Image Tool-ի համապատասխան ներդիրին, ապա կնկատեք, որ Intel BG-ի կոնֆիգուրացիան ներառում է վաճառողի արմատական բանալի հանրային մասի հեշ, մի քանի անհասկանալի: արժեքներ և այլն։ 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;
};Ընդհանուր առմամբ, Intel BG կոնֆիգուրացիան շատ ճկուն կառույց է: Դիտարկենք, օրինակ, Force_Boot_Guard_ACM դրոշը: Երբ այն մաքրվի, եթե BG գործարկման ACM մոդուլը SPI ֆլեշի վրա չգտնվի, վստահելի բեռնում չի առաջանա: Դա անվստահելի կլինի։
Մենք արդեն գրել ենք վերևում, որ VB ռեժիմի կիրառման քաղաքականությունը կարող է կազմաձևվել այնպես, որ եթե ստուգումը ձախողվի, նորից անվստահելի ներբեռնում տեղի ունենա:
Թողեք նման բաները վաճառողներին...
Կոմունալ ծրագրի GUI-ն ապահովում է հետևյալ «պատրաստի» պրոֆիլները.
Թիվ
Ռեժիմը
Նկարագրություն
0
No_FVME
Intel BG տեխնոլոգիան անջատված է
1
VE
VB ռեժիմը միացված է, անջատվում է ժամանակի դադարով
2
VME
երկու ռեժիմներն էլ միացված են (VB և MB), անջատվում են ժամանակի դադարով
3
VM
երկու ռեժիմներն էլ միացված են՝ առանց համակարգը անջատելու
4
ՀԻՆԳ
VB ռեժիմը միացված է, անմիջապես անջատում
5
FVME
երկու ռեժիմները միացված են, անհապաղ անջատում
Ինչպես արդեն նշվեց, Intel BG-ի կոնֆիգուրացիան պետք է մեկընդմիշտ գրվի համակարգի վաճառողի կողմից չիպսեթի ապահովիչներում (FPF)՝ չիպսեթի ներսում փոքր (ըստ չստուգված տեղեկությունների, ընդամենը 256 բայթ) ապարատային տեղեկատվության պահեստ, որը կարող է ծրագրավորվել դրսում: Intel-ի արտադրական օբյեկտներից (այդ իսկ պատճառով Դաշտային ծրագրավորվող ապահովիչներ):
Այն հիանալի է կոնֆիգուրացիան պահելու համար, քանի որ.
- ունի մեկանգամյա ծրագրավորվող տվյալների պահպանման տարածք (հենց այնտեղ, որտեղ գրված է Intel BG կոնֆիգուրացիան);
- միայն Intel ME-ն կարող է կարդալ և ծրագրավորել այն:
Այսպիսով, Intel BG տեխնոլոգիայի կոնֆիգուրացիան որոշակի համակարգի վրա սահմանելու համար վաճառողը արտադրության ընթացքում կատարում է հետևյալը.
- Օգտագործելով Flash Image Tool-ը (Intel STK-ից), ստեղծում է որոնվածի պատկեր՝ տվյալ Intel BG կոնֆիգուրացիայով, որպես փոփոխականներ Intel ME տարածաշրջանի ներսում (այսպես կոչված, FPF-ների ժամանակավոր հայելին);
- Flash Programming Tool-ի միջոցով (Intel STK-ից) գրում է այս պատկերը համակարգի SPI ֆլեշ հիշողության մեջ և փակում այսպես կոչված. արտադրության ռեժիմ (այս դեպքում համապատասխան հրամանն ուղարկվում է Intel ME):
Այս գործողությունների արդյունքում Intel ME-ն կհանձնի FPF-ներին ME տարածաշրջանի FPF-ների հայելից նշված արժեքները, թույլտվությունները SPI ֆլեշ նկարագրիչներում կսահմանի Intel-ի կողմից առաջարկված արժեքներին (նկարագրված է սկզբում: հոդված) և կատարել համակարգի RESET:
Intel Boot Guard-ի իրականացման վերլուծություն
Այս տեխնոլոգիայի ներդրումը կոնկրետ օրինակով վերլուծելու համար մենք ստուգեցինք հետևյալ համակարգերը Intel BG տեխնոլոգիայի հետքերի համար.
Համակարգ
Նշում
Գիգաբայթ GA-H170-D3H
Skylake, կա աջակցություն
Գիգաբայթ GA-Q170-D3H
Skylake, կա աջակցություն
Գիգաբայթ GA-B150-HD3
Skylake, կա աջակցություն
MSI H170A Gaming Pro
Սքայլեյք, ոչ մի աջակցություն
Lenovo ThinkPad 460
Skylake, հասանելի աջակցություն, միացված տեխնոլոգիա
Lenovo Yoga 2 Pro
Հասվել, ոչ մի աջակցություն
Lenovo U330p
Հասվել, ոչ մի աջակցություն
«Աջակցություն» նշանակում է Intel BG գործարկման ACM մոդուլի, վերը նշված մանիֆեստների և BIOS-ում համապատասխան ծածկագրի առկայությունը, այսինքն. իրականացումներ վերլուծության համար։
Որպես օրինակ՝ վերցնենք գրասենյակից ներբեռնվածը։ SPI ֆլեշ հիշողության վաճառողի կայքի պատկերը Gigabyte GA-H170-D3H-ի համար (տարբերակ F4):
Intel CPU boot ROM
Նախ, եկեք խոսենք պրոցեսորի գործողությունների մասին, եթե Intel BG տեխնոլոգիան միացված է:
Հնարավոր չեղավ գտնել վերծանված միկրոկոդի նմուշներ, հետևաբար, թե ինչպես են իրականացվում ստորև նկարագրված գործողությունները (միկրոկոդի կամ ապարատային) բաց հարց է: Այնուամենայնիվ, այն, որ ժամանակակից Intel պրոցեսորները «կարող են» կատարել այդ գործողությունները, փաստ է։
RESET վիճակից դուրս գալուց հետո պրոցեսորը (որի հասցեների տարածքում արդեն քարտեզագրված է ֆլեշ հիշողության պարունակությունը) գտնում է FIT-ը (Firmware Interface Table): Այն գտնելը հեշտ է, դրա ցուցիչը գրված է 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;
};
EntryType դաշտը ցույց է տալիս այս մուտքի բլոկի տեսակը: Մենք գիտենք մի քանի տեսակներ.
enum FIT_ENTRY_TYPES
{
FIT_HEADER = 0,
MICROCODE_UPDATE,
BG_ACM,
BIOS_INIT = 7,
TPM_POLICY,
BIOS_POLICY,
TXT_POLICY,
BG_KEYM,
BG_IBBM
};Այժմ ակնհայտ է, որ գրառումներից մեկը մատնանշում է Intel BG ստարտափի ACM երկուականի գտնվելու վայրը։ Այս երկուականի վերնագրի կառուցվածքը բնորոշ է Intel-ի կողմից մշակված կոդի մոդուլներին (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];
};
Պրոցեսորը բեռնում է այս երկուականը իր քեշի մեջ, ստուգում և գործարկում:
Intel BG ստարտափ ACM
Այս ԱԿՄ-ի աշխատանքի վերլուծության արդյունքում պարզ դարձավ, որ այն անում է հետևյալը.
- ստանում է Intel ME-ից Intel BG կոնֆիգուրացիան, որը գրված է չիպսեթի ապահովիչների վրա (FPF);
- գտնում է 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 Root Key-ի հանրային բանալին ստուգելու համար մենք հիշեցնում ենք, որ ապահովիչներից օգտագործվում է SHA256 հեշը, որն այս պահին արդեն ստացվել է Intel 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} մոդուլն է։
Դրա խնդիրն է փնտրել (GUID-ի միջոցով) DXE-ի համար հեշ աղյուսակ և հաստատել 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-ի դեպքում պարզվեց, որ դա BootGuardPei {B41956E1-7CA2-42DB-9562-168389F0F066} մոդուլն է, որը մշակվել է AMI-ի կողմից և, հետևաբար, առկա է ցանկացած AMI BIOS-ում՝ Intel BG աջակցությամբ:
Գործողության ալգորիթմը փոքր-ինչ տարբեր է, սակայն այն հանգում է նույնին.
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;
};Intel Boot Guard 2.x
Եկեք համառոտ խոսենք Intel Boot Guard-ի մեկ այլ ներդրման մասին, որը հայտնաբերվել է ավելի նոր համակարգում՝ հիմնված Intel SoC-ի վրա՝ Apollo Lake միկրոճարտարապետությամբ՝ ASRock J4205-IT:
Թեև այս տարբերակը կօգտագործվի միայն SoC-ներում (Kaby Lake պրոցեսորային միկրոճարտարապետությամբ նոր համակարգերը շարունակում են օգտագործել Intel Boot Guard 1.x), այն մեծ հետաքրքրություն է ներկայացնում Intel SoC-ների վրա հիմնված պլատֆորմների համար նոր ճարտարապետական տարբերակի ուսումնասիրման հարցում, որը շոշափելի է դարձել: փոփոխություններ, օրինակ.
- BIOS-ը և Intel ME տարածաշրջանները (ավելի ճիշտ՝ Intel TXE, ըստ Intel SoC տերմինաբանության) այժմ հանդիսանում են մեկ IFWI տարածաշրջան;
- չնայած Intel BG-ն միացված էր հարթակում, այնպիսի կառույցներ, ինչպիսիք են FIT, KEYM, IBBM, չեն հայտնաբերվել ֆլեշ հիշողության մեջ.
- բացի TXE և ISH միջուկներից (x86), չիպսետին ավելացվել է երրորդ միջուկը (ի դեպ, կրկին ARC)՝ PMC (Power Management Controller), որը կապված է էներգիայի ենթահամակարգի գործունակության և կատարողականի մոնիտորինգի ապահովման հետ:
Նոր IFWI տարածաշրջանի բովանդակությունը հետևյալ մոդուլներից է.
կողմնակալություն
անուն
Նկարագրություն
0000 ժ
SMIP
որոշ հարթակի կոնֆիգուրացիա՝ ստորագրված վաճառողի կողմից
0000 ժ
RBEP
Intel TXE որոնվածը ծածկագրի բաժին, x86, ստորագրված Intel-ի կողմից
0001 ժ
PMCP
որոնվածի կոդի բաժին Intel PMC, ARC, ստորագրված Intel-ի կողմից
0002 ժ
FTPR
Intel TXE որոնվածը ծածկագրի բաժին, x86, ստորագրված Intel-ի կողմից
0007B000h
UCOD
CPU-ի միկրոկոդի թարմացումները ստորագրված են Intel-ի կողմից
0008 ժ
IBBP
UEFI BIOS, SEC/PEI փուլեր, x86, ստորագրված է վաճառողը
0021 ժ
ISHC
Intel ISH որոնվածի կոդ բաժինը, x86, ստորագրված վաճառողի կողմից
0025 ժ
NFTP
Intel TXE որոնվածը ծածկագրի բաժին, x86, ստորագրված Intel-ի կողմից
0036 ժ
IUNP
անհայտ
0038 ժ
OBBP
UEFI BIOS, DXE փուլ, x86, անստորագիր
TXE որոնվածի վերլուծության ընթացքում ակնհայտ դարձավ, որ RESET-ից հետո TXE-ն պահում է պրոցեսորը այս վիճակում, մինչև այն պատրաստի պրոցեսորի համար հասցեական տարածքի հիմնական բովանդակությունը (FIT, ACM, RESET վեկտոր ...): Ավելին, TXE-ն այս տվյալները տեղադրում է իր SRAM-ում, որից հետո ժամանակավորապես ապահովում է պրոցեսորին հասանելիություն այնտեղ և «ազատում» այն RESET-ից։
Rootkits-ի պահպանության վրա
Դե ինչ, հիմա անցնենք «թեժին». Մի անգամ մենք հայտնաբերեցինք, որ շատ համակարգերում SPI ֆլեշ նկարագրիչները թույլտվություն ունեն մուտք գործելու SPI ֆլեշ հիշողության շրջաններ, որպեսզի այս հիշողության բոլոր օգտվողները կարողանան ինչպես գրել, այնպես էլ կարդալ ցանկացած տարածաշրջան: Նրանք. ոչ մի դեպքում.
MEinfo կոմունալից (Intel STK-ից) ստուգելուց հետո մենք տեսանք, որ այս համակարգերի արտադրության ռեժիմը փակված չէ, հետևաբար, չիպսեթի ապահովիչները (FPF) մնացել են անորոշ վիճակում: Այո, Intel BG-ն նման դեպքերում ոչ միացված է, ոչ անջատված:
Խոսքը հետևյալ համակարգերի մասին է (ինչ վերաբերում է Intel BG-ին և այն, ինչ նկարագրվելու է ավելի ուշ հոդվածում, մենք կխոսենք Haswell պրոցեսորային միկրոճարտարապետությամբ և ավելի բարձր համակարգերի մասին).
- բոլոր Gigabyte արտադրանքները;
- բոլոր MSI արտադրանքները;
- 21 Lenovo նոութբուքերի մոդելներ և 4 Lenovo սերվերի մոդելներ:
Իհարկե, գտածոյի մասին մենք հայտնել ենք այս վաճառողներին, ինչպես նաև Intel-ին:
Համարժեք արձագանքը հետևեց միայն Lenovoով ճանաչեց խնդիրը և .
Gigabyte Կարծես թե ընդունել են խոցելիության մասին տեղեկությունը, բայց ոչ մի կերպ չեն մեկնաբանել։
Հաղորդակցություն հետ MSI ամբողջությամբ կանգ է առել մեր խնդրանքով՝ ուղարկել մեր հանրային PGP բանալին (որպեսզի նրանց ուղարկենք գաղտնագրված անվտանգության խորհրդատվություն): Նրանք հայտարարեցին, որ իրենք «ապարատային արտադրող են և PGP բանալիներ չեն արտադրում»:
Բայց ավելին` կետին: Քանի որ ապահովիչները մնացել են չսահմանված վիճակում, օգտվողը (կամ հարձակվողը) կարող է ինքնուրույն ծրագրավորել դրանք (ամենադժվարը. ) Սա պահանջում է հետևյալ քայլերը.
1. Բեռնել Windows OS-ում (ընդհանուր առմամբ, ստորև նկարագրված քայլերը կարող են կատարվել նաև Linux-ի տակից, եթե դուք մշակում եք Intel STK-ի անալոգը ցանկալի ՕՀ-ի համար): Օգտագործելով MEinfo կոմունալ ծրագիրը, համոզվեք, որ այս համակարգի ապահովիչները ծրագրավորված չեն:
2. Կարդացեք ֆլեշ հիշողության բովանդակությունը Flash Programming Tool-ի միջոցով:
3. Բացեք ընթերցված պատկերը, օգտագործելով UEFI BIOS-ի խմբագրման ցանկացած գործիք, կատարեք անհրաժեշտ փոփոխությունները (իրականացրեք rootkit, օրինակ), ստեղծեք / խմբագրեք առկա KEYM և IBBM կառույցները ME տարածաշրջանում:
Նկարում ընդգծված է RSA ստեղնի հանրային մասը, որի հեշը ծրագրավորվելու է չիպսեթի ապահովիչներում՝ Intel BG-ի մնացած կոնֆիգուրացիայի հետ միասին:
4. Օգտագործելով Flash Image Tool-ը, ստեղծեք նոր որոնվածի պատկեր (տեղադրելով Intel BG-ի կոնֆիգուրացիան):
5. Գրեք նոր պատկեր՝ Flash Programming Tool-ի միջոցով թարթելու համար, MEinfo-ի միջոցով ստուգեք, որ ME տարածաշրջանն այժմ պարունակում է Intel BG կոնֆիգուրացիան:
6. Արտադրության ռեժիմը փակելու համար օգտագործեք Flash Programming Tool-ը:
7. Համակարգը կվերագործարկվի, որից հետո, օգտագործելով MEinfo, կարող եք ստուգել, որ FPF-ներն այժմ ծրագրավորված են:
Այս գործողությունները ընդմիշտ միացնել Intel BG-ն այս համակարգում: Գործողությունը հետարկելն անհնար կլինի, ինչը նշանակում է.
- միայն արմատային բանալու մասնավոր մասի սեփականատերը (այսինքն նա, ով միացրել է Intel BG-ն) կկարողանա թարմացնել UEFI BIOS-ն այս համակարգում.
- եթե դուք վերադարձնեք սկզբնական որոնվածը այս համակարգին, օրինակ՝ օգտագործելով ծրագրավորող, այն նույնիսկ չի միանա (հաստատման սխալի դեպքում կատարման քաղաքականության հետևանք);
- Նման UEFI BIOS-ից ազատվելու համար դուք պետք է չիպսեթը փոխարինեք ծրագրավորված FPF-ներով «մաքուր»ով (այսինքն՝ չիպսեթը վերամշակեք, եթե մեքենայի գնով մուտք ունեք ինֆրակարմիր զոդման կայան, կամ պարզապես փոխարինեք մայր տախտակը։ )
Հասկանալու համար, թե ինչ կարող է անել նման rootkit-ը, դուք պետք է գնահատեք, թե ինչն է թույլ տալիս ձեր կոդը գործարկել UEFI BIOS միջավայրում: Ասենք՝ պրոցեսորի ամենաարտոնյալ ռեժիմում՝ SMM: Նման rootkit-ը կարող է ունենալ հետևյալ հատկությունները.
- գործարկվի ՕՀ-ին զուգահեռ (կարող եք կարգավորել մշակումը` առաջացնելով SMI ընդհատում, որը կգործարկվի ժմչփի միջոցով);
- ունենալ SMM ռեժիմում գտնվելու բոլոր առավելությունները (լիարժեք մուտք RAM-ի և ապարատային ռեսուրսների բովանդակությանը, OS-ից գաղտնիություն);
- Rootkit կոդը կարող է գաղտնագրվել և վերծանվել SMM ռեժիմում գործարկվելիս: Ցանկացած տվյալ, որը հասանելի է միայն SMM ռեժիմում, կարող է օգտագործվել որպես գաղտնագրման բանալի: Օրինակ՝ SMRAM-ում հասցեների մի շարքից հեշ: Այս բանալին ստանալու համար դուք պետք է բարձրանաք SMM: Եվ դա կարելի է անել երկու եղանակով. Գտեք RCE-ն SMM կոդում և շահագործեք այն կամ ավելացրեք ձեր սեփական SMM մոդուլը BIOS-ում, ինչը անհնար է, քանի որ մենք միացրել ենք Boot Guard-ը:
Այսպիսով, այս խոցելիությունը հարձակվողին թույլ է տալիս.
- ստեղծել համակարգում անհայտ նշանակության թաքնված, չհեռացող rootkit.
- գործարկեք ձեր կոդը Intel SoC-ի ներսում գտնվող չիպսեթի միջուկներից մեկի վրա, մասնավորապես, Intel ISH-ի վրա (ավելի ուշադիր նայեք նկարին):
Չնայած Intel ISH ենթահամակարգի հնարավորությունները դեռ ուսումնասիրված չեն, թվում է, որ այն հետաքրքիր հարձակման վեկտոր է Intel ME-ի դեմ:
Արդյունքները
- Ուսումնասիրությունը տրամադրել է տեխնիկական նկարագրություն, թե ինչպես է աշխատում Intel Boot Guard տեխնոլոգիան: Մի քանի գաղտնիք Intel-ի անվտանգության մեջ՝ անհայտության մոդելի միջոցով:
- Ներկայացված է հարձակման սցենար, որը թույլ է տալիս համակարգում ստեղծել չհանվող rootkit:
- Մենք տեսանք, որ ժամանակակից Intel պրոցեսորներն ի վիճակի են գործարկել բազմաթիվ սեփականության կոդ նույնիսկ մինչև BIOS-ի գործարկումը:
- Intel 64 ճարտարապետությամբ պլատֆորմները գնալով ավելի քիչ հարմար են դառնում ազատ ծրագրային ապահովման գործարկման համար. ապարատային ստուգում, սեփականության տեխնոլոգիաների և ենթահամակարգերի աճող թվաքանակ (SoC չիպսեթում երեք միջուկ՝ x86 ME, x86 ISH և ARC PMC):
Մեղմացումներ
Վաճառողները, որոնք միտումնավոր բաց են թողնում արտադրության ռեժիմը, անպայման պետք է փակեն այն: Առայժմ նրանք միայն փակում են իրենց աչքերը, և դա ցույց են տալիս նոր Kaby Lake համակարգերը:
Օգտագործողները կարող են անջատել Intel BG-ն իրենց համակարգերում (որոնց վրա ազդում է նկարագրված խոցելիությունը)՝ գործարկելով Flash Programming Tool-ը -closemnf տարբերակով: Նախ, դուք պետք է համոզվեք (օգտագործելով MEinfo), որ Intel BG-ի կոնֆիգուրացիան ME տարածաշրջանում նախատեսում է ճշգրիտ անջատել այս տեխնոլոգիան FPF-ներում ծրագրավորումից հետո:
Source: www.habr.com