On 5/9/20 7:45 PM, Patrick Wildt wrote: > On Sat, May 09, 2020 at 06:38:33PM +0200, Heinrich Schuchardt wrote: >> On 5/9/20 6:13 PM, Patrick Wildt wrote: >>> On i.MX platforms board_spl_fit_post_load() can check the loaded >>> SPL image for authenticity using its HAB engine. U-Boot's SPL >>> mechanism allows booting images from other sources as well, but >>> in the current setup the SPL would just hang if it encounters an >>> image that does not pass scrutiny. Allowing the function to return >>> an error, allows the SPL to try booting from another source as a >>> fallback instead of ending up as a brick. >>> >>> Signed-off-by: Patrick Wildt <patr...@blueri.se> >> >> Could an intruder abuse this by destroying a signed image and providing >> an unsigned image on a source under his control? >> >> Best regards >> >> Heinrich > > Sure, let's think about it here. Maybe you have some more thoughts to > add. > > First of all, the SPL goes through all the boot devices, and if there's > none to find with an image, it will hang. It will hang like it does > before the diff. The only difference is that it tries additional > sources before hanging. Thus the attacker, unless he can exploit it > in his first trial, or is able to force a reset, must have some access > to reset the machine to have it boot and try again. This seems like he > must have some kind of local or remote phyiscal access. > > Let's assume the image is on the network or on another remote medium. > Then I guess the attacker will just try to attack that medium, and the > alternate boot sources won't make a difference. > > I guess that means we should focus on local sources. I think we can > also ignore a removable SD card, since he can just put in another one > and try again. > > So maybe let's think about SPI flash and eMMC, soldered on, not directly > accessible. If he has physical access, I guess he could open up the box > and desolder a few pins, or add some voltage here and there to try and > disrupt the bootup. But, then maybe it's easier to just desolder the > whole SPI/eMMC and add his own. > > But what if he doesn't have that access? If he's remote? Ok, he will > probably have to exploit the daemon (webserver or whatever) to gain some > code execution. Then he'll try and become root, so he can access the > disks. Then I figure he'll try and overwrite or remove the image. > With this, on the next reboot it will (hopefully) fail to boot, unless > he already has an exploit, then my patch won't make a difference. > > I figure the real issue could be that when the attacker has physical > access, manages to remove/replace the image with a fallback to load from > a device like an SD card, that it's now easier for him to try and find > an exploit.
This last scenario is what I was thinking of. So if HAB is used it may be ok to search all devices for signed images but non-signed images should be rejected. Is that given with your patch? Best regards Heinrich > > Am I missing something? > > Best regards, > Patrick >
