Secure Boot хамгаалалтын системийг тойрч, хортой код суулгах боломжтой UEFI сул талуудыг илрүүлсэнтэй холбогдуулан Microsoft эрхүүдийг цуцаллаа.
Сүүлийн арван жилийн турш ашиглагдаж ирсэн UEFI “shim” буюу ачаалах хэрэгслүүдэд ноцтой цоорхой байгааг ESET-ийн судлаачид хоёрдугаар сард илрүүлжээ. Эдгээр сул тал нь хакеруудад эх хавтангийн түвшний хамгаалалтыг тойрон гарч, үйлдлийн систем ачаалах явцад хортой код гүйцэтгэх боломжийг олгодог байсан байна. Энэхүү аюул нь зөвхөн Windows төдийгүй Linux хэрэглэгчдэд нөлөөлж байсан бөгөөд суулгасан хортой програм хангамж нь хатуу дискийг солих эсвэл үйлдлийн системийг дахин суулгасан ч устдаггүй байсан нь нөхцөл байдлыг улам хүндрүүлж байв.
UEFI нь компьютер асах үед техник хангамжийг бэлтгэж, удирдлагыг үйлдлийн системд шилжүүлдэг програм хангамж юм. Secure Boot нь зөвхөн криптограф гарын үсэгтэй, найдвартай програмуудыг ачаалах замаар системийн аюулгүй байдлыг хангадаг. Гэвч гуравдагч талын “shim” хэрэгслүүд нь Microsoft-ын 2011 оны гэрчилгээг ашиглан энэхүү хамгаалалтад нэвтэрдэг байсан нь халдлага үйлдэх гол цэг болжээ.
Microsoft зургаадугаар сарын нөхөөсөөр дамжуулан эдгээр аюултай “shim”-ийн ашиглах эрхийг албан ёсоор цуцалсан байна. ESET-ийн онцолсноор, эдгээр сул талуудын зарим нь бүр арван жилийн өмнөөс баримтжуулагдсан байсан ч Microsoft үүнийг олон жилийн турш анзааралгүй орхигдуулсан нь том алдаа болсон гэж үзэж байна.
Дэлгэрэнгүйг эх сурвалжаас харах
↓Эх сурвалжийг нээх ↓
Software development, much like making a stew that’s a perfect umami bomb in every bite, is a tricky business. Every major commercial product is touched by many hands, and sometimes the chefs leave cardamom and bay leaves in the mix. Okay, perhaps I’ve overstretched the metaphor—what you need to know is that apparently Microsoft’s Secure Boot was basically busted for the last decade.
Rather than leftover bones in the broth, old system images could be exploited to bypass a system’s motherboard-level protection to execute dubious code during system boot. It’s bad enough that this effectively makes Secure Boot redundant, but worse still, any malicious firmware installed this way could then survive swapping out the hard drive or persist past reinstalling your operating system.
The affected images were UEFI shim bootloaders, which were first introduced to extend Secure Boot support to Linux devices (though they can also be installed on Windows devices). ESET researchers identified and reported 11 of these vulnerable shims back in February. Microsoft has revoked the permission it once granted to the affected shims, so that bad actors can’t continue to leverage them as a bypass (via Ars Technica).
At the risk of oversimplifying, ‘Unified Extensible Firmware Interface (UEFI)’ is a firmware architecture spec that initialises hardware and then allows it to transfer control to your OS during startup. As a safety precaution designed to root out boot kits, Secure Boot requires a cryptographically signed certificate from UEFI apps before they can run.
Shims, then, are little bridges of code that allow a motherboard’s UEFI firmware to communicate with operating systems like Linux. Shims allow Linux to boot with Secure Boot enabled, without also requiring a key for every distro to be registered within your motherboard’s NVRAM settings.
Third-party boot components, like shims, are often signed with the ‘Microsoft Corporation UEFI CA 2011’ certificate so that they play nice with Secure Boot. You may remember that some of the 2011 certificates used by anti-cheat software expired recently.
Anyway, the vulnerabilities resulting from these old shims affected both Linux and Windows users. The 11 shims were part of various tools and software packages, including Linux distros and PC diagnostics software (CERT has compiled a helpful list). Another twist in the tale is that bad actors could also introduce their own copy of an affected shim to a vulnerable system.
Microsoft only revoked the shims’ permissions in June’s monthly patch release. It’s all well and good staying on top of these updates, but ESET have highlighted that at least one of the vulnerabilities they reported had already been well documented a decade ago. The fact that it lingered on for so long, without its permissions being revoked, feels like a huge oversight on Microsoft’s part.
