Slashdot Mirror
Why Cybersecurity Experts Want Open Source Routers (vice.com)
derekmead writes: A coalition of 260 cybersecurity experts is taking advantage of a Federal Communications Commission (FCC) public comment period to push for open source Wi-Fi router firmware.
The cybersecurity experts asked the FCC on Wednesday to require router makers to open-source their firmware, or the basic software that controls its core functionality, as a condition for it being licensed for use in the US. The request comes amid a wider debate on how the FCC should ensure that Wi-Fi routers' wireless signals don't "go outside stated regulatory rules" and cause harmful interference to other devices like cordless phones, radar, and satellite dishes.
The cybersecurity experts asked the FCC on Wednesday to require router makers to open-source their firmware, or the basic software that controls its core functionality, as a condition for it being licensed for use in the US. The request comes amid a wider debate on how the FCC should ensure that Wi-Fi routers' wireless signals don't "go outside stated regulatory rules" and cause harmful interference to other devices like cordless phones, radar, and satellite dishes.
good luck! check out this provision in the TPP: http://www.international.gc.ca... Prevents governments in TPP countries from demanding access to an enterprise’s software source code.
Exposed to the internet, never monitored, never updated, and sits between a computer and the internet, the textbook definition of a man in the middle attack..
The two functions get shoved into one box for consumer purposes(often with a DSL or cable modem as well, maybe even a SIP ATA for some 'triple play' nonsense); but logically speaking there usually is a router, though an anemic one, present inside something you'd call a "Wifi router" with an AP connected internally to it. There isn't quite the same neat logical separation that you'd see with enterprise APs, the AP and the router usually share an OS, lousy HTTP configuration interface, etc. but both functions are included.
Dedicated APs are pretty thin on the ground in cheap-consumer-shit land, even compared to discrete DSL and cable modems.
Below is the text of another comment a career security professional (myself) submitted to the FCC on this issue. Specifically, this is regarding the FCC's proposal to essentially outlaw open routers, by requiring that the firmware be boot-locked.
Based on 18 years of professional experience in network security, in both the private sector and government, the proposed rule causes significant concern for information security posture. There are three primary reasons. The legitimate goals of the FCC could be achieved in an alternate manner which does not cause the same widespread security vulnerabilities, by instead requiring that output power levels and any other critical parameters be limited to legal levels by a separate chip. This approach would be far superior to effectively banning proper security practice for the ENTIRE operating system and all utilities on the device, as the current proposal does.
1
The proposed rule which requires that manufacturers disallow firmware updates (other than signed manufacturer updates, typically provided for only a very short time), makes it much more difficult to prevent incidents such as the $45 million loss at TJX and the Target breach. In both cases, the victim companies were initially targeted because insecure wifi devices were in use. To reduce future occurrences of such breaches, it is imperative to be able to update devices which use wireless networking. Especially when a vulnerability such as Shellshock is discovered, it is imperative that risks be mitigated immediately.
Updates provided by the manufacturer may at first seem to be a possible solution, but are not actually a viable solution for two reasons. Manufacturers generally do not provide long-term updates, updates for devices more than about one-two years old. In many cases, no updates are offered at all to handle issues after the date of sale. It is not reasonable to anticipate that organizations and families will replace their network gear every year or two - firmware updates are needed, including for devices which are a few years old. Perhaps ESPECIALLY for devices which are a few years old.
Secondly, updates from the manufacturer are not a viable solution for more sensitive government and private organizations due to the response time required. In the first 24 hours after the release of Shellshock, thousands of systems were compromised. For many networks, it is critically important to mitigate the threat during this initial time frame. Manufacturer full updates were not available for several days to several months, as we first discussed the best long term solution and that solution propagated downstream from the authors, to the subsystem maintainers, distribution maintainers, OEM repackagers, and finally out to customers after testing at each level. In the meantime, temporary MITIGATIONS were performed on-site by network engineers and security contractors. These vital mitigations which protected sensitive networks in the interim would be illegal and prevented by manufacturer locks under the proposed rule. In simple terms, the proposal makes it illegal to manufacturer equipment which can be _quickly_ protected against new threats to our cyber security.
2
Another reason that the proposed rule is problematic is that the manufacturer default firmware, with all available features designed to be as easily accessible as possible, is not appropriate for any environment in which security is a concern. A central tenet of information security, and security in general, is that the attack surface should be as small as possible - services not needed for a particular installation should not be installed and enabled. The only software which definitely cannot be exploited is software which is not installed or not enabled. Therefore, the most secure firmware tends to be that with as many features _removed_ as possible, with only those items required for the current role installe
Just because YOU don't understand it, it doesn't mean that there are a LOT of people that do and would. I'm not knowledgeable enough to personally audit open-source encryption software like GPG and OpenSSL, but I'm glad it's open-source so others who are more knowledgeable than me can scrutinize.
How about this for a title: FCC is trying to strip more of your individual freedoms away, EFF objects.
You can't handle the truth.
Ban isp from forcing you to rent there hardware / make them give you a true bridge mode / pure Ethernet handoff
"Firmware" has multiple meanings. The thing you're talking about is indeed called "firmware", but it is a minuscule fraction of the firmware on a typical router, which is generally a linux/unix derivative and includes everything from device drivers to configuration UI. And which is usually riddled with security vulnerabilities and other flaws.
Even the minuscule bit you're talking about still needs to be inspectable and repairable, because devices always have bugs -- often already known by the time they're shipped and purchased -- and device manufacturers have (apparently) little to no economic interest in fixing them, and it's the owner of an RF device who is legally responsible for compliance. Unless you honestly expect everyone to throw their routers away and buy new ones every few months, or you simply don't care about security, performance, or FCC compliance, field updates are a necessity.
If an RF-controlling firmware component is nothing but the equivalent of a few jumper switches, then document them thoroughly. If it's functional software (which in fact it pretty-much always is), then publish it, and do so in a form so it can be recompiled to ensure that what's on the device is the same as what was published. Volkswagen has proved beyond any reasonable person's doubt that unverifiable software is not to be trusted.
(Disclosure: co-author/signatory to the FCC letter.)
and no, it wasn't finally discovered because it was OSS, but buy automated testing that works equally well on closed source
But the fix was able to be independently verified because it is OSS.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
What's sad is that in an ideal world, the NSA *would* help and perform security audits to keep citizens, businesses and government safe from malicious actors.
But sadly, their version of help means inserting back doors and compromising security in the name of DEA parallel constructions to jail some hippie for growing pot.
You, however, seem to be confused about what firmware is because you are comparing it to "complicated software". And this has been my experience with software engineers--it is impossible to convince them that there is knowledge in this world which is not directly mappable to some sort of software.
There are parts of firmware that are just not understandable unless you have deep knowledge the specific hardware device sitting in front of you, in some cases down to the circuit level (or below, even). It is unreasonable to insist that hardware vendors document their devices down to that level and it is dangerous to allow random idiots to muck about with that firmware.
In a good deal of the consumer crap devices I have looked under the hood of, the device runs a crippled version of openwrt.
In such cases, the router and AP functionality comes about entirely through software, since the core OS treats both the wired interface and the wireless interface as discrete network interface cards. The wired interface is usually the one that is more interesting, as the multiple ports are treated as VIFs.
Considering the pricing point of between 50 and 100$ for most consumer grade PoS devices out there, there's a pretty good featureset under there if you can just get past the ABYSMAL driver and config script stack that the manufacturers often push on the poor things.
Often times, the "stock" firmware for these devices use drivers that have been hacked up seven ways to sunday so that they expose certain behaviors-- and have config scripts that do loopy loops to try and get the system into a state that the device maker wants it to be in. (Things like having the root password be set via script every bootup, because the stock firmware does not have a JFFS partition to store actual root credentials, and instead stores the user-defined password in the NVRAM so it can be easily reset with the reset button. On bootup, the script grabs the value from NVRAM and sets the root password. Nevermind the DUMBSHITNESS of exposing the root user this way, since it runs all the services under root.) Looking at it, it is the script equivalent of a Rube-Goldberg contraption.
OpenWRT (the REAL deal, not the hacked up dog and pony show that netgear and pals puts under the hood of their devices) boots in a fraction of the time (Stock firmwares often take over a full 2 minutes to fully finish the init script!! Open WRT becomes fully functional in typically under 30 seconds.) allows PROPER device administration (like, allowing you to set up proper service user and group accounts on the router to segregate process access requirements, set up and use jails, give you your choice of what routing and wifi supplicant package to use, what HTTP daemon to use-- if any-- etc.)
Consumer grade crap can become quite useful with a firmware update. Just that you have to treat it like what it actually is--- a small, general purpose computing platform-- and set it and configure it appropriately.