Top 10 FOSS legal stories in 2016 (opensource.com)

[Posted February 16, 2017 by corbet]

Mark Radcliffe surveys the most important legal issues surrounding free and open-source software on opensource.com. "The challenge for the Linux community is to decide when to bring litigation to enforce the GPLv2. What it means in many situations is that to be compliant is currently left to individual contributors rather than being based on a set of community norms. As Theodore Ts'o noted, this issue really concerns project governance. Although permitting individual contributors to make these decisions may be the Platonic ideal, the tradeoff is ambiguity for users trying to be compliant as well as the potential for rogue members of the community (like McHardy) to create problems. The members of the Linux community and other FOSS communities need to consider how they can best assist the members of their community to understand what compliance means and to determine when litigation might be useful in furtherance of the community's goals."

Router lockdown

Posted Feb 17, 2017 9:49 UTC (Fri) by mfuzzey (subscriber, #57966) [Link] (18 responses)

Of course it's the FCCs role to police frequency allocations and that is absolutely necessary.

But, while of course they should ensure that routers as shipped comply with the rules I don't think they should try to prevent users from modifying them.
If a user does so and causes interference then they should be fined, have the equipment confiscated and possibly even go to jail.

Just as with cars, they have to meet lots of regulations before being approved for sale (quite rightly) but if the end user modifies his car to no longer be in compliance he's responsible, not the original manufacturer.

Routers typically have an application processor running Linux and firmware running on the radio chipset itself.
The radio chipset firware is rarely (if ever) OSS.
But the firmware on the radio chipset is generally configured by the host OS and Linux has a mechanism (CRDA) for distributing up to date signed configuration data.

Nothing in the FCC rules actually *requires* the code on the application processor to be locked down (or any specific protection mechanism at all) but that's often the easiest way for the vendor to convince the FCC that it has met the requirements.

The other problem is that the rules vary depending where you are in the world.
So, while it would be possible to do everything related to the FCC rules in the radio chip firmware and use different firmware for different zones that would actually work less well than the current scheme regarding compliance when devices move around the world (a device purchased in the US travelling to Europe or vice versa).
The host OS is in a better position to know where it is located and configure the radio appropriately.

Router lockdown

Posted Feb 17, 2017 12:32 UTC (Fri) by pizza (subscriber, #46) [Link] (15 responses)

> Nothing in the FCC rules actually *requires* the code on the application processor to be locked down (or any specific protection mechanism at all) but that's often the easiest way for the vendor to convince the FCC that it has met the requirements.

s/easiest/by far the easiest and cheapest/

Keep in mind that for the vast majority of devices, the "application processor" and the "radio chipset" are two sections of the same silicon.

There is rarely any hardware-level feature that prevents operating out of band (keep in mind that different countries have different legal bands, so the hardware needs to be capable of doing so. Many radios even allow operating well outside the "traditional" wifi spectrum. And the hardware is configured, both in the operational sense and the limitation sense, entirely by software.

Sure, you can say that the config data is stored in a special write-once non-volatile storage, but the "application software" still reads that chunk and hands it off to the radio.

This means the only ways to prevent the user from causing the device to operate out-of-band are: (1) completely lock down the application processoror, or (2) re-architect your silicon to make the regulatory/etc configuration parameters only accessible by the radio hardware, which in turn must be heavily locked down. The latter takes literally years of lead time.

Router lockdown

Posted Feb 17, 2017 15:35 UTC (Fri) by RogerOdle (subscriber, #60791) [Link] (14 responses)

Locking down the hardware certainly does not take years of lead time. It takes almost no time at all to design in locks on RF hardware compared to the time to design the RF circuits themselves. The circuits themselves can be configured by one-time fuses so that there is one-shot to make it work for a particular market. This technology has been around for years to protect intellectual property. The problem is that these days manufacturers assume they can ship unfinished products that they can patch with "security updates" instead of making them work right before they ship. So the idea of one-time configuration is not welcome by the manufactures who are rushing to market.

Let's keep in mind that a router is an appliance. It is not a phone, tablet, or computer that you use for web surfing or playing games. You buy it, set it up, and leave it. It becomes an awkward looking thing that sets on the shelf that you take for granted. An obvious target for hackers who can penetrate the heart of your communications at a location where you never look. Just how "programmable" do you want your router to be? I like the idea of reprogramming it so I can improve the security of the device but I do not want it to so easy that the dumbest hacker on the planet can mess with it.

Router lockdown

Posted Feb 17, 2017 16:23 UTC (Fri) by pizza (subscriber, #46) [Link] (13 responses)

> Locking down the hardware certainly does not take years of lead time.

You are, in a word, incorrect, especially if said hardware was not already designed to be locked down.

(My $dayjob involves producing licensable radio IP, so I can say that with some authority)

While not necessarily taking years, there's still a substantial lead time -- A year from requirement capture to something being in an end-user's hands would not be unreasonable, with each middleman/vendor/etc involved adding more to the timeline.

> So the idea of one-time configuration is not welcome by the manufactures who are rushing to market.

No, the problem is that manufacturers don't want to have to produce a unique product for every market, and want to be able to shrink the Bill of Materials as much in possible so they have a chance of making _some_ money..

> Just how "programmable" do you want your router to be? I like the idea of reprogramming it so I can improve the security of the device but I do not want it to so easy that the dumbest hacker on the planet can mess with it.

Those two properties exist on different axes; the former is more a matter of design, the latter is more a matter of quality.

Router lockdown

Posted Feb 17, 2017 18:56 UTC (Fri) by RogerOdle (subscriber, #60791) [Link] (12 responses)

I am an RF engineer so I do know what I am talking about. If you have been producing radio IP then you should have the necessary skill and training to lock it down. By now it should be a matter of routine. Since the RF IP is most probably in the form of VHDL language, combining it with lockouts at critical points is trivial, not difficult.

It is not without cost. It may involve a turn in the silicone layout. The cost is insignificant because it does not require any change to the actual RF circuits, only to the control interfaces.

One-time programmable configuration does allow them to shrink the bill-of-materials since the programmable fuses are built into the RF integrated circuits and cost nothing more than it does to produce them in the first place. The problem is that once you burn them, the device is committed to the market it is programmed for. This isn't a technical problem, it is a logistics problem. The answer is also simple. Do not burn the fuses until you ship to the final customer.

As for router programmability being merely a factor of quality, I beg to differ. If you think your router is secure because you disabled the admin interface from the Internet side, they are now being attacked on the inside of your network from corrupt websites that attack your router from your own browser. Sure you can blame the users who never change the admin password from the default but the average layman barely knows how to setup one in the first place. If the router manufacturer's made a simple change to the control interface then the router would not work as a router at all until the default password was changed. That simple change alone would reduce the number of router attacked by two orders of magnitude.

The FCC is being practical when it requires restrictions on router hardware. The alternate is for them to only allow WIFI routers to be used by trained and licensed individuals. We all know that won't work. So the next best thing is to require hardware designs that resist abuse by malicious or incompetent people.

RF devices are not private things. They operate in the airwaves that all share and have coresponding responsibilities. Instead of blaming the FCC of some kind of nefarious behavior, how about coming up with alternate solutions?

Router lockdown

Posted Feb 17, 2017 21:54 UTC (Fri) by pizza (subscriber, #46) [Link] (11 responses)

(Please, please quote properly.. it makes your responses far easier to read)

>If you have been producing radio IP then you should have the necessary skill and training to lock it down. By now it should be a matter of routine. Since the RF IP is most probably in the form of VHDL language, combining it with lockouts at critical points is trivial, not difficult.

Okay, I'm lumping "RF circuits" together with "RF control circuits" -- but that doesn't alter the validity of my argument.

> It is not without cost. It may involve a turn in the silicone layout. The cost is insignificant because it does not require any change to the actual RF circuits, only to the control interfaces.

OTP is not free; It brings with it major IC design implications -- floorplanning (it's big, plus you need to isolate it from things around it), power supplies (internal or externally generated power supply?), packaging (if you go with an external supply, which also has implications for the PCB), process node constraints (is OTP even available at your process node? If not, you have to port to, or at least re-validate your actual RF circuits at, that new process), plus the actual cost of licensing it from a physical IP provider.

So, unless you designed OTP into your SoC from the outset, it's a highly non-trivial thing to add in, from design to manufacture to test to final programming for the customer application.

What most routers (and their underlying SoCs) do is store the RF parameters in the same off-chip flash they store the application code, and use software to retrieve and copy it over to the radio hardware elsewhere on the SoC. That same flash likely includes the firmware/microcode for the radio control logic. This means the whole thing is only as "secure" as the software. Locking the whole thing down is by far the simplest way to ensure the RF parameters can't be tampered with easily. It also means end-users are SOL. (Sure, you can use cryptographically signed blobs, but then you're looking at non-trivial changes to your RF control hardware/software and the joys of having to deal with US ITAR regulations. Nothing is free!)

So what I'm saying is that OTP was not some foregone conclusion, especially when there was a cheaper alternative that worked just as well to support the operational and regulatory requirements of the time.

> As for router programmability being merely a factor of quality, I beg to differ.

You seem to be conflating two completely independent things, so let me repeat myself, first quoting you for good measure:

>>I like the idea of reprogramming it so I can improve the security of the device but I do not want it to so easy that the dumbest hacker on the planet can mess with it."
> Those two properties exist on different axes; the former is more a matter of design, the latter is more a matter of quality.

The relative ease of "dumb hackers" of getting into your router has far more to do with the quality of the code in your router than anything else. Outdated software, network vulnerabilities, hard-coded backdoors, stupid passwords, and so forth making your router holier to script kiddies than swiss cheese.. has no bearing on the ability of a device owner to legitimately reflash their own code load into the device, which is a capability that has to be designed into the system in order to be feasible.

> So the next best thing is to require hardware designs that resist abuse by malicious or incompetent people.

Incidently, there's no way for the device to distinguish between malicious, incompetent, or completely-authorized-by-law [ab]users.

> The FCC is being practical when it requires restrictions on router hardware.

Perhaps, perhaps not. There is considerable disagreement on this subject from folks far more respected than you or I.

Consider: Locking down the hardware so that we can't ever possibly alter radio parameters will not even slightly improve routers' ability to resist the vagrancies of script kiddies; if anything it will make it slightly worse, as end users will have no legal way of removing or replacing the vulnerable components ourselves. (Because to do so would be "circumventing technical protection measures" as the DMCA puts it)

I for one have no faith in even Tier 1 vendors to be competent in this regard, an attitude fostered by many years of bitter experience. And Tier 2..N vendors will only be worse.

Router lockdown

Posted Feb 17, 2017 22:29 UTC (Fri) by RogerOdle (subscriber, #60791) [Link] (10 responses)

I am not just an RF engineer, I am also a Director of Engineering. I have considerable experience with ITAR and protecting IP. If an engineer of mine kept coming up with reasons not to do something like you do then he would be looking for another job. The FCC does not require that vendors have perfect solutions, but that they make reasonable efforts within accepted design practices. Stonewalling just maintains vulnerabilities that only help the criminals. The consumer would appreciate a vendor that has their interest in mind. The most common (and successful) attack on a router is by the use of the default admin password the router is shipped with (user=admin, pw=admin or password). The very simple change of locking out normal router operations until this is changed would make things better. It would force the user to actually take notice and think about the password instead of just thinking that the password is nothing more than an annoyance.

I do not particularly care if it causes router manufacturer's some of their bottom line. I do not want products from vendors that sacrifice my security for their bottom line. If badly configured routers effected only the users that set them up then that would be one thing but these routers compromise everyone and and every institution that those people interact with. I know that simple changes to router design can make them much safer than they are now. You seem to keep seeing the worst case, most expensive solutions as the only viable ones. If the current router vendors can not do better then they should step aside and let qualified professionals do the job. We have to be proactive when it comes to security, not whining defeatists. It can't be done? It can! Do it!

Router lockdown

Posted Feb 17, 2017 22:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

The username=admin,pw=admin won't allow users to access anything more than the router's UI. In theory.

Router lockdown

Posted Feb 17, 2017 23:02 UTC (Fri) by RogerOdle (subscriber, #60791) [Link]

That's the idea. The user has to put a lock (real user name and password) on the router before anything else can be done. This removes the low-hanging fruit that is the first thing that crackers look for. It is not a complete solution but as least this much should have been done long ago.

Of course you also have to prevent companies that configure it for you, like in store tech support, from using common credentials to set them for you. But let's take things one step at a time.

Router lockdown

Posted Feb 18, 2017 14:01 UTC (Sat) by pizza (subscriber, #46) [Link]

> I am not just an RF engineer, I am also a Director of Engineering.
> I do not particularly care if it causes router manufacturer's some of their bottom line.
> If an engineer of mine kept coming up with reasons not to do something like you do then he would be looking for another job.

Just saying, if you worked at a router [SoC] manufacturer, with that attitude, you'd be looking for another job before long as well.

*shrug*

Router lockdown

Posted Feb 18, 2017 19:59 UTC (Sat) by Wol (subscriber, #4433) [Link]

> I am not just an RF engineer, I am also a Director of Engineering. I have considerable experience with ITAR and protecting IP. If an engineer of mine kept coming up with reasons not to do something like you do then he would be looking for another job.

I'd be careful what you say if I were you!

That statement makes you sound like a PHB. "I don't care that the second law of thermodynamics says perpetual motion machines are impossible! If you haven't invented one by next week you're out of a job!"

I don't know whether the GP's arguments are valid, but it comes over that you don't care whether they are valid.

Cheers,
Wol

Router lockdown

Posted Feb 18, 2017 21:30 UTC (Sat) by pizza (subscriber, #46) [Link] (5 responses)

> The FCC does not require that vendors have perfect solutions, but that they make reasonable efforts within accepted design practices. Stonewalling just maintains vulnerabilities that only help the criminals.

You don't seem to comprehend that what the FCC is asking for will not result in routers becoming more resistant to script kiddies and their malfesance. If anything, it will help make the problem worse by making previously-legal activities illegal.

As you should already be well aware (both as an RF engineer and as a Director of Engineering), these days, the "RF
limitation" logic is implemented nearly entirely in software -- and has been done so for well over a decade after IC and SoC vendors realized the protocols were getting to complex to implement and validate using hardware state machines. Similarly, we've long progressed past the point of simple RF band locking -- The rules are simply too varied, complex, and interact with operational requirements to do any other way -- I shouldn't have to point out that taping out new silicon to implement new or changed rules is extremely expensive versus making a code change. Take WiFi on some of the 5GHz bands; you're allowed to transmit until you hear RADAR pulses, and rather than just locking the band outright, you're supposed to identify an alternative channel and gracefully notify your clients to switch to that channel. Similarly, if you're using a frequency hopping system (eg on the 900MHz ISM band). you can't stay on a particular frequency for more than X seconds in a Y amount of time, where X and Y depend on several variables including modulation, bandwidth, output power and your hop pattern -- And those variables can be (and often are) negotiated dynamically.

Given that the control is done in software, requiring that router makers prevent said controls from being altered requires locking down the software. Up until now, the FCC has been okay with the status quo of slightly-locked, overridable-by-relatively-clued-user systems. But that may no longer be sufficient, and it will be far easier (and most importantly, cheaper!) to just lock down the whole thing than it is to re-architect your system (including the SoC itself) so that it may be only partially locked down or sufficiently split-brained so that the RF controls are _entirely_ independent from the rest of the system.

And again, even if the system is locked down (from the FCC's perspective) it has no bearing on your complaints about Swiss cheese UIs that script kiddies can hijack and use as part of a botnet or whatnot. That doesn't require tampering with or altering _any_ of the software in the system, just downloading and executing something out of a ramdisk. So, please, stop conflating the two as they are in no way related. Furthermore, unless said kiddies muck with the actual RF stuff, it's completely outside the FCC's purview -- Instead the FTC (and possibly the FBI) typically handles that sort of thing.

(Writing wifi drivers and building router BSPs was my line of work for nearly a decade, including everything necessary for regulatory compliance, testing, and approval. I've been there, done that, and have the hair loss to show for it. These days I'm part of a team building bluetooth, 802.15.4, and other radio IP, including SoC reference designs. 75% of my time is spent interacting with RF engineers to implement proper software control of protocol-agnostic radios, attempting to find the sweet spot between performance and power consumption, while being *extremely* conservative about anything that would cause us to fail regulatory testing -- and yes, that includes keeping on top of what the FCC is getting up to. Furthermore, we're being continually hammered on to shrink our die area and external BoM. Fortunately our management, director of engineering included, is wise enough to understand that engineering is all about tradeoffs and that we have to actually compete in a market that only cares about per-unit costs and time-to-market. So, respectfully, take your I-know-your-business-better-than-you-ever-could attitude and shove it.)

Router lockdown

Posted Feb 20, 2017 17:44 UTC (Mon) by RogerOdle (subscriber, #60791) [Link] (4 responses)

The particular situation we are arguing about arises because the FCC authorized unlicensed WIFI radio to operate on the same frequency band that the FAA is using. Now they have to fix their screw up by forcing the router builders to guarantee that their routers can be altered by third parties so that they can interfere. Apparently no one, not the FAA or the router people advised the FCC to keep private frequencies away from critical aviation frequencies. The situation should not have been allowed to develop but the FCC seldom considers the long view when allocating spectrum.

But we have a problem. The script kiddies are not the problem. They do not have the expertise or tools to develop or modify RF firmware. But governments, foreign corporation, organized crime, and terrorists do. If you do not take steps to protect your designs from third-party manipulation, you put us all at risk. Consider that these agencies have the money to hire away the guy setting in the cubical next to yours and some of them may already know as much about your RF design as you do. You can not assume that they don't. What matters to them is whether or not your equipment has been installed in the critical location that gives them leverage. If your equipment is the weak link in the security chain then you will be a target for them.

I know about the details of RF design and I have said nothing against it. I want products that are safe and secure and that I can trust to work correctly not be taken over by people who want to cause harm to others. There have been many reports of router vulnerabilities in the past year leading to information leaks, denial of service attacks, DNS service corruption. If someone knows that a router can be hijacked to cause interference with critical infrastructure of the US then sooner or later, someone will do that.

The news is already out about the whether RADAR thing. The particular situation that seems to be limited to only a couple of major airport systems and they would be wise to change the equipment rather than trust compliance with the law. They shouldn't have too because the FCC should not have allowed potential interference to be possible in the first place. But they did and now we have to deal with the situation that is.

We need all of the hardware vendors to take security seriously and not assume that the enemy is some script-kiddie out to cause some minor bit of vandalism. Our enemy is highly skilled and highly financed. They are working against us 24/7 and we need everyone to work together. Balancing security and convenience isn't easy and it will cost us all in the long run but we are already paying for it with higher prices, identity theft, loss of trust in our government institutions, and in the corporations that tie everything together with networking. What can you do to help?

Router lockdown

Posted Feb 21, 2017 1:23 UTC (Tue) by zlynx (guest, #2285) [Link] (2 responses)

> The script kiddies are not the problem. They do not have the expertise or tools to develop or modify RF firmware. But governments, foreign corporation, organized crime, and terrorists do.

Those attackers are ludicrous to worry about. Those sorts don't need to attack YOUR router. They can just have someone go into the building and leave their own piece of hardware behind.

Getting access to a fully featured software defined radio stack isn't difficult, just expensive.

Router lockdown

Posted Feb 21, 2017 1:49 UTC (Tue) by anselm (subscriber, #2796) [Link]

They can just have someone go into the building and leave their own piece of hardware behind.

Presumably something with a little more oomph than a home WiFi router, if their plan is to disturb ATC radar.

I would also suggest that, given the current state of security engineering in cheap routers, whether the things can be misused to interfere with radar is probably one of the lesser worries. Using the router to spy on its users, to interfere with web page retrieval or DNS, or to participate in a DDoS attack are likely much more realistic issues, if only because they work from abroad without specific knowledge of where the router is actually located.

Router lockdown

Posted Feb 21, 2017 11:43 UTC (Tue) by pizza (subscriber, #46) [Link]

> Those attackers are ludicrous to worry about. Those sorts don't need to attack YOUR router. They can just have someone go into the building and leave their own piece of hardware behind.

As someone who has worked on equipment that meets that vague description, you are bang-on with this one.

Except they didn't even have to go into the building; just walk around nearby with a backpack.

Router lockdown

Posted Feb 21, 2017 12:06 UTC (Tue) by pizza (subscriber, #46) [Link]

> We need all of the hardware vendors to take security seriously and not assume that the enemy is some script-kiddie out to cause some minor bit of vandalism. Our enemy is highly skilled and highly financed.

Script kiddies aren't the ones who find the serious vulnerabilities; those "highly skilled" ones are responsible for that. If we're lucky, they'll sell the vulnerability to criminal enterprises where it'll eventually get packaged in a form that script kiddies can use. (Or a more organized criminal enterprise, if you prefer. It's all the same technically; only the magnitude of the effect varies) If we're unlucky, it'll go to a state-scale actor, which led to such joys as Stuxnet.

> They are working against us 24/7 and we need everyone to work together. Balancing security and convenience isn't easy and it will cost us all in the long run but we are already paying for it with higher prices, identity theft, loss of trust in our government institutions, and in the corporations that tie everything together with networking.

So who do you propose pays for this effort? And how are you going to support your argument that your employer needs to spend real time and money *now* when the "problem" is "a theoretical concern" that might not ever come to pass, and even if it does, won't actually affect the company? (Feel free to answer using your Engineer hat or your Director of Engineering hat; with the former the latter tends to be the one who says no, but with the latter it's usually your fellow execs)

> What can you do to help?

The same thing I've always done -- continue to volunteer my time and energy to develop and advocate for Free Software -- including two (now obsolete) mainlined wifi drivers. I have no power or sway over router makers beyond the ability to chose to purchase one, or not. (When I was still in that line of work, we were diligent about incorporating any published security updates to the software we included or bundled, but we had no way to force our clients to actually incorporate this stuff and push out updates to their end-users..)

But I digress -- what we should all be doing is demanding source code to the devices we purchase, both as a matter of principle, but also as a practical concern. Without the complete corresponding source code to the devices we own -- and the legal right to utilize it -- we're always going to be beholden to someone else's vision of what we should be allowed to do, and --most relevant to this conversation-- be completely reliant on their (usually awful) security practices. And yes, that includes the ability to muck with RF parameters. You can't have one freedom without the other, at least not on a technical level.

Router lockdown

Posted Feb 17, 2017 18:47 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

> Of course it's the FCCs role to police frequency allocations and that is absolutely necessary.

There are better ways to solve these sorts of problems.

Router lockdown

Posted Feb 17, 2017 20:46 UTC (Fri) by zlynx (guest, #2285) [Link]

In places without official enforcement this can lead to vigilante justice. A group of shortwave radio operators getting together and "reasoning" with someone jamming their frequencies, for example.

So not necessarily better ways.