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..
Government intelligence agencies can help contribute to the code base.
The IRS can then help watch people more and help them form more correct political views.
The FEC can then help the Party making sure helpful people are able to help more!
Firmware can be extremely messy, low-level code. It may not even be written in any sort of recognizable programming language. It is frequently the digital equivalent of a set of jumper switches, just a binary blob which is meaningless if you don't have deep knowledge of the hardware it is controlling. Firmware can directly control low-level electronics and an incorrect setting can lead to physical damage to the device and potential harm to nearby humans.
It is dangerously stupid to insist that firmware be open-sourced and to allow developers to modify the firmware on devices.
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
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
It happens like this:
(1) Companies write TPP and other laws to indemnify themselves and resist modifications to their buggy routers.
(2) FCC makes the problem worse by effectively requiring DRM on routers.
(3) incidence of serious hacks skyrockets as people are unable to update their routers and other network-enabled devices.
(4) legislators react to spike in online crime/tragedies not by undoing (1)-(3) but with "get tough" anti-"hacking" laws that chill research and throw people in jail for minor transgressions, research, clock-building, vulnerability disclosure, security tools, or a anything not understood that politicians and aggressive prosecutors could perceive as "hacking".
(5) The problem gets MUCH MUCH worse as a result. Bright minds are tossed into jail, open research is chilled, and online crime continues to skyrocket.
(6) GOTO 4.
-------------------
This is my SIG. There are many like it, but this one is mine.
The TPP effectively takes control of the www. If we follow the adage of "the Internet treats censorship as damage and routes around it," then we can see that what will most likely develop is a network that is outside of the www. The easiest way to implement such a network in the U.S. is with Wi-Fi-type devices, but if those devices are locked down, not just legally, but physically, then this task becomes yet harder, especially with the ridiculously low power limitations placed on consumer controlled devices.
http://www.afar.net/tutorials/...
How do you implement the rules listed there for antenna gain?
If your equipment is used in a fixed point-to-point link, there are two exceptions to the maximum EIRP rule above:
In the 5.8 GHz band the rule is less restrictive. The maximum EIRP allowed is 53 dBm (30 dBm plus 23 dBi of antenna gain).
In the 2.4 GHz band you can increase the antenna gain to get an EIRP above 36 dBm but for every 3dBi increase of antenna gain you must reduce the transmit power by 1 dBm. The table below shows the combinations of allowed transmit power / antenna gain and the resulting EIRP.
Transmit Power
(dBm)
Antenna Gain
(dBi)
EIRP
(dBm)
30 6 36
29 9 38
28 12 40
27 15 42
26 18 44
25 21 46
24 24 48
23 27 50
22 30 52
I don't see any way for the wifi router to tell the gain of the antenna you attach to it and automatically drop the signal strength.
The responsibility for staying within these power limits falls on the operator (or, if professionally installed, on the installer).
So if that is the case, why is this firmware lockdown even on the table, even with locked down firmware, you are responsible for staying within the power limits.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
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.