Матию Гарет (Matthew Garrett), известен разработчик на ядрото на Linux, който в миналото получи награда от Фонда за софтуер с отворен код за принос към развитието на свободния софтуер, разказа за същността на механизма SBAT (Secure Boot Advanced Targeting), създаден за блокиране на уязвимости в зареждащия сектор без отзоваване на цифровия сертификат, а също и за неговата роля в скорошния инцидент с обновление за Windows, който доведе до прекратяване на зареждането на някои дистрибуции на Linux, инсталирани паралелно с Windows на системи с включен UEFI Secure Boot. Накратко, отговорни са както компанията Microsoft, която не е тествала напълно обновлението и го е приложила към системи, към които не би трябвало да се прилага, така и разработчиците на някои дистрибуции на Linux, които не са обновили зареждача GRUB и номера на поколенията SBAT, когато в GRUB бяха открити уязвимости.
По-долу е преводът на бележката на Гарет:
Когато се разработваше спецификацията на UEFI Secure Boot, всички участници в нея бяха, да кажем, малко наивни. Основната модел на сигурност на Secure Boot е, че всеки код, който стартира в привилегированата среда на ниво ядро, трябва да бъде проверен преди изпълнението — фърмуерът проверява зареждача, зареждача проверява ядрото, ядрото проверява всеки допълнителен зареден код по време на изпълнението, и сега имаме доверена среда за налагане на всяка друга политика на сигурност, която желаем. Очевидно е, че хората могат да сбъркат, но в спецификацията беше предвиден начин за отзоваване на подписани компоненти, които се оказаха ненадеждни: просто добавете хеш на недостоверния код в променлива и след това откажете да зареждате каквото и да е с този хеш, дори ако е подписан с доверен ключ.
За съжаление, както се оказа, проблемът е в мащаба. Всеки дистрибутив на Linux, работещ в екосистемата Secure Boot, генерира свои собствени бинарни файлове на зареждача, и всеки от тях има свой хаш. Ако в изходния код на такъв зареждач бъде открита уязвимост, е необходимо да се отзоват голям брой различни бинарни файлове. А обемът памет за съхранение на променлива, съдържаща всички тези хашове, е ограничен. Просто няма достатъчно място, за да се добавя нов набор хашове всеки път, когато се установи, че GRUB (започващият зареждач, написан в епохата, когато защита на зареждането не се практикуваше, и имащ няколко отделни парсера на img-образи, както и парсер на шрифтове) има още един механизъм, който позволява на атакуващия да накара зареждача да изпълни произволен код, затова е необходимо друго решение.
Това решение стана SBAT. Общата концепция на SBAT е доста проста. Всеки важен компонент в процеса на зареждане обявява безопасно поколение, което се включва в подписания бинарен файл. Когато бъде открита и отстранена уязвимост, това поколение се увеличава. След това може да бъде издадено обновление, определящо минималното поколение — компонентите на зареждането ще гледат на следващия елемент в веригата, ще сравняват името и номера на поколенията с тези, съхранявани в променливата на фърмуера, и ще решават дали да го изпълнят или не. Вместо да се отзовават голям брой отделни хашове, може да бъде издадено едно обновление, което просто казва: „Всяка версия на GRUB с безопасно поколение под този номер се счита за ненадеждна.“
Защо това стана актуално? SBAT беше разработен съвместно от общността на Linux и Microsoft, и Microsoft реши да издаде обновление за Windows, което инструктира системите да не се доверяват на версиите на GRUB с безопасно поколение под определено ниво. Това беше направено, защото тези версии на GRUB имаха реални уязвимости в сигурността, които позволиха на злонамерени лица да нарушат веригата на безопасно зареждане на Windows, и видяхме реални примери на злонамерен софтуер, който искаше да го направи (Black Lotus използва уязвимост в Windows зареждача, но уязвимостта в GRUB беше толкова ефективна). Ако погледнем на това чисто от гледна точка на сигурността, това е напълно легитимно желание.
Сега, що се отнася до съобщението «Нещо съвсем се обърка» и невъзможността за зареждане в резултат на това обновление. Това е резултат на shim, а не на някакъв код на Microsoft. Shim отчита обновленията SBAT и, за да не нарушава принципите на сигурността, приети от другите зареждачи в системата, и, въпреки че Microsoft е издала обновление SBAT, именно зареждачът на Linux отказва да стартира старите версии на GRUB. Всичко работи така, както трябва.
Проблемът, с който хората се сблъскват, е, че няколко дистрибуции на Linux не са издали версии на GRUB с по-ново поколение сигурност и следователно тези версии на GRUB са считани за небезопасни (забележете, че GRUB се подписва от самите дистрибуции, а не от Microsoft, така че тук няма приносят извънредно забавяне). Според Microsoft, обновлението на Windows Update трябваше да прилага обновлението SBAT само към системите, работещи единствено с Windows, а всякакви инсталации с двойно зареждане ще остават уязвими за атаки, докато инсталираният дистрибутив не обнови GRUB и не актуализира поколението SBAT. За съжаление, както сега е очевидно, това не сработи така, както беше замислено, и поне някои системи с двойно зареждане приложиха обновлението, а Shim на този дистрибутив отказа да зареди GRUB на този дистрибутив.
Какво е заключението? Microsoft (по разбираеми причини) не искаше да бъде атакувана Windows с уязвима версия на GRUB, която да бъде измамно накарана да изпълни произволен код и след това да внедри буткит в ядрото на Windows по време на зареждане. Microsoft направи това, като издаде обновление на Windows, което обнови променливата SBAT, посочвайки, че уязвимите версии на GRUB не трябва да се зареждат на тези системи. Зареждачът на първия етап, предоставен от дистрибутива Shim, прочете тази променлива, прочете раздела SBAT от инсталираната копия на GRUB, разбра, че те конфликтират, и отказа да зареди grub с съобщение „Нещо съвсем се обърка“. Това обновление не трябваше да се прилага към системи с двойно зареждане, но все пак беше приложено.
В общи линии:
1) Microsoft приложи обновление към системи, към които не трябваше да се прилага
2) Някои дистрибуции на Linux не обновиха зареждача GRUB и поколението сигурност SBAT, когато в GRUB бяха открити уязвимости.
В резултат на това някои хора не могат да заредят своите системи. Смятам, че тук има много виновни. Microsoft трябваше да проведе повече тестове, за да се увери, че инсталациите с двойно зареждане могат да бъдат точно идентифицирани. Но и дистрибутивите, които предоставят подписани зареждачи, трябва да се уверят, че ги актуализират и обновяват поколенията за сигурност, за да съответстват, защото в противен случай те предоставят вектор на атака, който може да бъде използван за пробив на други операционни системи, и това е вид нарушение на обществения договор около всичко това.
За съжаление, жертвите тук са главно крайни потребители, които се сблъскват с това, че системата внезапно отказва да зареди онези ОС, които искат да заредят. Това никога не трябва да се случва. Не мисля, че анкета сред крайните потребители относно това дали искат актуализации на системата за безопасно зареждане ще доведе до добър резултат, и докато леко се倾向я да мисля, че безопасното зареждане UEFI не е нещо, което носи полза за повечето крайни потребители, това също е нещо, което не искате да откриете след подобни инциденти, затова съчувствам, че то е включено по подразбиране, така че подкрепям неговото включване по подразбиране и споделям избора на Microsoft, с изключение на неудачната опит да избегнат актуализация на системите с двойно зареждане.
Както и да е, бях силно ангажиран с реализирането на този механизъм за Linux през 2012 година и написах първия прототип Shim (който сега е значително по-добър зареждач, подкрепян от по-широк кръг хора и до който не съм се докосвал от няколко години), така че ако искате да обвините някого, моля, не се колебайте да ме обвините. Това е нещо, което не трябваше да се случва, и ако не сте Microsoft или дистрибутив на Linux, то това не е ваша вина. Извинявайте.
Източник: opennet.ru
