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_KGrFjHftZLm... https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

Regards, Joakim