Wi-Fi Routers: Just How Bad Are They?
I’ve written about the sad state of Wi-Fi routers before, chiefly in FCC Clarifies the Ask for Wi-Fi Routers and Open Source Software and Regulatory Compliance chiefly. The open source community and the FCC want to improve Wi-Fi security, but it’s not clear that they have their arms around the problem. The open source community – led by Google – correctly perceives software shortcomings in today’s routers, and the FCC correctly perceives hardware shortcomings. As severe as these problems are, the avoid the number one issue.
How Routers Come to Be
Before I get to that issue, it’s worthwhile to remind readers about how the process works for the procurement of home routers by large ISPs. Briefly, most home routers are provided by ISPs, who buy them from manufacturers who specialize in large corporate contracts. The manufacturers specialize in low-cost manufacturing, typically through ties to China, and maintain small engineering and system test teams in the US. Because these contracts are very competitive, differences of less than a dollar per unit can make the difference between a multi-million unit sale or no sale at all.
So manufacturers are motivated to keep their devices pretty bare bones; they don’t typically include features that are not required by the ISPs, but the ISPs don’t always write their Requests for Quotation (RFQs) with any attention to detail. I’ve seen some of these documents that consisted of nothing more than a terse spreadsheet. Until recently, security was seen as a non-issue for home routers. To obtain Microsoft certification before 2008, it was necessary for routers to leave the factory with passwords disabled, for example. We now know that’s an extremely undesirable state of affairs.
The manufacturers typically build from system designs provided by the chip companies, who also supply packages of open source software enhanced by customization shops that adapt it to ISP requirements. There are a lot of cooks in the kitchen.
Customers Don’t Keep Router Software Up to Date
So what’s the big issue? An awful lot of the software in home routers was written before security was considered important and is therefore full of bugs and vulnerabilities. While many these bugs have been fixed, millions of units are out in the field that haven’t been updated. When they’re not updated, hackers can install code in your router that you really don’t want.
The Wall Street Journal has done an excellent analysis of the security issues and their consequences that highlights the update problem:Rarely Patched Software Bugs in Home Routers Cripple Security. The title is misleading because the article highlights the problem of users failing to apply patches; the programmers are doing the work, but it’s a tree falling in forest when no one is listening.
The article isn’t the usual newspaper tech policy fare in which a journalist with just a little understanding of technology communicates with a reader with even less: WSJ commissioned Tod Beardsley, a researcher at security company Rapid7, to test and report on the top 20 routers and he did a good job.
The Essence of the Router Problem
The opening three paragraphs explain the issue:
In late 2014, a small Massachusetts software company got an ominous email: A computer-security researcher said a flaw in one of its programs put millions world-wide at risk of being hacked.
Engineers at the company, Allegro Software Development Corp., analyzed the flaw in the program, which can help users access the controls of home Internet routers. They quickly realized something strange: They had fixed this bug nearly 10 years earlier. But it lived on, even in new devices.
The reason: A component maker had included the 2002 version of Allegro’s software with its chipset and hadn’t updated it. Router makers used those chips in more than 10 million devices. The router makers said they didn’t know a later version of Allegro’s software fixed the bug.
The router flaw highlights an enduring problem in computer security: Fixing bugs once they have been released into the world is sometimes difficult and often overlooked. The flaw’s creator must develop a fix, or “patch.” Then it often must alert millions of technically unsophisticated users, who have to install the patch.
Allegro is one of the customization shops I mentioned above. Before its work gets to the router, it has to pass through the chip vendor, the manufacturer, the ISP, and the customer because most of us don’t want our devices updated without our knowledge. If the chain has four links, it’s easy to see how it can be broken. So we need a system where end users are made aware of the need to update their devices. We do this for software already, so there’s nothing weird about it.
How to Keep Code Up to Date
We need to put a system in place that automatically checks for router updates and makes it easy for customers to apply them, in much the same way that operating systems and application programs check for updates and encourage users to apply them. This is a little more complicated for routers than for computers and applications because routers are “headless devices” that don’t have screens or direct access to screens. So the last problem that needs to be solved is how to notify the user. This can be addressed by making one or more of the computers on the home network the administrator. The router checks for updates and notifies the administrator machine when an update needs to be applied.
If the router software doesn’t get an answer, it can send an email to a designated mailbox for update notices. If it still doesn’t get an answer, it can cut off access to the Internet until it gets one. That should get the user’s attention. To resolve ambiguity, ISPs can demand flashing lights on out-of-date routers. This will simplify support calls even if it won’t eliminate them entirely.
But the larger problem is identifying the routers that need particular patches. A given router will include a Linux kernel, a command line interface like BusyBox, and a customized graphical user interface, all at different revision levels. But part of the process of checking for updates is reporting the revision level of the major components.
That leaves it up to somebody – the ISP or the manufacturer – to maintain a database of patches and revision levels. They have systems like this already, but they’re not always as automated as they might be.
The Nuclear Option
If the software in a router isn’t update or checked for updates in a long time – like a year – it’s not unreasonable for the router to stop running until it’s updated. It can maintain a connection to the update site but block out the rest of the Internet. That’s a serious move, but this is a serious problem that we should not be swept under the rug.
It would best for all of this to be a voluntary system maintained by router companies, but one way or another it needs to happen.
UPDATE: Read the comments, where Dale Allyn points to the fact that Apple represents best practices in Wi-Fi routers. He’s right.
Interesting that you don’t mention Apple WiFi routers and software utility as an example of much of what you describe as a desirable solution. Apple’s Airport Utility app checks for router firmware updates weekly, even if the application is not open. And the OS X Software Update checks for utility and router software updates as well. The updates aren’t forced upon the user, but users are notified and provided an easy and very simple path to install the update (two clicks). Automatic update is also an option.
Apple isn’t perfect, but with regard to this topic, they get a lot of it right. They’re conspicuous by their absence from your post, as providing an example worth emulating in some ways.
Good point, Apple represents best practices in Wi-Fi routers. Which you’d expect, given that an Apple spinoff run by a long-time Apple employee (Photonics and Dick Allen) was instrumental in creating Wi-Fi to begin with.
Apple is a special case in that they don’t sacrifice quality to save a few pennies on hardware; Apple is smart, routers should be like Apple’s.