наскоро споделяме тук в блога новината за проблем, причинен от актуализация на Microsoft при двойно зареждане с Linux дистрибуции, които използват GRUB. По отношение на инцидента, споменахме в статията, че „целта“ на тази актуализация е да се справи с уязвимостта на GRUB отпреди две години, „CVE-2022-2601“, която позволява на атакуващите да заобиколят защитените защити при зареждане, но това далеч не е полза, в крайна сметка навреди на много потребители.
Дни след събитието, Матю Гарет, известен разработчик на Linux ядро, Публикувам бележка в който той обясни действието на механизма SBAT. в него, споменава, че SBAT е проектиран да блокира уязвимости в буутлоудъра, без да е необходимо да отменяте цифрови подписи, и беше централният елемент в неотдавнашния инцидент причинени от актуализация на Windows, която засегна някои Linux дистрибуции на системи с UEFI сигурно зареждане, предотвратявайки тяхното зареждане.
Според Гарет, Microsoft и някои Linux разработчици споделят отговорността на проблема: Microsoft за това, че не е тествал адекватно актуализацията във всички сценарии и lРазработчици на Linux за това, че не са актуализирали номера на поколение GRUB и SBAT когато бяха открити уязвимости в GRUB.
Гарет също така споменава, че когато е създадена спецификацията на UEFI Secure Boot, всички участващи до известна степен са подценили нейната сложност, т.к.
Основният защитен модел на Secure Boot гласи, че целият код, изпълняван в привилегирована среда на ниво ядро, трябва да бъде проверен преди изпълнение: фърмуерът проверява зареждащото устройство за зареждане, зареждащото устройство за зареждане проверява ядрото, а ядрото проверява всеки допълнителен код, зареден по време на изпълнение. По този начин се създава сигурна среда за прилагане на допълнителни политики за сигурност.
В допълнение, той уточнява, че въпреки че има възможност за „правене на грешки“ като такава, спецификацията включва механизъм за отмяна на ненадеждни подписани компоненти: хешът на проблемния код просто се добавя към променлива и зареждането на всеки код с този хеш, дори ако е подписан с доверен ключ.
До този момент всичко звучи добре, но Гарет споменава, че проблемът е в мащаба и главно във фрагментацията на екосистемата Secure Boot, тъй като всяка дистрибуция генерира свои собствени файлове двоични файлове за буутлоудъра, всеки със собствен хеш.
Ето защо обяснява това когато се открие уязвимост в изходния код на буутлоудъра, голям брой файлове трябва да бъдат отменени различни двоични файлове. Освен това наличната памет за съхраняване на променлива, съдържаща всички тези хешове, е ограничена, и няма достатъчно място за добавяне на нов набор от хешове всеки път, когато се открие уязвимост в GRUB и затова беше необходимо различно решение.
Това решение беше SBAT.
Концепцията на SBAT е сравнително проста: всеки критичен компонент в рамките на веригата за зареждане декларира номер за генериране на защита, който е включен в двоичния файл със знак. Когато уязвимостта бъде идентифицирана и коригирана, този брой на поколение се увеличава. Оттам е възможно да се издаде актуализация, която установява минималното приемливо поколение. Компонентите за зареждане ще проверят този номер, за да определят дали могат да изпълнят следващия елемент във веригата за зареждане, сравнявайки името и номера на компилация със стойностите, съхранени в променливата на фърмуера.
Вместо да се налага да отмените многобройни индивидуални хешове, една актуализация може да каже: „Всяка версия на GRUB с ниво на сигурност, по-ниско от това число, се счита за ненадеждна.“
Linux, истинската отговорност
Гарет споменава, че грешката което не позволява на някои системи да се зареждат след актуализацията, не идва от кода на Microsoft, а от компонента shim на зареждащия механизъм за зареждане на Linux.
Въпреки че Microsoft пусна актуализацията на SBAT, буутлоудърът на Linux е този, който отказва да стартира по-стари версии на GRUB, което прави всичко да работи както се очаква от техническа гледна точка.
Ето защо истинският проблем се крие във факта, че няколко Linux дистрибуциите не са пуснали актуализирани версии на GRUB които включват корекции за сигурност и нови поколения SBAT. Това кара тези версии на GRUB да се считат за опасни, тъй като shim блокира тяхното изпълнение.
Важно е да се отбележи, че GRUB е подписан от самите Linux дистрибуции, а не от Microsoft, което елиминира всякакви външни забавяния при актуализиране.
Предвид обяснението на Гарет, споменава, че Microsoft пусна своята актуализация така че да се прилага само в Windows (както трябва да бъде) и проблемът беше от страна на дистрибуциите, които все още управляваха уязвими версии и генериране на проблема с двойно зареждане
Накрая той споменава, че в този инцидент, За съжаление, основните жертви на тази ситуация са крайните потребители, които внезапно установяват, че не могат да заредят операционната система, която искат.
Това е нещо, което никога не трябва да се случва. Въпреки че разбирам необходимостта UEFI Secure Boot да бъде активиран по подразбиране и като цяло подкрепям решението на Microsoft, ясно е, че опитът да се предотврати актуализацията на системи с двойно зареждане не проработи според очакванията.
Ако сте заинтересовани да научите повече за това, каня ви да се запознаете с оригиналната бележка от Матю Гарет В следващия линк.