Can "Right to Repair" laws (or other laws) require a company to open source their proprietary firmware?

Question

AFAIK, there are no prohibitions here that require omission of specifics, so I will be specific.

Over the years, I have invested a fair sum of money on products made by a company called Sonos. Fairly recently (2018 IIRC), Sonos "went public"; this is approximately the same time my issues with them commenced. Wikipedia REF on Sonos.

My Sonos sound system began to experience various malfunctions - some were resolved by Sonos tech support, some were not. Various rumors and statements were circulated regarding limited support for Sonos' "legacy" products (ALL of my Sonos equipment was purchased prior to 2018). However, the situation is more serious than Sonos has admitted. Recently, I became aware of a Sonos product flaw that is potentially far more serious than failure to play music - a computer security flaw that significantly increases my risk exposure. An update to the firmware is needed to effect a repair, and eliminate the security flaw.

Repairing this flaw will require a repair to the system firmware - an update that Sonos has chosen not to make available. Instead, Sonos' "solution" is to offer a small discount on the price of their new systems, and commit the old systems to the landfill.

The security flaw (NTLM v1 & SMB v1) is in open-source software modules that Sonos elected to incorporate into their firmware. The flaws in the open source software were recognized and patched by its open source authors years ago, and are readily available. However, repair of the firmware requires that Sonos provide documentation on how to integrate the patched software into the binary blob of firmware that Sonos claims is proprietary. For those interested, here's a link to an online discussion of this issue at Sonos' website in which I participated.

Despite a claim made in this discussion, Sonos has not released the source code, nor any details that would allow one to repair the network security defect they have ignored. Rather, Sonos has simply claimed that it "is not possible" to remedy this defect. If you read through the discussion, it seems apparent to me that most of the other participants in the discussion (customers, Sonos employees?) accept that claim, and are happy to continue doing business with Sonos.

I'm not quite ready to admit defeat. I've read a wee bit about the "Right to Repair" laws being enacted in some states REF 1, and it seems the Feds are pursuing enforcement also REF 2.

My question is whether or not this "Sonos Situation" is covered by these "Right to Repair" laws - or are there other laws that may be a better "fit" for these circumstances? Or - am I simply an unfortunate customer of a company that is pursuing its business interests in an entirely legal fashion, and has no liabilities here?

Answer 1

The Right to Repair generally talks about hardware, not firmware or software, and only to the point of restoring "original" functionality. For example, RTR would make it prohibited to have Apple require that they fix your phone battery for hundreds of dollars and make it impossible for you, or a third-party shop, to do the repair instead. In Sonos case, RTR would imply that if your speaker blew a fuse (or capacitor, etc), you should have the right to fix that yourself, and they should provide you with reasonable instructions and hardware to do so.

That said, if you look at the Sonos OSS references, at least a few of the licenses suggest that you can't release derivatives under more restrictive languages. Unfortunately, I'm not aware of any case law that establishes this would work, and it would be really expensive to try and find out. There's also the problem of Intellectual Property and Copyright that they could try to argue as reasons why they can't release the proprietary bits that make their hardware run. Any other options would be, unfortunately, illegal, in part because of the DMCA.

---

Edit: Looking further into this, I found that there is H.R.4006 - Fair Repair Act, which, if passed, would require manufacturers of some hardware to offer diagnostic tools and public copies of firmware. In addition, there are also actions being taken by iFixit at the Copyright Office to allow an exception to DMCA violations for the purposes of patching firmware. Also, the President of the United States issued an Executive Order that, among other things, instructs the FTC to set rules against anticompetitive repair policies.

Much of this has moved forward in just the last year, so it's relatively new to me, but it sounds like an even stronger indicator that Sonos is probably not going to have that defense much longer, unless they totally abandon their old hardware, in which case, it may become legal to hack your own firmware.

Answer 2

No

The right to repair proposals are not for a right to fix design choices or design defects.

Answer 3

First, it may be that it is indeed not possible to fix it. E.g. if the affected firmware was stored in ROM (or fused so it cannot be updated).

‎

Second, I don't think this is that bad. This is an old system using an outdated protocol. It just happens that such outdated protocol has some flaws. Undesirable, for sure, but it's not critical.

Please note that the main issue lies on the insecure implementations present in Windows. A Sonos speaking to a Synology probably don't involve insecure code. They won't be vulnerable to EternalBlue. The issue of an attacker cracking the hashes does exist, but it can be overcome by using a long, machine-generated random password. In my opinion the main issue here is that it requires exposing the downgraded version to all clients, not just the Sonos. (See the negative answer to How can I enable Samba 1 authentication for a single share?)

However, there are a number of workarounds you could still use:

• Connect the Sonos and NAS through an isolated network with no other clients
• Use a separate NAS just for the Sonos system
• Use a different interface (with NTLMv1 enabled) for the Sonos
• Proxy the connection through a system that translates them (this was also suggested on the forum thread)
• Use a different protocol (e.g. share the music using NFS instead of SMB)
• Depending on the type of access provided by the Sonos system, it may be possible to connect to the server using SMBv2 implemented in userland instead of using the kernel support.

Nonetheless, the NAS must not be exposed to the internet. Not even if it is not using NTLMv1. Not even if your grandma need to access it to view your cat photos. A NAS belongs to the internal network, not to the internet or a DMZ. The problem #1 is to expose it to begin with. It might be done securely (depending on the NAS an how updated that one happens to be), but most people won't be able to do that, just don't try. If anyone needs to connect to the NAS from the outside, they should VPN in.

‎

Third, I think this should be approached from a licensing point of view rather than from a 'Right to Repair' one. If the client was using samba, this would be much clearer as GPL 3 "anti-tivoization clauses" would clearly state your right to change the open source part (which is the one you wanted to modify). But instead the issue is in the Linux kernel, which is GPL 2, where there is no clear requisite that they should provide you the tools to burn your own firmware. Still, they must provide the source code for the Linux kernel they used. It's possible that wouldn't allow you to patch support for newer SMB, though. Plus obviously, Sonos would have no responsibility if you broke it trying to apply an unsupported update.