Мети Гарарет, известен разработчик на ядрото на 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
