Нищо странно, нулеви драми ... Но е открита друга уязвимост, CVE-2020-10713, която засяга загрузчика GRUB2 и Secure Boot. Публикация на изследователския екип на Eclypsium е това, което стои зад тази констатация и е наречено BootHole. Дори Microsoft публикува запис на своя портал за сигурност, като го предупреждава и твърди, че в момента има сложно решение.
BootHole Това е уязвимост при препълване на буфер, която засяга милиарди устройства с GRUB2 и дори други без GRUB2, които използват Secure Boot като Windows. В класификацията на системата CVSS тя е оценена като 8.2 от 10, което означава, че е с висок риск. И това е, че нападателят може да се възползва от това, за да може да изпълнява произволен код (включително злонамерен софтуер), въведен по време на процеса на зареждане, дори и с активирано защитено стартиране.
така dispositivos ще бъдат засегнати мрежи, сървъри, работни станции, настолни компютри и лаптопи, както и други устройства като SBC, определени мобилни устройства, IoT устройства и др.
Освен това, според Eclypsium, ще бъде сложно за смекчаване и ще отнеме време, за да се намери решение. Това ще изисква задълбочен преглед на буутлоудърите и доставчиците трябва да пуснат нови версии на буутлоудъри, подписани от UEFI CA. Ще бъдат необходими координирани усилия между разработчиците в отворения код на Microsoft и съвместната общност и други засегнати собственици на системата, за да свалят BootHole.
Всъщност те са направили a списък със задачи за да можете да поправите BootHole в GRUB2 и имате нужда от:
- Пач за актуализиране на GRUB2 и премахване на уязвимостта.
- Разработчиците на дистрибуции на Linux и други доставчици да пуснат актуализациите за своите потребители. Както на ниво GRUB2, инсталатори, така и подложки.
- Новите подложки трябва да бъдат подписани от Microsoft UEFI CA за трети страни.
- Администраторите на операционни системи очевидно ще трябва да актуализират. Но той трябва да включва както инсталираната система, изображенията на инсталатора, така и създадените от тях носители за възстановяване или зареждане.
- Списъкът за отмяна на UEFI (dbx) също ще трябва да бъде актуализиран във фърмуера на всяка засегната система, за да се предотврати изпълнението на кода по време на зареждане.
Най-лошото е, че що се отнася до фърмуера, трябва да внимавате и да внимавате да не се окажете с проблеми и компютрите да останат в тухлен режим.
В момента компании като Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team и OEM производители, както и доставчици на софтуер, те вече работят за решаването му. Ще трябва обаче да изчакаме, за да видим първите кръпки.
UPDATE
Но подценяването на ефективността на разработчиците и общността би било глупаво. Вече има няколко кандидати за кръпка за смекчаване, които идват от компании като Red Hat, Canonical и др. Те отбелязаха този проблем като основен приоритет и той се отплаща.
Проблемът? Проблемът е, че тези кръпки създават допълнителни проблеми. Това ми напомня за случилото се с лепенките Metldown и Spectre, че понякога лекарството е по-лошо от болестта ...