How does ROCK protect against someone on the network replacing ffmpeg with a malicious version?
I have to be careful about network security because of both my work and my wife’s work. All my audio (including ROCK) and IoT stuff is on a carefully isolated VLAN that trusted devices can reach into but not the reverse. The assumption being that IoT devices are prone to compromise. The problem is that I want to mount music files from my fileserver and that means a pinhole from ROCK to my fileserver.
If there are no such protections, I suppose I can set up a regular job to push my music files to the room core from the fileserver. But it’s another thing that can break. I chose ROCK over running Roon in a container to avoid this kind of fragility.
Not sure about your initial question but, you could just add a drive to the Rock (not sure what you are running your Rock on, is it a NUC with space for a storage drive?) and let Roon get the files from it? This way you would not have to open a hole to your fileserver for the music files and would only use the file server as backup.
As anyone on the network can place the ffmpeg file on the ROCK in the first place, it seems obvious that there are no special protections against replacing it. Roon’s architecture assumes that the local network is trusted, as far as I can tell.
Based on the competency you have to ask this question in the first place - and the sophistication of your network partitioning strategy - I think you already know the answer to the question. You shouldn’t trust ffmpeg or, more generally, Roon ROCK. I don’t mean any disrespect at all to the folks who develop Roon - Roon just does not claim certification, audit, hardening, etc. which is absolutely fine for a consumer audio product. It should be categorized and isolated with the rest of your audio and IoT gear.
One way or another, I think you need to get a copy of your music onto the untrustworthy side of your network. A drive, a one-way sync job, or some other strategy seems like the way to go.
I agree that it’s another complex thing that can break but when is security ever cheap or easy?
Welcome again to you and your wife - it’s a great product and a (generally) pretty supportive community.
I really didn’t want to come in and have my first post sound like I was scolding Roon for their security practices. It would be nice if you could add a password to the smb shares and admin screen, but I don’t blame Roon for not prioritizing this. It’s not the level of concern it would be if Roon was smarthub that could control cameras, locks, or alarms. That said, it would be good if there wasn’t a trivial remote execution exploit.
I was hoping that they maintained a table of checksums for approved ffmpeg executables. Since posting, I remembere it’s connected to a managed switch that has port level ACLs.
It doesn’t. Full stop, it does not. The ROCK share uses guest credentials and gives full R/W access to the whole system. The best you can do is firewall ROCK to block SMB. You’d need to plug ROCK into a “layer 4” switch to do that though.
I don’t know what file server you have but if you’ve got multiple ethernet ports on it you could use one on the IoT network and firewall it to only the ROCK IP. Depends on how much you trust the file server to be on that network though.
But, here’s what I do and its a cheap option while also providing ROCK better performance…
I have an XTB (size doesn’t matter) USB drive plugged directly into ROCK machine. I have a computer with 2 ethernet ports (one is a cheap USB hub style). One port is “secure” and other is on the “IoT network”. When I want to move files onto ROCK I enable the “IoT network” interface, move my files, and then disable it again. Or you could unplug it completely. For the convenience the quick attach to the unsafe network works fine for me. This is a ~$120 solution for an inexpensive USB drive and cheap usb ethernet adapter.
If you’re concerned about security this is the right answer. With great security comes great inconvenience
@Rose if you don’t trust the IoT guys then isolate them from the roon network that at least rules them out too.
The other way is to regularly (every off play time or maybe nightly) update the FFMPEG from your music files server. Or a script that checksums it and replaces it accordingly.
I didn’t interpret your post as scolding. Questions like the one you asked usually lead to someone, somewhere, either learning something, having an insight, or starting a dialogue.
The threat you identified is legitimate. A bad actor who penetrates the untrustworthy partition of your network can trivially inject an executable onto the trustworthy side of your network. The first time that executable is given the opportunity - which might be the first time a track is played or analyzed - that executable will have the opportunity to do whatever it wants, including dropping other executables which might be long-lived and difficult to detect.
Most of us probably operate with this vulnerability but without the partitioning you have in place. In that context, there is no “new” threat for us because we are already vulnerable to the bad actors in the first place. And those bad actors have much easier exploits at their disposal and no need to mess around with spoofed versions of ffmpeg.
I agree with you that things like checking checksums can be a component of hardening a system. Signing is even better but is challenging when you don’t control, and can’t distribute, a binary. But the problem is deeper because you need a transitive trust chain that is hardened at every stage. Plus operational security. And things like a password protecting an SMB share aren’t helpful unless anti-hammering is in place because without it, you just have a bad actor slowly spraying passwords without anyone knowing.
I don’t think it would necessarily be a bad idea for Roon to put a password on top of their SMB shares or their web interface. It would, though, create new support vectors for them because people will forget their passwords or struggle to get authentication to work. That’s a slippery slope of building more features, like password recovery, multi-factor auth, etc. without necessarily truly impacting the security model. I bias towards thinking that if a thing isn’t going to be secure, it shouldn’t act like it’s secure. There’s actually, in my opinion, a benefit of Roon doing what they’re doing which is not acting like the system is secure. Now you know it’s not secure and you can make informed choices. I think that’s better for them than implying that the system is secure because of a password input box and then having some highly security minded user - possibly you - ask all of the increasingly complicated questions including “how do you vet your employees? how is your source depot locked and audited? what is your internal audit model? can you provide evidence of penetration testing? how do you know that your tool chain is secure?” and all of the test of it.
If I were a bad guy using the attack vector we’re discussing, I would temporarily rename the “good” version of ffmpeg, and drop a “bad” version. My “bad” version would drop additional binaries on its first run. The first thing these additional binaries would do would be to delete the bad ffmpeg and rename the original back to its original name. There would be a very short window during which any script attempting to check for intrusion would be able to detect that anything is wrong. Just saying.
@Rose - Your next assignment, should you choose to accept it, is to solve this issue one way or another and then come join some of the other fun conversations around here!
