I hope I am not the first one to find this. I am overseas visiting a friend and I got him interested in Roon. Yesterday, he set up a trial account and began scanning his library. All of this went fine and he was very happy to see that Roon could recognize the multiple zones he already has setup and identify a number of Roon Ready components on his network. So far so good. At this point, I suggested he install the Roon App on his iPad. He didn’t want to, so I grabbed my iPad, opened the app and I could connect directly to his library without entering any password. We also figured out that i had full control, so I could also delete tracks or albums in his library.
While it is unlikely that anyone would maliciously travel the world with the Roon app and delete tracks and albums from Roon users’ libraries, this does seem to be a security issue. Can you require a login to Roon first before connecting to a library using a new device? Or at least require individual devices to enter a code displayed on the Roon Core before allowing connection?
There are quite a few security guffaws with Roon, but all the home systems are pretty much just as bad. Hence why I have all my networked audio stuff in its own isolated VLAN.
If you are using a NAS for the actual raw library, and not a directly attached storage device on the Roon Core system, you can do like I do and create a read-only user on the NAS for Roon to connect with. While someone being malicious (or more likely “just having a laugh” in a home setting) can still change metadata, they can’t change or delete any of the underlying raw library files.
I’m new to Roon, myself, and I see they let you create multiple profiles. I assume this is so different family members can have their own custom playlists. But do the profiles allow a parent to lock down the library so a child can’t get at tracks marked as explicit (or entire artists, etc)? Seems like that’d be the kind of feature a non-techie would be more concerned with…
I’d be interested which ones in particular so it could be discussed and hopefully addressed accordingly.
As @ncpl pointed out above first opening your home network and then trying to introduce “security” back again on a lower level - and that’s what the OP suggested should be done - seems not too good an idea. I agree that a more thorough profile management would certainly be helpful (for instance for parental control). Network and application security will probably not really benefit from this.
So why’s running a Roon core on a home network insecure (“as bad as …”)? You suggest running it in its own VLAN - which benefit does this give compared to just secure your home network with the usual “tricks” like
using the best available built-in protection of the (WiFi) router
set and use passwords according to recommendations easily to be found “everywhere on the net” (1234myWiFi)
not allowing “everybody” to access the home network and if ones has to provide access to guests configure a guest network,
allowing internet access only to devices which really need it to function properly
and maybe a few other things I can’t think of at the moment? We are talking about a consumer level use case.
PS: If there’d be something like a turnkey solution for accessing the internet in a secure and safe way that would be something … but there’s not (even so most “something with internet” companies targeting consumers pretend it/IT won’t hurt you).
I tried to interest a Roon developer who was at local (Seattle) event some months back. No success as far as I could tell, in line with responses I’ve seen here. Roon as a development organization doesn’t seem to accord priority to this security issue.
OK. I’ve been reading through the thread you mentioned (and I’ve read a few other discussions related to security aspects of Roon) and I’m still not sure if there’s something which should be acted upon immediately = qualifies for a CVE #.
If Roon would provide remote network access to the Core it would definitely need to provide secure access and authentication measures. Since Roon works on a remote feature let’s assume this is / will be part of that.
But for now Roon is a local network device even so it uses Internet connectivity for metadata related things and license tracking. So my guess is you refer to probable flaws within the current implementation and since Roon communicates somehow with the outside it may be exploitable due to flaws in the Roon software - no matter if programmed by Roon or third parties as long as it gets installed from a package delivered by Roon. This is a valid concern and I share this concern. What I don’t understand is how a fully fledged user management would protect against this threat. Maybe I miss something but how would an application sandbox itself in an environment it gets brought into and how would I trust its claim that it will do no harm?
You need to set up security measures for everything you put into your network sandboxing things depending on the trust level you give each of those things. That’s also why I’ve asked how maybe VLANing audio stuff can help. Because: unfortunately you’ve to do most of the secure-your-network-stuff “by hand”. Like thinking about and acting on how data is shared. If for example you’re worried about Roon creating directories on your storage remember you gave Roon access to it…
I was a bit surprised that Roon even has a “Delete Track” or “Delete Album” feature. I figured it accessed the various sound files read-only, and only messed with its own database. Be nice to at least have the option of disabling that functionality st set-up.
Problem is, Roon doesn’t even appear to perform a digital signature check when auto-updating its packages. If their S3 bucket gets compromised (and this is a lot more common than you might think – many ways for a bad actor to take over an AWS account in a matter of minutes when the owner doesn’t know or take the time to properly secure it further than what AWS gives them “out of the box”), then a malicious entity could easily deploy malware to every Roon device in the world. And since Roon wants to run as root for the convenience of mounting network shares, they now can do a LOT of damage. This alone is why you should NEVER run Roon on anything but dedicated devices, and give it non-shared, read-only accounts to your NAS (and only to the music library share, not your entire NAS where the bad actor could then get at your more sensitive files like tax returns, etc). Running on its own device, they can still use that as a launching point to attack other machines in your home once they pop the Roon device, but you’re going to make them work for it.
And some will say I’m being overly paranoid for a home network. And maybe I am. But then my day job is cybersecurity at the company I work for, and I come from a background of programming, systems engineering and network engineering. I can’t NOT be paranoid about cybersecurity, especially when so many companies don’t even think about it and produce devices we have running in our homes. This is why I isolate devices to separate VLANs; I can firewall them off into their own areas so they can get to the Internet services they need (like Roon’s need for license checks and metadata retrieval), but if they get popped, they can’t get at any of my “real” systems.
Thank you for elaborating on the issues you see. If I got it right then
The Roon network – and not my home – infrastructure should be set up and run according to best practices for cloud service usage. As an end user I’ve no real way to check this and am bound to hope the services I use do enough to not put me in danger (or I just don’t care). Maybe some kind of certification involving external auditing could raise the trust level but then this is always just a snapshot in time and doesn’t guarantee anything. Still it might be helpful.
The software distribution mechanism for Roon Core (and possibly for the Windows and macOS GUI+Core versions) may has room for improvement. That’s something which would need comment from the Roon team. And one could argue that the necessity of it depends on how well the infrastructure mentioned in point 1 is run - but maybe distributing unsigned software packages is not state of the art anymore, if that’s the case with Roon right now. I take your word for it.
Intro: Convenience is a killer feature. We have to accept that - the entire Online Smart Isn’t IT Great & Simple promise is just that: a promise. So some compromise has to be made.(*)
If the Roon Core (and only this part of Roon) needs to run as root for the turn-key-effect it wants to provide then some warning may be needed when the Core notices it gets offered deeper integration into a home network - like a notice what mounting a network share incorporates (“Your Core can now access and maybe alter and delete everything on that share. If you let it. OK?”). The user then may/will decide to just ignore the warning (a privacy notice - cool, I’ll accept it) or could use the recommended way for audio file storage = directly attached. Running as root on the Core does not necessarily mean root privileges on all other devices on my network though, does it?
The Core exposes the entire storage it has mounted for everybody on the respective home network. If the user was careless enough to let Roon mount anything else than audio data everybody on the network is the Core’s guest and sees what’s in Data\Storage - that’s how it is. Also, every guest can add or delete stuff there. But it’s the problem of the user. Is it a security issue? I tend to think it’s not but may be wrong. It definitely isn’t nice when one needs something like parental control for the audio library. But that’s not part of the current feature set anyway.
Dividing a home network in virtual lan segments is beyond most consumer manageable affairs. For most or so it seems it’s already too much to ask to use a guest WLAN for visitors despite the fact that current routers will provide such a feature easily. And while I understand your concerns it still sounds like over-engineering the home network. There are other and easier to maintain ways to keep confidential private data from berserk IoT or networked audio devices. Shared storage should only be used for data one wants to share, right?
Security is important and I agree one can’t be paranoid enough. The question is how a practical approach for the average or at least the recommended Roon usage scenario looks like. If Roon doesn’t think of it being unnecessary a KB article on how to set up a decently secure and safe home audio network with Roon in simple steps might be a nice thing.
(*) Do they say “your network was compromised” because of that?
At the very least Roon needs password control on profiles and the ability to create read and play only profiles. The current situation where everyone has open slather to everything is very insecure and puts the entire metadata library and source files at risk.
I am not an expert in computers or computer security, but it seems to me that you do need to access the local network to login and see Roon. If someone can hack your local network remotely, Roon database and music files should be the least of your concern.
Really, that shouldn’t be the reason for the implementation of user management features into Roon (there are good reasons though).
A guest network is the first line of defence here, believe us.
Else it’s like keeping the door to your house always wide open, being away or not. It’s possible but you shouldn’t ask the cabinetmakers to ensure nothing of worth disappears while you aren’t looking.
I think the average person is more likely to instate security through a password to get into Roon than through network settings (eg, guest network). Roon should be making it easy (as possible), not hard (as possible).
I’m not saying the password approach is state of the art, just easy to understand and likely to cover some of the issues. (Of course, making Roon demand a password to use it has to be an opt-in, since it is a change.)