> We have been assessing our existing processes (for OpenWrt, and especially the OpenWrt One) against NIST IR 8425A, and are now accelerating those efforts to ensure we can show that routers using OpenWrt are indeed safe and secure, as determined by independent bodies.
It would be awesome to have somebody show that OpenWrt-based routers are safe and secure. I looked into this problem about 10 years ago and my concluding was that stock OpenWrt was really questionable. Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-first-from-the-ground-up alternative with a real trustworthy update story.
> Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-from-the-ground-up alternative with a real trustworthy update story.
I admit I'm not super deeply familiar, but I would have guessed the opposite - that openwrt had no extra software included, not least because it's targeting devices where total disk and RAM are measured in megabytes. What components would you remove/replace that make it "giant"?
The only thing that can reasonably be called "giant" about OpenWRT is the package repository: it has a decent package manager like you'd expect to find on a desktop Linux distro, and it can be used to add functionality to your router, including a fair bit if stuff that goes well beyond what is typically used on routers. But the default install set is not giant, and is typical of what you'd expect for a wireless router.
My impression was that autoupdate was not the default because the devices it runs on only have so many resources, and there's a non-trivial chance of bricking the device (given how many devices are supported)? It's not like other vendors are doing any better in this space (and I've seen enough things in the "IoT/embedded" space brick themselves with updates to be a bit wary of autoupdates).
Auto-update is also a bad idea unless you can make it really secure, which is hard to do on devices so constrained they don't even have a clock to keep track of what day it is to judge whether a certificate is still valid.
Minimizing the chance of bricking the device with an automatic update requires at a minimum having two copies of the OS, so that the running copy isn't trying to modify itself and can remain as a fallback in case of a broken update. That's not too challenging these days now that most routers are using NAND flash, but for a long time it was common to use very small NOR flash modules with the absolute minimum capacity.
Updates don’t currently have a way to ensure that user installed packages have their configurations updated appropriately, so user installed packages may break on update. Additionally, as a sibling comment pointed out, official images don’t include user packages, so you’d either need a scalable way to build custom images or the updater would need to be smart enough to reinstall packages after update.
It would still be nice to have an official automatic update feature that is opt-in for stock systems.
You also need to rebuild the firmware with the installed packages. Otherwise you end up without your packages installed. That requires a server to build the firmware for your device. Doing this automatically for everyone is resource intensive.
They have the tools and infrastructure for assembling custom firmware images on-demand, and have recently added it to the default images, so they must feel like their infrastructure is ready for significantly increased demand.
I use attended sys upgrade. I've been using OpenWrt for the last 7 years, but I've noticed that attended sys upgrade often fails at release time. And there are often point releases shortly after. I'm just skeptical that their infrastructure would handle mass auto updates at release time. I usually wait a few weeks after release until the masses have reported various device specific bugs before I upgrade.
OpenWRT updates are very much discouraged on an ongoing basis primarily because most devices running it use very cheap flash chips which are small and fail quickly after too many writes. They’re nowhere near the level of SSDs, or even SD cards, that can handle many flash cycles.
Almost as important is the fact that updates do not overwrite the original packages, because those are in a read-only partition. Updates are written to an overlay file system, so every updated package uses twice as much flash space. Installing updates weekly would quickly fill the flash.
But as far as vulnerabilities go, what’s the actual exposure? From the outside there’s no ports open, and on the inside only a few for device management, and basic services like dhcp, etc. Those have been around for decades and are pretty well hardened by now.
Pretty much all the routers that are targeted by the ban would be OpenWrt derivatives, AFAICT. It’s basically the Android of routers, except without the Google resources.
Google Wifi Is one of the main lines that aren’t based on OpenWrt.
Just in case anyone else was wondering, it seems that some early products (running AirOS) were modified versions of OpenWRT, but later software/hardware is not.
So yes, this comment is correct, but it threw me since I wasn’t following the company back then and I hadn’t heard of that history before.
I always assumed it was priced outrageously to have a big enough margin to start fulfilling the preorders and refund requests from the original kickstarter. The device does not sell very many units so it won't benefit from bulk pricing.
> We have been assessing our existing processes (for OpenWrt, and especially the OpenWrt One) against NIST IR 8425A, and are now accelerating those efforts to ensure we can show that routers using OpenWrt are indeed safe and secure, as determined by independent bodies.
It would be awesome to have somebody show that OpenWrt-based routers are safe and secure. I looked into this problem about 10 years ago and my concluding was that stock OpenWrt was really questionable. Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-first-from-the-ground-up alternative with a real trustworthy update story.
> Like, there is no auto-update story, but at the same time it is a giant (relative to what it should be, IMO) Linux distro full of vulnerability-laden components. This space is in dire need of a minimal security-from-the-ground-up alternative with a real trustworthy update story.
I admit I'm not super deeply familiar, but I would have guessed the opposite - that openwrt had no extra software included, not least because it's targeting devices where total disk and RAM are measured in megabytes. What components would you remove/replace that make it "giant"?
The only thing that can reasonably be called "giant" about OpenWRT is the package repository: it has a decent package manager like you'd expect to find on a desktop Linux distro, and it can be used to add functionality to your router, including a fair bit if stuff that goes well beyond what is typically used on routers. But the default install set is not giant, and is typical of what you'd expect for a wireless router.
My impression was that autoupdate was not the default because the devices it runs on only have so many resources, and there's a non-trivial chance of bricking the device (given how many devices are supported)? It's not like other vendors are doing any better in this space (and I've seen enough things in the "IoT/embedded" space brick themselves with updates to be a bit wary of autoupdates).
Auto-update is also a bad idea unless you can make it really secure, which is hard to do on devices so constrained they don't even have a clock to keep track of what day it is to judge whether a certificate is still valid.
Minimizing the chance of bricking the device with an automatic update requires at a minimum having two copies of the OS, so that the running copy isn't trying to modify itself and can remain as a fallback in case of a broken update. That's not too challenging these days now that most routers are using NAND flash, but for a long time it was common to use very small NOR flash modules with the absolute minimum capacity.
Updates don’t currently have a way to ensure that user installed packages have their configurations updated appropriately, so user installed packages may break on update. Additionally, as a sibling comment pointed out, official images don’t include user packages, so you’d either need a scalable way to build custom images or the updater would need to be smart enough to reinstall packages after update.
It would still be nice to have an official automatic update feature that is opt-in for stock systems.
You also need to rebuild the firmware with the installed packages. Otherwise you end up without your packages installed. That requires a server to build the firmware for your device. Doing this automatically for everyone is resource intensive.
See https://openwrt.org/releases/25.12/notes-25.12.0 and https://openwrt.org/docs/guide-user/installation/attended.sy...
They have the tools and infrastructure for assembling custom firmware images on-demand, and have recently added it to the default images, so they must feel like their infrastructure is ready for significantly increased demand.
I use attended sys upgrade. I've been using OpenWrt for the last 7 years, but I've noticed that attended sys upgrade often fails at release time. And there are often point releases shortly after. I'm just skeptical that their infrastructure would handle mass auto updates at release time. I usually wait a few weeks after release until the masses have reported various device specific bugs before I upgrade.
OpenWRT updates are very much discouraged on an ongoing basis primarily because most devices running it use very cheap flash chips which are small and fail quickly after too many writes. They’re nowhere near the level of SSDs, or even SD cards, that can handle many flash cycles.
Almost as important is the fact that updates do not overwrite the original packages, because those are in a read-only partition. Updates are written to an overlay file system, so every updated package uses twice as much flash space. Installing updates weekly would quickly fill the flash.
But as far as vulnerabilities go, what’s the actual exposure? From the outside there’s no ports open, and on the inside only a few for device management, and basic services like dhcp, etc. Those have been around for decades and are pretty well hardened by now.
Is there a way to prove that a device claiming to run OpenWrt is actually running it and not a modified, compromised version of it?
Pretty much all the routers that are targeted by the ban would be OpenWrt derivatives, AFAICT. It’s basically the Android of routers, except without the Google resources.
Google Wifi Is one of the main lines that aren’t based on OpenWrt.
I don’t operate any OpenWrt-based devices.
Ubiquiti built a multi-billion dollar company on modified OpenWRT.
Just in case anyone else was wondering, it seems that some early products (running AirOS) were modified versions of OpenWRT, but later software/hardware is not.
So yes, this comment is correct, but it threw me since I wasn’t following the company back then and I hadn’t heard of that history before.
Pretty sure the unifi firmware on APs is still modified openwrt as are many of their other products.
Just look for syswrapper.sh
(Very long time ubiquiti user, alpha tester, etc)
>see the Librem 5 (USA) for example
I always assumed it was priced outrageously to have a big enough margin to start fulfilling the preorders and refund requests from the original kickstarter. The device does not sell very many units so it won't benefit from bulk pricing.
April 2. Was this an April 1 joke?