An alternative would be to have the firmware show a description of the signed content, like version information, that the user must OK. It might show it along with the current version with a warning if versions are downgrading or the whole thing is changing. The warning might tell you to be sure of the source of this update. If it's the same software, and another version, it might be set to automatically update.
If it's the lowest-level, unrecoverable firmware, I like it being hard for attackers to change it. One idea I used to push was putting that in EEPROM with a jumper (or switch) required to update it. The software will have already performed numerous checks from the kernel state to the payload with external inputs (eg networking) shut down. If malicious, it can't do anything without that physical interaction.
The regular, update mechanism which uses other storage is in that EEPROM. It has highly, security-enhanced mechanisms for updates. It might even have it's own partition if it's a microkernel-based system. So, we have one that's hard to attack with software while the other takes physical attack or social engineering. Also, I think a Chromebook or something implemented a ROM/flash combo.
For example: manufacturer bakes in their public key and a per device public/private key pair. The bootloader checks firmware updates against the manufacturers public key and the per device public key. The per device private key is only readable with hardware access via serial or USB etc. The user can extract their device’s private key to be able to sign their own firmware updates. Additionally, the bootloader could support adding new public keys to verify firmware with, so long as the payload to add the new public key was signed by the per device key. This would simplify getting updates from e.g. OpenWRT if they have their own key pair they sign with, vs requiring each user to sign each firmware update with their personal key.
If they support OpenWRT or similar, fair enough - maturity does bring some additional safety. But in general this is not the case. Or am I missing something?
Here's the exploit for the Netgear WGR614v9: https://github.com/trailofbits/exploits/tree/main/junkyard-2...
Here's the exploit for the BitDefender Box 1: https://github.com/trailofbits/exploits/tree/main/junkyard-2...
There's a lot of included detail so you can learn how to write your own and really understand every decision we made in writing them.
myself248•11h ago
Which I read as "Don't buy it in the first place, if it's not already supported by OpenWRT."
Simple enough.
iszomer•8h ago
sidewndr46•8h ago
You can have a device that is 100% supported by everyone from the chip vendor, board assembler, and an OEM that is still trivially vulnerable.
yjftsjthsd-h•7h ago
tonyhart7•7h ago
sidewndr46•6h ago
kej•1h ago
swinglock•7h ago
sidewndr46•6h ago
Hilift•7h ago
sidewndr46•6h ago
Zigurd•5h ago
bee_rider•4h ago
nickpsecurity•5h ago
Older hardware has had longer for vulnerabilities to be found. Some might not mitigate new classes of vulnerabilities. The EOL hardware will not receive patches for any vulnerabilities. So, they're at higher risk of attack.
From there, the attack will be either malicious input to that machine over the network or a file that embeds an attack. Many problems can be mitigated by running secure software, esp for input validation, on that hardware. One might also use them offline or on trusted networks with software that's hand-chosen for them. (That's what I do.)
ge96•3h ago
I have a powerful gaming desktop but says not eligible to upgrade to win 11
gnopgnip•1h ago
ge96•44m ago