Hi, Yet another security issue surfaced yesterday, see this blog post about it https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
When I was reading it I cannot avoid seeing similarities to what I've tried to raise in the DT(E) discussions. I.e., firmware run-time exploits running after signatures have been verified successfully (slide 27, 28 [1]) can be devastating and therefore I've tried to suggest that each component verifies the DTB that it gets from the previous firmware component (slide 29, 30 [1]), alternatively and probably better ... doing something like a measured boot (including DTB's) where you compute a running hash spanning across all firmware (+configuration) being loaded. Some quotes from the blog post: > Almost all signed versions of GRUB2 are vulnerable, meaning virtually > every Linux distribution is affected. We don't want to read something similar about DTS/DTB in the future. > Additionally, as we will show in this blog post, a vulnerability in the boot > process that enables arbitrary code execution can allow attackers to control > the boot process and operating system, even when secure boot signatures are verified. Confirm my concerns. > In the course of Eclypsium’s analysis, we have identified a buffer overflow vulnerability > in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg). > Of note: The GRUB2 config file is a text file and typically is not signed like other files > and executables. This vulnerability enables arbitrary code execution within GRUB2 and > thus control over the booting of the operating system. As a result, an attacker could > modify the contents of the GRUB2 configuration file to ensure that attack code is run > before the operating system is loaded. In this way, attackers gain persistence on the device. Replace "GRUB2" with "DT" and "grub.cfg" with "*.dts/dtb" in the quote above and we have another potential future quote about DT security issues. A solid, useable and robust solution for problems like this might be complex to realize, but I think it's worth continuing to look into what can be done, since it seems risky to continue loading and running "DT code" like we're doing in many places today (and it's not only DT that is subject to this, regular firmware suffers with the same kind of issues). I.e., I'm going to raise this again in future DT(E) calls. [1] https://docs.google.com/presentation/d/1CvKBBZ33ggzyhP2ub8iZ410I_KGrFjHftZLmTY0-23A/edit?usp=sharing <https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/> Regards, Joakim _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
