Matthew Garrett, zn\u00e1my v\u00fdvoj\u00e1r jadra Linux, ktor\u00fd v minulosti z\u00edskal od Nad\u00e1cie otvoren\u00e9ho zdroja ocenenie za pr\u00ednos k rozvoju slobodn\u00e9ho softv\u00e9ru, hovoril o podstate mechanizmu SBAT (Secure Boot Advanced Targeting), vytvoren\u00e9ho na blokovanie zranite\u013enost\u00ed v bootloaderi bez odvolania digit\u00e1lneho podpisu, ako aj o jeho \u00falohe v ned\u00e1vnom incidente s aktualiz\u00e1ciou pre Windows, ktor\u00e1 viedla k ukon\u010deniu bootovania niektor\u00fdch distrib\u00faci\u00ed Linuxu nain\u0161talovan\u00fdch ved\u013ea Windows na syst\u00e9moch s aktivovan\u00fdm UEFI Secure Boot. Stru\u010dne povedan\u00e9, za to m\u00f4\u017eu ako spolo\u010dnos\u0165 Microsoft, ktor\u00e1 aktualiz\u00e1ciu plne netestovala a aplikovala ju na syst\u00e9my, kde nemala by\u0165 aplikovan\u00e1, tak aj v\u00fdvoj\u00e1ri niektor\u00fdch distrib\u00faci\u00ed Linuxu, ktor\u00ed neaktualizovali bootloader GRUB a \u010d\u00edslo gener\u00e1cie SBAT, ke\u010f v GRUB boli objaven\u00e9 zranite\u013enosti. <\/p>\n
N\u00e1sledne je preklad pozn\u00e1mky Garretta: <\/p>\n
\nKe\u010f sa vyv\u00edjala \u0161pecifik\u00e1cia UEFI Secure Boot, v\u0161etci jej \u00fa\u010dastn\u00edci boli, povedzme, trochu naivn\u00ed. Z\u00e1kladn\u00fd model bezpe\u010dnosti Secure Boot spo\u010d\u00edva v tom, \u017ee cel\u00fd k\u00f3d, ktor\u00fd sa sp\u00fa\u0161\u0165a v privilegovanej prostred\u00ed na \u00farovni jadra, mus\u00ed by\u0165 pred vykonan\u00edm overen\u00fd \u2014 firmware over\u00ed bootloader, bootloader over\u00ed jadro, jadro over\u00ed ak\u00fdko\u013evek \u010fal\u0161\u00ed k\u00f3d na\u010d\u00edtan\u00fd po\u010das behu, a teraz m\u00e1me d\u00f4veryhodn\u00e9 prostredie na uplat\u0148ovanie ak\u00fdchko\u013evek in\u00fdch bezpe\u010dnostn\u00fdch polit\u00edk, ktor\u00e9 chceme. Je zrejm\u00e9, \u017ee \u013eudia sa m\u00f4\u017eu pom\u00fdli\u0165, ale v \u0161pecifik\u00e1cii bol predpokladan\u00fd sp\u00f4sob odvolania podp\u00edsan\u00fdch komponentov, ktor\u00e9 sa uk\u00e1zali ako ned\u00f4veryhodn\u00e9: jednoducho pridajte hash ned\u00f4veryhodn\u00e9ho k\u00f3du do premennej a potom sa zrieknite na\u010d\u00edtania nie\u010doho s t\u00fdmto hashom, aj ke\u010f je to podp\u00edsan\u00e9 d\u00f4veryhodn\u00fdm k\u013e\u00fa\u010dom. <\/p>\n
Bohu\u017eia\u013e, ako sa uk\u00e1zalo, probl\u00e9m je v rozsahu. Ka\u017ed\u00e1 distrib\u00facia Linuxu, ktor\u00e1 funguje v ekosyst\u00e9me Secure Boot, generuje vlastn\u00e9 bin\u00e1rne s\u00fabory bootloadera, a ka\u017ed\u00fd z nich m\u00e1 svoj vlastn\u00fd hash. Ak sa v zdrojovom k\u00f3de tak\u00e9ho bootloadera n\u00e1jde zranite\u013enos\u0165, je potrebn\u00e9 odvola\u0165 ve\u013ek\u00e9 mno\u017estvo r\u00f4znych bin\u00e1rnych s\u00faborov. A objem pam\u00e4te na uchovanie premennej, ktor\u00e1 obsahuje v\u0161etky tieto hashe, je obmedzen\u00fd. Prosto nebude dostatok miesta na prid\u00e1vanie nov\u00e9ho s\u00faboru hashov zaka\u017ed\u00fdm, ke\u010f sa zist\u00ed, \u017ee GRUB (bootloader, ktor\u00fd bol p\u00f4vodne nap\u00edsan\u00fd v dob\u00e1ch, ke\u010f sa e\u0161te nepraktizovala ochrana bootu a m\u00e1 nieko\u013eko oddelen\u00fdch parserov img-obrazov, ako aj parser p\u00edsma) m\u00e1 \u010fal\u0161\u00ed mechanizmus pre \u00fato\u010dn\u00edka, aby ho prin\u00fatil vykona\u0165 \u013eubovo\u013en\u00fd k\u00f3d, preto bolo potrebn\u00e9 in\u00e9 rie\u0161enie. <\/p>\n
T\u00fdmto rie\u0161en\u00edm bol SBAT. Celkov\u00e1 koncepcia SBAT je dos\u0165 jednoduch\u00e1. Ka\u017ed\u00e1 d\u00f4le\u017eit\u00e1 s\u00fa\u010das\u0165 v re\u0165azci spustenia vyhlasuje bezpe\u010dnostn\u00fa gener\u00e1ciu, ktor\u00e1 je zahrnut\u00e1 v podp\u00edsanom bin\u00e1rnom s\u00fabore. Ke\u010f je zranite\u013enos\u0165 zisten\u00e1 a odstr\u00e1nen\u00e1, t\u00e1to gener\u00e1cia sa zv\u00fd\u0161i. Potom je mo\u017en\u00e9 vyda\u0165 aktualiz\u00e1ciu, ktor\u00e1 ur\u010duje minim\u00e1lnu gener\u00e1ciu \u2014 \u0161tartovacie komponenty sa bud\u00fa pozera\u0165 na nasleduj\u00facu polo\u017eku v re\u0165azci, porovn\u00e1va\u0165 jej n\u00e1zov a \u010d\u00edslo gener\u00e1cie s t\u00fdmi, ktor\u00e9 s\u00fa ulo\u017een\u00e9 v premennej firmware, a rozhodova\u0165, \u010di ju vykona\u0165 alebo nie, vych\u00e1dzaj\u00fac z toho. Namiesto odvolania ve\u013ek\u00e9ho po\u010dtu jednotliv\u00fdch hashov je mo\u017en\u00e9 vyda\u0165 jednu aktualiz\u00e1ciu, ktor\u00e1 jednoducho hovor\u00ed: \u201eAk\u00e1ko\u013evek verzia GRUB s bezpe\u010dnostnou gener\u00e1ciou pod t\u00fdmto \u010d\u00edslom sa pova\u017euje za ned\u00f4veryhodn\u00fa.\u201c <\/p>\n
Pre\u010do sa to vlastne stalo aktu\u00e1lnym? SBAT bol vyvinut\u00fd spolo\u010dne komunitou Linuxu a Microsoftom, pri\u010dom Microsoft sa rozhodol vyda\u0165 aktualiz\u00e1ciu pre Windows, ktor\u00e1 hovorila syst\u00e9mom, aby ned\u00f4verovali verzi\u00e1m GRUB s bezpe\u010dnostnou gener\u00e1ciou ni\u017e\u0161ou ako ur\u010dit\u00e1 \u00farove\u0148. Urobilo sa to preto, \u017ee tieto verzie GRUB mali skuto\u010dn\u00e9 bezpe\u010dnostn\u00e9 zranite\u013enosti, ktor\u00e9 umo\u017e\u0148ovali \u00fato\u010dn\u00edkom naru\u0161i\u0165 re\u0165azec bezpe\u010dn\u00e9ho bootovania Windows, a videli sme skuto\u010dn\u00e9 pr\u00edklady malv\u00e9ru, ktor\u00fd sa sna\u017eil to urobi\u0165 (Black Lotus vyu\u017eil zranite\u013enos\u0165 v bootloaderi Windows, ale zranite\u013enos\u0165 v GRUB bola rovnako \u00fa\u010dinn\u00e1). Ak sa na to pozrieme \u010disto z poh\u013eadu bezpe\u010dnosti, je to \u00faplne legit\u00edmna po\u017eiadavka. <\/p>\n
Teraz k spr\u00e1ve \u201eNie\u010do sa pokazilo\u201c a nemo\u017enosti spustenia v d\u00f4sledku tejto aktualiz\u00e1cie. Vypisuje ju shim a nie k\u00f3d od Microsoftu. Shim berie do \u00favahy aktualiz\u00e1cie SBAT, a aby nedo\u0161lo k poru\u0161eniu bezpe\u010dnostn\u00fdch princ\u00edpov, ktor\u00e9 prijali in\u00e9 bootloadery v syst\u00e9me, a hoci Microsoft vydal aktualiz\u00e1ciu SBAT, pr\u00e1ve bootloader Linuxu n\u00e1sledne odmieta spusti\u0165 star\u0161ie verzie GRUB. V\u0161etko funguje tak, ako m\u00e1. <\/p>\n
Probl\u00e9m, s ktor\u00fdm sa \u013eudia stretli, spo\u010d\u00edva v tom, \u017ee nieko\u013eko distrib\u00faci\u00ed Linuxu nevydalo verzie GRUB s nov\u0161ou gener\u00e1ciou zabezpe\u010denia, a preto s\u00fa tieto verzie GRUB pova\u017eovan\u00e9 za nebezpe\u010dn\u00e9 (je potrebn\u00e9 poznamena\u0165, \u017ee GRUB je podp\u00edsan\u00fd samotn\u00fdmi distrib\u00faciami, a nie Microsoftom, tak\u017ee tu nie je \u017eiadne vonkaj\u0161ie zdr\u017eanie). Pod\u013ea Microsoftu mala aktualiz\u00e1cia Windows Update aplikova\u0165 aktualiz\u00e1ciu SBAT iba na syst\u00e9my, ktor\u00e9 funguj\u00fa iba s Windowsom, a ak\u00e9ko\u013evek in\u0161tal\u00e1cie s dvojit\u00fdm zaveden\u00edm by zostali zranite\u013en\u00e9 vo\u010di \u00fatokom, pokia\u013e nain\u0161talovan\u00e1 distrib\u00facia neaktualizuje GRUB a nezmen\u00ed gener\u00e1ciu SBAT. Bohu\u017eia\u013e, ako je teraz zrejm\u00e9, toto nefungovalo tak, ako sa zam\u00fd\u0161\u013ealo, a aspo\u0148 niektor\u00e9 syst\u00e9my s dvojit\u00fdm zaveden\u00edm pou\u017eili aktualiz\u00e1ciu, ale Shim tejto distrib\u00facie odmietol na\u010d\u00edta\u0165 GRUB tejto distrib\u00facie. <\/p>\n
Ak\u00fd je z\u00e1ver? Microsoft (z d\u00f4vodov, ktor\u00e9 s\u00fa jasn\u00e9) nechcel, aby bolo mo\u017en\u00e9 napadn\u00fa\u0165 Windows prostredn\u00edctvom zranite\u013enej verzie GRUB, ktor\u00fa by bolo mo\u017en\u00e9 podvodne prin\u00fati\u0165 vykona\u0165 \u013eubovo\u013en\u00fd k\u00f3d, a n\u00e1sledne implantova\u0165 bootkit do jadra Windows po\u010das jeho sp\u00fa\u0161\u0165ania. Microsoft to vyrie\u0161il vydan\u00edm aktualiz\u00e1cie Windows, ktor\u00e1 aktualizovala premenn\u00fa SBAT, uv\u00e1dzaj\u00fac, \u017ee zranite\u013en\u00e9 verzie GRUB sa nemaj\u00fa sp\u00fa\u0161\u0165a\u0165 na t\u00fdchto syst\u00e9moch. Poskytovan\u00fd distribu\u010dn\u00fd Shim bootloader prv\u00e9ho \u0161t\u00e1dia t\u00fato premenn\u00fa na\u010d\u00edtal, pre\u010d\u00edtal oddiel SBAT z nain\u0161talovanej k\u00f3pie GRUB, zistil, \u017ee s\u00fa v konflikte, a odmietol na\u0161tartova\u0165 grub so spr\u00e1vou \u201eNie\u010do \u00faplne zlyhalo\u201c. T\u00e1to aktualiz\u00e1cia nemala by\u0165 aplikovan\u00e1 na syst\u00e9my s dvojit\u00fdm sp\u00fa\u0161\u0165an\u00edm, ale aj tak bola aplikovan\u00e1. <\/p>\n
Celkovo: <\/p>\n
1) Microsoft pou\u017eil aktualiz\u00e1ciu na syst\u00e9my, na ktor\u00e9 sa nemala aplikova\u0165 <\/p>\n
2) Niektor\u00e9 distrib\u00facie Linuxu neaktualizovali bootloader GRUB a gener\u00e1ciu zabezpe\u010denia SBAT, ke\u010f boli v GRUB zisten\u00e9 zranite\u013enosti. <\/p>\n
V d\u00f4sledku toho niektor\u00ed \u013eudia nem\u00f4\u017eu na\u010d\u00edta\u0165 svoje syst\u00e9my. Mysl\u00edm si, \u017ee tu je mnoho vinn\u00edkov. Microsoft by mal vykona\u0165 viac testov, aby sa uistil, \u017ee in\u0161tal\u00e1cie s dual boot m\u00f4\u017eu by\u0165 presne identifikovan\u00e9. Distrib\u00facie, ktor\u00e9 dod\u00e1vaj\u00fa podp\u00edsan\u00e9 bootovacie s\u00fabory, by sa mali tie\u017e uisti\u0165, \u017ee ich aktualizuj\u00fa a obohacuj\u00fa o bezpe\u010dnostn\u00e9 opravy, aby zodpovedali, preto\u017ee inak poskytuj\u00fa vektor \u00fatoku, ktor\u00fd m\u00f4\u017ee by\u0165 pou\u017eit\u00fd na napadnutie in\u00fdch opera\u010dn\u00fdch syst\u00e9mov, a to je ak\u00e9si poru\u0161enie verejnej dohody okolo toho v\u0161etk\u00e9ho. <\/p>\n
\u017dia\u013e, obe\u0165ami s\u00fa tu predov\u0161etk\u00fdm koncov\u00ed pou\u017e\u00edvatelia, ktor\u00ed sa stret\u00e1vaj\u00fa s t\u00fdm, \u017ee syst\u00e9m n\u00e1hle odmieta na\u010d\u00edta\u0165 ten opera\u010dn\u00fd syst\u00e9m, ktor\u00fd chc\u00fa na\u010d\u00edta\u0165. K tomu by nikdy nemalo d\u00f4js\u0165. Nemysl\u00edm si, \u017ee prieskum koncov\u00fdch pou\u017e\u00edvate\u013eov oh\u013eadom toho, \u010di chc\u00fa aktualiz\u00e1cie zabezpe\u010denej sp\u00fa\u0161\u0165ania, prinesie dobr\u00fd v\u00fdsledok, a hoci sa jemne prikl\u00e1\u0148am k n\u00e1zoru, \u017ee zabezpe\u010den\u00e9 sp\u00fa\u0161\u0165anie UEFI nie je nie\u010do, \u010do prin\u00e1\u0161a prospech v\u00e4\u010d\u0161ine koncov\u00fdch pou\u017e\u00edvate\u013eov, je to i tak nie\u010do, \u010do by ste nechceli objavi\u0165 po tak\u00fdchto incidentoch, tak\u017ee s\u00facitim s t\u00fdm, \u017ee je to zapnut\u00e9 predvolene, a preto podporujem jeho predvolen\u00e9 zapnutie a del\u00edm sa o vo\u013ebu Microsoftu, okrem ne\u00faspe\u0161n\u00e9ho pokusu vyhn\u00fa\u0165 sa aktualiz\u00e1ci\u00e1m na syst\u00e9moch s dual boot. <\/p>\n
V ka\u017edom pr\u00edpade som bol silne zapojen\u00fd do implement\u00e1cie tohto mechanizmu pre Linux v roku 2012 a nap\u00edsal som prv\u00fd prototyp Shim (ktor\u00fd je teraz v\u00fdrazne lep\u0161\u00ed bootloader, podporovan\u00fd \u0161ir\u0161\u00edm okruhom \u013eud\u00ed, a ktor\u00e9ho som sa nedotkol u\u017e nieko\u013eko rokov), tak\u017ee ak chcete obvini\u0165 niekoho konkr\u00e9tneho, pokojne ma obvi\u0148te. To je nie\u010do, \u010do sa nemalo sta\u0165, a ak nie ste Microsoft alebo distrib\u00facia Linux, nie je to va\u0161a vina. Ospravedl\u0148ujem sa. <\/p><\/blockquote>\n