New FCC Rules Could Ban WiFi Router Firmware Modification

An anonymous reader writes: Hackaday reports that the FCC is introducing new rules which ban firmware modifications for the radio systems in WiFi routers and other wireless devices operating in the 5 GHz range. The vast majority of routers are manufactured as System on Chip devices, with the radio module and CPU integrated in a single package. The new rules have the potential to effectively ban the installation of proven Open Source firmware on any WiFi router.

ThinkPenguin, the EFF, FSF, Software Freedom Law Center, Software Freedom Conservancy, OpenWRT, LibreCMC, Qualcomm, and others have created the SaveWiFi campaign, providing instructions on how to submit a formal complaint to the FCC regarding this proposed rule. The comment period is closing on September 8, 2015. Leave a comment for the FCC.

Comments

Build your own router

[Anonymous Coward]

You can buy an ALIX or Soekris board with a case and wifi card, then install your favorite router distribution on it such as pfSense

Re:Build your own router

[RavenLrD20k]

How do you figure? The wireless card would have its own licensed firmware operating the radio and thus be under the restrictions enforced...but the rest of the box would be managed by the general purpose operating system, which the FCC wouldn't be able to regulate under this rule. The GPOS would then manage what network traffic comes off and goes to the wireless card, but not handle the management of the card directly.

Re:Apple can't modify Time Machine Firmware?

[Wrexs0ul]

I was just thinking that. This is so broad as to be unusable.

And mature products like DD-WRT are what make consumer-grade routers fly. It's pretty much the only reason I'll buy an ASUS, because the stock firmware doesn't have the feature set needed for latency sensitive hardware.

just more rules from Fed.gov

[Indy1]

That I'll happily ignore.

Re:or else what, exactly?

[jonsmirl]

No, they want the routers to ship with CPU Trusted mode turned on. Without access to the private key you won't be able to load WRT.

This a security nightmare since you will now be dependent on router manufacturers for issuing security updates and remotely loading them into your router. We all know how well that has gone in the past.

I also believe that to date the FCC has received zero actually complaints about someone illegally modify current routers. So in attempting to address this imagined problem the FCC is going to enlarge a gigantic real problem (ie unpatched routers).

Re:or else what, exactly?

[bob_super]

We couldn't get the rape, hate crime and murder charges to stick... But you're going down for updating your WiFi!
Justice Has Been Served !!!!

This is a real threat

[Wiseleo]

The PDF explicitly mentions DD-WRT as an example of what should not be permitted:

Third-Party Access
Control
1. Explain if any third parties have the capability to operate a US sold device on any
other regulatory domain, frequencies, or in any manner that is in violation of the
certification.
2. What prevents third parties from loading non-US versions of the
software/firmware on the device? Describe in detail how the device is protected
from “flashing” and the installation of third-party firmware such as DD-WRT.

Wrote a comment.

Nope.FCC application form: "protected from dd-wrt"

[raymorris]

That would be reasonable, perhaps, but it's not the approach the FCC is taking. The FCC instructions (linked below) require all applicants (manufacturers) to:

      Describe in detail how the device is protected
from âoeflashingâ
      and the installation of third-party firmware such as DD-WRT.

So indeed the rule they have proposed is to explicitly require that manufacturers prevent the installation of DD-WRT.

https://apps.fcc.gov/kdb/GetAt...

My comment to the FCC regarding several security

[raymorris]

I submitted a comment to the FCC outlining several significant security concerns regarding the proposed rule.

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 installed.

Manufacturer firmware does the exact opposite, for ease-of-use by ordinary consumers. All services which might be of use to any customer are installed, enabled, and wide open for

Re:or else what, exactly?

[plover]

I also believe that to date the FCC has received zero actually complaints about someone illegally modify current routers. So in attempting to address this imagined problem the FCC is going to enlarge a gigantic real problem (ie unpatched routers).

There's the clue to "follow the money." If this isn't a real problem, it's likely legislation that's been written by some big company whose profit model is threatened by open source. Look for the sponsors to be Cisco or Belkin, someone who would benefit by selling you replacement hardware if their old hardware gets hacked.

And that suggests a potential cure.

If this is to go forward, it needs to come with a big safety, hacking, and consumer safety clause, something like "Due to the restrictive nature of this rule, the vendors of devices subject to these restrictions must offer a free 20 year warranty repair or replacement of any device found to have a flaw in either the hardware or the software included with the device, including any flaws that expose the device to unauthorized access or use. This replacement must include free shipping of the replacement part, free return shipping of the failing device, and free on-site installation of the replacement device. If repairs can be made via software update, the manufacturer may opt to update all affected machines remotely. All such repairs must be completed within one month of the FCC being made aware of the flaw. This free service must be extended for 20 years from the date of the device registration with the FCC. Any company who dissolves or reorganizes before the 20 year span expires will automatically transfer the liability for free replacements to the majority acquirer of their assets. Non-compliance with this law will result in fines to the manufacturers and distributors of these devices equal to twice the retail purchase price at the date of the sale of the first device multiplied by the quantity of devices manufactured, with the fines to be disbursed equally to customers who physically present the device to an authorized FCC representative, and the FCC."

If they still want this law when it includes a poison pill like this, then we'll all be cheering for bugs to be found every month so we can get another "router check" from them.