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

Ow my reading comprehension

[Anonymous Coward]

Parsing legalese tends to cause me physical pain, but I decided to check the actual text rather than accept the summary.

So, here's the deal, any radio transmitter physically capable of operating in certain controlled bands has some complex and moderately convoluted limits applied to parts of those bands. This is about keeping those bands operating in the ways the FCC has approved. IFF your preferred Open Source software were to include those restrictions in its default behavior list, they'll be fine. If you use such a re-written wifi controller with the proper default behavior list, you'll be fine. If you remove one of the safeguards and start broadcasting a jammer signal on police radio frequencies, you'll be very far from fine.

they don't ban installation of open source

[YesIAmAScript]

It simply requires the hardware to be designed such that if you install open source, you cannot modify the radio to use frequency bands and powers that it is not supposed to use.

And this is easy to do. Just put in settings to limit power and lock out bands and make those settings irreversible until a full system reset. Then make the bootloader set those settings before running the installed OS.

Then the OS can be open source.

It would be absolutely fantastic if people would be rational about tech news. Tech people/netizens are starting to sound like my grandfather now. Every change is something to be feared. OBAMA IS GOING TO TAKE YOUR GUNS! The people running the FCC are people, just like you. They aren't demons or out to get you. Try to work with other people you haven't met instead of exhibiting xenophobia.

Re:Like Tomato?

[gstoddart]

Well, if we're getting into the business of banning things on the basis of what they could be used for, let's start with rocks

You joke, but from TFA:

Under the rule proposed by the FCC, devices with radios may be required to prevent modifications to firmware. All devices operating in the 5GHz WiFi spectrum will be forced to implement security features to ensure the radios cannot be modified. While prohibiting the modification of transmitters has been a mainstay of FCC regulation for 80 years

In other words, this is something they've been doing for a very long time, and they are suddenly saying you can't modify things which impact transmitters. It's kind of the things the FCC has been doing for decades.

So while TFA says "yarg, teh open source and teh tinkering" ... in part it's the FCC reminding people there are long established rules in place for determining what you can do with a transmitting device.

If the Federal Rock Administration had been regulating rocks for 80 years, then your analogy might be bullshit.

But preventing making changes to a transmitting device is something they've been doing for a long time. It's not like they're newly asserting this authority, they're pointing out they've had it for decades.

Re:Good luck enforcing that, FCC

[Anonymous Coward]

Actually, no.

Almost every embedded SoC - from the most expensive Altera down to Atmel's pinhead-sized ATTiny-13 BGA package - comes with security fuses for exactly this purpose. By writing 1 to fuse bits in the code, upon upload it can be made to physically destroy the debug interface, the flash memory's writeability, and/or a few other things used by the in-house hackers (engineers) to develop a product before rendering it "final" when it's shipped out to the hostile world. Yes, our beloved hobbyist micros can do this too.

Believe it or not, SoC designers have in fact thought of how to keep people from altering and expropriating the code that's stored on microcontrollers before. If you want to prevent somebody with less than a full-on chemistry, nanolithography and electron microcroscopy setup from even *reading* it, it's not hard.

Of course, most non-trivial systems don't go this far precisely because it also makes updates to the main code impossible. So they design a bootloader that IS locked down this way, and which is trusted to check the main code before running it, which is the good-on-paper theory behind Trusted Computing.

Re:Like Tomato?

[jimbolauski]

The restrictions are only for the 5GHz band. The reason is 5GHz is supposed to use dynamic frequency selection and transmit power control this is to avoid interfering with weather radar and allow more people to play nice together. They just don't want Dorthy to get hit by a tornado because some one is crapping all over that frequency. They are using a cannon to kill a fly when all they have to do is require that any firmware follow DFS and TPC on 5GHz routers.

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

Re:Apple can't modify Time Machine Firmware?

[Gr8Apes]

The restriction seems to the RF portion only: "and would affect the operating parameters of frequency range, modulation type or maximum output power". So if the firmware doesn't effect any of those 3 items, you're not subject to this.

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