Which I read as "Don't buy it in the first place, if it's not already supported by OpenWRT."
Simple enough.
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.
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.)
I have a powerful gaming desktop but says not eligible to upgrade to win 11
I'm not a PC builder myself, nice to see the designs people come up with
Uh I mean if you're gonna throw a big GPU in the trash I'll haul it away for only ten bucks...
My rig is not that impressive, i9 with 4070 what sucks is the ram is locked for some reason at 2400mhz even if I buy ram that is faster than that so idk. I swear it that was the specific cpu (10th gen)
I did go through a bunch of steps checking trying to get it to work, stuff in bios enabling settings
You can have my Windows 10 from my cold dead hands ha
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.
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?
The time value of money is at play here. Vulnerability researchers are either black hats or they are something else. Most folks who research vulns don’t exploit devices they don’t own, and those who do are mostly black hats. Most folks with the skills to be black hats if they so desired definitionally have the “skills to pay the bills” but they may be using them in the legal market, so they would need a large return on the time invested, as well as a premium for doing illegal things due to the downside risk of being caught.
Vulnerabilities that can be exploited pay more than hypothetical ones, so proof of concept is worth less than a fully operationalized exploit chain. The larger the install base, the larger the pool of vulnerable target devices, and the larger the payout to the researcher.
A bird in the hand is worth two in the bush because the sure thing is worth more than uncertainly. A demonstrated capability that exploits a vulnerability in a widely distributed device is worth more because it does more than a hypothetical vulnerability in a brand new device that doesn’t already have market penetration or saturation.
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.