U-Boot Has Been Seeing Better x86 Support, EFI Improvements

[phoronix]

Phoronix: U-Boot Has Been Seeing Better x86 Support, EFI Improvements

Google's Simon Glass who is part of the Chromium / Chrome OS team presented at this week's Embedded Linux Conference in San Diego on U-Boot...

http://www.phoronix.com/scan.php?page=news_item&px=U-Boot-2019-Progress

[andyprough]

13 new remotely exploitable vulnerabilities were announced in late July. The security team that found the vulnerabilities indicated they were fairly simple to exploit, and they released a temporary but untested patch. So far I haven't heard that the U-Boot devs have finalized a fix.

[polarathene]

What makes U-Boot interesting to see on x86?

[starshipeleven]

What makes U-Boot interesting to see on x86?

It's orders of magnitude simpler than UEFI while able to do more or less the same things.

[starshipeleven]

13 new remotely exploitable vulnerabilities were announced in late July. The security team that found the vulnerabilities indicated they were fairly simple to exploit, and they released a temporary but untested patch. So far I haven't heard that the U-Boot devs have finalized a fix.

That's dishonest to not cite sources or even say what these vulnerabilities are about. In this specific case it's about a secondary feature that isn't used outside of development, so yeah, cool and all, but much less bad than you make it look like.

https://www.scmagazine.com/home/security-news/vulnerabilities/13-vulnerabilities-disclosed-in-u-boot-loader/

The issues, which can lead to remote code execution, are exploitable when U-Boot is configured to use networking and NFS, said Semmle CSO Fermín Serna, who discovered the fault. He noted U-Boot can be found in this state during development or under diskless configurations, but far less infrequently in “final consumer devices using U-Boot.”

Afaik while quite a few devices do have nfs support in u-boot, with config to pull images from somewhere, it's always disabled as the device is booting from its own flash memory.

The only network-oriented interfaces you can find in use at any scale on embedded devices are a tftp client pulling a firmware image for recovery purposes, or an embedded webserver to provide a web-based recovery the user can use to upload a firmware image.

[polarathene]

It's orders of magnitude simpler than UEFI while able to do more or less the same things.

Ah ok, so you need something like coreboot for it to be usable? I thought it was more akin to grub or systemd-boot.

[d4ddi0]

Ah ok, so you need something like coreboot for it to be usable? I thought it was more akin to grub or systemd-boot.

uboot is more like EFI, BIOS or Coreboot than grub. Its been the standard on ARM forever. It boots a linux kernel directly without need for grub, and it is scriptable enough to boot different options. It really is simpler and more configurable than anything else, BUT like a BIOS/EFI, it needs some work customized for each board/chipset family.

[andyprough]

That's dishonest to not cite sources or even say what these vulnerabilities are about.

Not a single dishonest word in my entire post.

far less infrequently in “final consumer devices using U-Boot.”

Assuming he meant 'far less frequently', he's still saying that there's some final consumer devices in this configuration which are exploitable. Q.E.D. -- risk. Besides which, with rampant global tech espionage, why would you assume there's no risk for devices in development or under diskless configurations? With or without wide-scale consumer device risk, there's still risk. Pwning a few million consumer devices is not the only definition of risk. Are you of the belief that vulnerabilities and remote exploits simply should not be discussed? Seems like a bad idea.

[starshipeleven]

Ah ok, so you need something like coreboot for it to be usable? I thought it was more akin to grub or systemd-boot.

No, on x86 you can start a bootloader off the FSP (the board init blobs also used in Coreboot) or the AMD equivalent directly.

[starshipeleven]

Not a single dishonest word in my entire post.

Yeah apart from not specifying what type of vuln it was, and how irrelevant it is.

he's still saying that there's some final consumer devices in this configuration which are exploitable.

Devices not mentioned, it's speculation at best.

As said above I've yet to see any embedded device that loads images over nfs at all.

why would you assume there's no risk for devices in development or under diskless configurations?

It's kind of obvious for a developer. The documentation states that it will pull anything with the right name from a server at the right IP address. Same as tftp does.
It does not take a genius to know that this is not secure.
Developers can mitigate this by just physically connecting the cable to a isolated LAN that spans their own desk only.

For half-serious diskless configurations, the safety of the data transfer (be it tftp or NFS) is completely irrelevant if you are using basic stuff like firmware signature enforcement on the loaded files before executing/processing them (and u-boot can do this, many more modern devices for US market do that to prevent the load of third party firmware from flash in accordance to US wireless communication laws).

With or without wide-scale consumer device risk, there's still risk.

Risk within specific usecase (development) that is NOT wide-scale and irrelevant if you do your job right and sign the firmware images.

Saying "13 new remotely exploitable vulnerabilities" implies much more risk of saying "u-boot's NFS support is as unsafe as its tftp client, but NFS is rarely if ever used outside of development setups".

As now the only ones at risk are some developers with their own tiny network, running ass-naked with no firmware signatures, not everyone using u-boot.