24

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?

16
  • 4
    Legal is not the same as morally correct or "not immoral". So while what they are doing is completely legal, it is arguably immoral. You like your old things, they serve you well, why should you have to buy new ones and pay the company extra money? In short, they can't be forced by any current law to "do the right thing".
    – jo1storm
    Jul 4 at 7:41
  • 2
    You say that Sonos used OSS modules. Which ones? And more importantly: what licences do those OSS modules use? This might be the elephant in the room, but: instead of focussing on "the right to repair" laws, I think it's more likely that you can order them to release their source code because the license they used forces them to do so. Wouldn't be the first time this happens to a large company.
    – Opifex
    Jul 4 at 10:22
  • 3
    @Opifex The main affected module is the Linux kernel, which is under the GNU GPLv2. However, that version does not restrict "tivoization" (making it impossible to replace the firmware in a device with your own version). The GPLv3 is the first version to tackle that issue.
    – TooTea
    Jul 4 at 11:13
  • 2
    @FluidCode: Perhaps it should have been obvious to Sonos that the software would require periodic updates to remain "functional" - software that (for example) subjects you to risk of electrocution is not really "functional" - is it? The concern is that these NTLM v1 & SMB v1 vulnerabilities are the basis for ransom-ware attacks. The "music library" that Sonos relies upon is housed in a network appliance (NAS or equivalent), and the only means Sonos has to connect is via NTLM v1 & SMB v1.
    – Seamus
    Jul 4 at 19:49
  • 4
    If we as a society flog this issue hard enough, we are going to come to a sad realization. That thing isn't a bicycle. It's an amalgam of hardware, software and services, with the last 2 defining it... and without at least 2 of those, it's not a product at all. And the company is allowed to temporarily lease you both the software and the services until a time of their choosing (ask Adobe or Microsoft). As such you have no rights to the amalgam as-bought, you only have rights to the bare metal of the hardware. And, you knew this going in. Jul 5 at 0:43

3 Answers 3

16

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.

12
  • "The Right to Repair generally talks about hardware, not firmware or software". "Generally Talks" would seem to be some distance from "Specifically Excludes". I get your point re "original functionality", but original functionality didn't include a very real risk of becoming a victim of ransom-ware - as using NTLM v1 & SMB v1 - does today. Hardware-only products get recalled for safety issues... is this so different? Good catch on the document you linked from Sonos' website!! I couldn't find any others, but this is not a complete list; e.g. no mention of NTLM or SMB.
    – Seamus
    Jul 4 at 19:24
  • @Seamus All the channels I've watched speaking to RTR deal only with user-serviceable/repairable hardware, such as Louis Rossman (excellent stuff to watch). I believe only the automotive industry is required by law to provide firmware updates, almost everyone else gets a free pass there. Some places may have Consumer Protection Laws that might meet the criteria (selling of a defective product), but RTR simply isn't the path for that.
    – phyrfox
    Jul 4 at 19:45
  • @Seamus I would love to find a RTR counterexample to that, though, as I do agree that "generally talks about" is not as strong is "specifically prohibits" or "specifically enforces." I'm pretty sure there's a lot of powerful lobbying that goes on to protect IP even over the rights for users to have their devices not leak all their data. And it happens all the time. Baby monitors, Ring doorbells, whatever. We're supposed to "trust" the firmware, and if it's broken, tough luck for us consumers.
    – phyrfox
    Jul 4 at 19:47
  • 1
    @Seamus Yes, "hack" has several definitions. You're in a situation where you need a firmware update, so either: a) Sonos can give you an update, or b) you can hack the firmware yourself. The latter is illegal in DMCA; this law effectively says you do not own your own hardware. The intent was to prevent piracy via circumventing DRM, but manufacturers have used this for decades to deny RTR. The new laws would require either Sonos providing source code and instructions, or legal permission for you to hack it in yourself.
    – phyrfox
    Jul 5 at 2:19
  • 1
    Unfortunately, I'm not aware of any case law that establishes this would work -- It works and there have been several case laws in the US. For example, this one: en.wikipedia.org/wiki/…
    – slebetman
    Jul 5 at 8:06
10

No

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

2
  • 12
    Not every software bug is a design defect, IMHO.
    – PMF
    Jul 4 at 6:02
  • 3
    Also, I'm not convinced these are software bugs, exactly. Software limitations might be a better description of the issue. This is software running on hardware that is, in some cases, 13 years old. As someone who works on older hardware and software, I believe them when they say they can't fix certain issues in any reasonable manner. Jul 4 at 15:01
5

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.

5
  • "If the client was using samba, ..." Please read 1st sentence, 5th paragraph of the OPQ: "The security flaw (NTLM v1 & SMB v1) is in open-source software modules that Sonos elected to incorporate into their firmware."
    – Seamus
    Jul 7 at 0:16
  • "outdated protocol has some flaws. Undesirable, for sure, but it's not critical.". That reminds me of something my Father said a few years ago: "The only minor surgery is surgery they perform on someone else". Honestly, I don't know why you bothered to post this.
    – Seamus
    Jul 7 at 0:19
  • 1
    He bothered to post this because he’s correct, as far as I can tell from the question and my research at the time I looked into this. The serious security flaws aren’t in Samba, the open source software; they’re in the Microsoft protocol and the Microsoft Windows server. The fix, such as it is, is to stop using smb 1 and ntlm 1, and start using smb 2. This is actually a pretty big change, analogous to fixing a problem with a train by changing the rail gauge. Your quote from your father applies to software upgrades, too. Jul 21 at 12:05
  • Thanks @KevinMcKenzie. Seamus: my point was precisely that you are not measuring properly the severity of this issue, you are complaining that the toilet lock, installed in your home where you live alone, could be opened from the outside with some effort. I reaffirm: it's bad, but not critical. And I mentioned a number of mitigating measures you could apply.
    – Ángel
    Jul 30 at 1:49
  • @Seamus I have red it. I even went to the discussion thread, and found it is using the implementation of SMB protocol from the Linux kernel (GPLv2), not the one from the Samba project (GPLv3). And their different GPL versions do matter here. So i don't think there's anything wrong in the answer as stated, although I have slightly edited it trying to clarify this point.
    – Ángel
    Jul 30 at 1:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.