MuseHub runs with excessive privileges on Linux and MacOS, posing a serious security threat
Answered
On the MuseScore forums there is broad concern over MuseHub's use of root-owned background services, in any case on MacOS and Linux. (The Windows situation is unknown to me.)
Brief summary of the situation in MacOS (that on Linux is similar, although the details differ):
Upon installation, MuseHub installs a helper application that runs as root. It sits in /Library/PrivilegedHelperTools and is called com.muse.museservice.
This service runs permanently and only stops when MuseHub is uninstalled. It opens bittorrent ports. Its apparent functions are:
- To run as bittorrent host for downloading software and content such as MuseScore and MuseSounds
- To install downloaded items without user intervention.
Running a root-privileged process without need is considered bad practice and in fact presents an unknown danger to the integrity and privacy of the system. This danger is even greater if the process has ports open to the outside.
For the above mentioned purposes there is no need for root privileges, except perhaps to avoid asking the user for permission when a new version of the software or other content is ready to be installed. That would be no big deal, and in fact is the preferred way according to most who have spoken out on the forums.
Please realize that all MuseHub users are now exposed to the danger of having their computers compromised or even hijacked, and please fix the issue on the shortest possible term.
Following are links to the two Issues submitted to the MuseScore issue tracker. Many other forum topics deal with the problem, all with the same conclusion: this is dangerous and cannot continue.
Sorry if I am the bringer of bad news. No bad intentions here. I hope this will quickly become a thing of the past, and all can enjoy the great features of MuseHub without worry. Thank you.
-
Official comment
Hi guys,
I can see some concerns here, so I wanted to jump in and reassure you that Muse Hub poses no security threat. Indeed, it installs a "privileged helper tool" (or background service), which is Apple's recommended security model for escalating privileges safely.
This is more a developer discussion than a support discussion, but it may be interesting to know the decisions behind going with a helper.
Muse Hub performs some system-level tasks that require admin-level privileges: installing applications, updating applications, removing applications, creating files, deleting files, moving files (i.e sound libraries, sound effects, VST3 effects etc). It can also update itself, and uninstall itself. These operations need to be performed responsibly, require admin-privileges to complete reliably, and be done in as secure an environment as possible.
There's a few reasons for pushing "responsible" operations into a helper: mostly, they revolve around the concept of giving the least privileges possible to the majority of your code.
I'll write from the perspective of macOS; but the same concepts apply for modern Windows Apps. I'll get to Linux last, because we'll be making some changes there, but for now it works in the same way because the Linux Hub is generally the same core code as the Windows Hub, minus some features.
1. Using a helper moves any operations that require escalated privileges out of the "UI" code - i.e all the graphics, animation, high level database connection stuff etc, and into a notarised, code-signed binary that runs alongside the main app. This blackbox can't be changed; if it's modified by any third party, it won't match the code signature and thus won't run. This helper can only be called in specific ways from the UI code itself. Why can't all these operations be done from UI code? Because UI code is inherently easier to attack. To help against this, the UI is "sandboxed" (run inside its own virtual container). A side effect of of this is that the app now requires those special permissions to do almost anything outside of its own container/sandbox. This causes a few UX quirks, but ultimately it's the safest way to do it.
2. macOS has special rules for privileged helper tools; it manages them quite differently to a normal app life-cycle, which can be tricky to manage as developers, but is ultimately more secure and efficient than trying to do everything from UI code alone. You'll notice from e.g Activity Monitor or Services Monitor there are hundreds of these helpers doing all sorts of things across the OS.
3. Muse Hub might be installed on a "Guest" account that may not have the required read/write access or privileges. The administrator can then decide whether or not they wish Muse Hub to work on this account, without having to supply their credentials for every operation.
4. Downloads can be made significantly more reliable if they're done from background code. It allows download operations to be started, maintained, restarted and completed even if the UI is interrupted or blocked for some reason. For example, it can also download updates in the background if you have the "automatically keep up to date" options checked, and it also makes self-updating and uninstalling possible.
There are a few other technical benefits as well as user experience benefits of pushing all this responsibility to a helper tool; the downside being that they are notoriously difficult to work with as developers - because they are subject to very strict OS management (rightly so).
On Windows, things are pretty much the same story. You have probably experienced many other applications using a helper tool to perform their "responsible" tasks (e.g ScreenFlow for recording your screen, Dropbox for writing to your disk, or any similar "manager" app like Avid Link, Splice, Adobe Creative Cloud, Native Access, Steinberg Download Assistant etc).
You can uninstall the Hub and the helper/service by using the uninstall button inside the Hub's settings page (macOS), or using the Apps & Features page in Windows Settings (or right-clicking the Hub icon in the system tray and choosing Uninstall). This will stop the service and uninstall everything Hub-related, except for your already-installed content.
All that said, whilst the privileged helper + sandboxed UI approach is the Apple/MSFT recommended way to do those kinds of responsible operations, it is not the only way. We are actively investigating other methods that allow us to deliver the current and planned feature set of the Hub in a safe and secure way, without the need for a helper. If a suitable and secure method shows up, and it is mutually beneficial to move to that method, then we will do.
So, what about Linux? Well, the same general concepts apply and the Linux version of the Hub shares some code with the Windows version, which is why the same overall approach has been used for v1.
However, we have decided that the Linux version of the Hub will not be getting the features of the macOS and Windows Hub (application install/management, studio effects, drag n' drop sounds, tutorials and example projects etc). The Linux Hub will remain what it is now - a relatively straightforward software manager for Muse Sounds, and the sampler engine that powers them. As such, we'll likely be removing the helper/background service entirely from the Linux version of the Hub quite soon. Instead, you may see more prompts for a password each time it needs to perform an system-level task (like updating itself, or the sampler). This simpler, more stripped-back experience for Linux should also allow us to more easily compile it for more flavours of Linux.
Whilst the above deals with the most secure way for us to safely offer the current and future planned features of Muse Hub, you may actually be asking: "but what's preventing the Hub from deliberately doing malicious things!?" The Hub is developed by a well-regarded professional team, and the application is signed by certificates from trusted authorities. The Hub itself is designed and built for one purpose: to bring complementary creative software and content together in a fast and easy-to-use experience.
Whilst it's "v1" software (we know!), we sincerely hope the Hub has helped many users discover, download and enjoy some of the new content experiences it has made possible.
-
AppArmor or SELinux could restrict the privileges of the helper service to minimize any possible risks from running it as root, but I agree that it is bad practice to run as root unless it's really needed. The main question is whether it's really necessary in this case, e.g. for tweaking the network layer in some way, like opening firewall ports. But this could and should be done by install scripts (ideally within a distro-blessed package), rather than at run-time.
See also https://musehub.zendesk.com/hc/en-gb/community/posts/8536393474461-Muse-Hub-any-plans-of-making-the-source-code-available- - if distros could package it then I'm pretty sure this problem would get solved extremely quickly.
0 -
As I noted in another ticket (I guess mine is redundant) the muse-hub also doesn't check return codes properly. There are many cases where file permissions may not be allowed to a root user ( rootsquashed nfs mount, for example ). When the muse-hub runs into this, it crashes, implying that it assumes it'll have permission by running as root. This seems like a poor programming shortcut... ( No ego in that, I've made that kinda mistake too.. it's easy to think that running as root will guarantee access , but it should get fixed.)
2 -
Any updates here? This is a serious security vulnerability and there hasn't been any response for 2 weeks.
1 -
That is disappointing indeed, and I find it difficult to understand why such concerns are not being addressed.
On the MuseScore forum there is a topic to assemble all possible information on this issue, for all three platforms Windows, MacOS and Linux: https://musescore.org/en/node/341517. It is to be hoped that such information will move MuseHub to pay attention.
0 -
Thanks David for your post.
Your point of view is clear, but it is mostly beside the point. Please refer to the MuseScore topic I mentioned for arguments.
0 -
I do have persisting concerns about Muse Hub, but won't voice them right now. I do have a quick question, you mentioned that "This is more a developer discussion than a support discussion, but it may be interesting to know the decisions behind going with a helper." Just curious if there is a proper place to have said developer discussion other than the zendesk.
1 -
It's good to hear that you will (going forward, anyway) be using password requests for *temporarily* escalating privileges in Linux, as that's the appropriate method for root access on Linux systems. User-run software should never be allowed full root access on a Linux system without password authorization at runtime, especially since the Linux version just downloads sounds, which could easily be stored and used at the user level without root access, and only require root access (with password authorization) if the user/administrator decides to install the sounds in a root-level location for system-wide access (for multiple users). I think the majority of users should only need user-level access, with the exception of educational institutions. Even if the Linux version installed application software like the Windows/Mac version does, it should only ever need root access on a temporary basis (so only a limited time, and with password authorization). This is how all Linux package installers/managers function, and it is concerning that the MuseHub service uses root privileges constantly. I would think even on Windows/Mac, temporary root access during software install only would be preferable to constant root access.
1 -
Hi David,
I am coming over from the MuseScore forum where I started a thread titled "MuseHub - What does it do and can it really cause harm? In search of facts." (https://musescore.org/en/node/341517)
The purpose of this thread is, and I quote:
"This topic is an invitation to share information on MuseHub and how it works. The aim is to assess whether it is safe to use, and to take action should there be cause for concern. (...) When we have a clear picture we can make a well argued proposal to MuseHub. Or lay the issue to rest once and for all."
I was encouraged to start this by Marc Sabatella, a senior MuseScore official whom you probably know. He himself is convinced that MuseHub is harmless, yet supports communicating concerns from the community to you if that is felt necessary.
This thread has been running for some time now, and so far we have only heard from MuseScore users. I am happy to see that now, in your post, we see the MuseHub position. What I hope is that now through discussion we a can reach a shared understanding; the common goal being to establish that this beautiful app is indeed safe to use. Or to make it so, should there appear to be some problem remaining. I do hope you are willing to take part in this.
Let me summarize my understanding of the main points of your position:
- On MacOS, MuseHub is safe because it uses Apple's recommended architecture for safely delegating elevated privileges to privileged helper tools in case an application needs them. There is nothing special about MuseHub in this, helper tools are running all over the OS doing sensitive tasks.
- Whilst you are following Apple's recommendations for helper processes, you are also investigating ways to "deliver the current and planned feature set of the Hub in a safe and secure way, without the need for a helper".
- On Windows, things are similar and other programs also use helper tools for sensitive tasks - although it seems there is not a preferred mechanism for this like Apple has.
- Added benefits are: On Guest accounts it relieves the administrator from having to enter their credentials, and downloading is more reliable if done with a helper tool.
- On Linux, things are apparently more complex on the implementation side, and the choice will likely be made to let go of the advanced features such as "application install/management, studio effects, drag n' drop sounds, tutorials and example projects etc." Also the helper with its advanced privileges will likely be dropped, and consequently the user will be asked from time to time to enter their password. Something that Mac and Windows users will not have to do.
- The team can be trusted because they are well regarded and professional, and in addition the app is notarized and signed by certificates from trusted authorities.
Have I summarized your position correctly? Would you be willing to discuss it further with the aim to come to a shared understanding and increased trust in MuseHub?
Thanks!
0 -
Hi Jim,
Thanks for writing. Sure, that about sums it up -- and I'm happy to discuss any concerns you have...
From a general trust perspective, I suppose some background into the Hub's conception might help to alleviate concerns, though, as with any product, at some point you just have to feel confident enough in the product and team behind it to use it.
The goal and remit for Hub is super simple: enable a large audience to experience high-end content, free, and easily. The way it's designed and built - inside and out - is in service of that goal.
The Hub is v1, and we're working to improve many aspects of it over time. Of course, it was also all designed to be entirely optional: it's cool, but you don't need the Hub - or anything in it - to actually use e.g MuseScore or Audacity etc. We hope it enhances these products, but it's your choice whether to use the Hub or not! In that respect, it's essentially the same as any of other commercial "plugin" that provides content and enhances a host; e.g Native Access or UA Connect etc.
As you know, the Hub is not a community project. But, the overall way it works is not particularly a secret. Please do ask any further questions: I'll do my best to answer them!
0 -
Hi David,
thanks for replying, and for your willingness to discuss. I hope, and think, that with an open discussion with good will on both sides it will be possible to resolve the matter to the satisfaction of the great majority of those concerned.
I agree with you in that in the end it is up to the user to determine if they are confident enough to allow the software on their computer. Such a rational decision must be based on a perceived balance between residual risk and benefits. Absolute certainty seldom exists.
On the risk side most prominent, in the view of many, is the fact that the helper runs with root permissions, because of the serious consequences that would have if some fault would come to the surface. That risk in in their eyes even greater because it has ports open to the Internet.
This risk can of course be mitigated by special measures. You have given some arguments why you feel the risk is not great - some technical, some organizational. Yet some risk inevitably remains.
The benefit as I see it, is that the user never has to enter an admin password. The Hub offers a seamless service in maintaining the software and content the user has subscribed to.
For many, the risk outweighs the benefit.
If possible, I would like to avoid a complicated discussion of the remaining risk in the light of the technical and organizational measures you have taken. That would be interesting, but maybe it is not necessary.
At this point for me the question to you would therefore be: In the view of the inevitable residual risk of the helper becoming compromised and the serious consequences that could have, and in view of the concerns many have, would you be willing to reconsider asking for those highly elevated privileges - at the price of asking the user from time to time to enter an admin password?
I realize that would bring with it some redesign of the software, maybe a lot - but I think it would at once take the sting out of the whole matter.
Thanks for considering!
0 -
David,
You said, "it was also all designed to be entirely optional: it's cool, but you don't need the Hub - or anything in it - to actually use e.g. MuseScore or Audacity etc.". Well, I would say it's not *entirely* optional. The exception to this is if a MuseScore user wants to use the Muse Sounds feature. For this, Muse Hub is not optional at all. It is a requirement. And this is where the frustration comes in. I could easily ignore Muse Hub in order to use the basic MuseScore and Audacity software, but if I want to have the enhanced sound quality of Muse Sounds, I'm forced to install the relatively risky (as discussed above) Muse Hub program, because that's the only way to install that feature. So it comes across as a bit sneaky, like it's presenting an exclusive and desirable toy, baiting people into installing this unknowable (because it's closed-source) software blob. This seems to some of us to be similar to tactics that more shady and untrustworthy companies employ. So it feels slimy, even if that's obviously not your intention. I feel like something needs to change here, because some trust is being lost in this move.
Is there any possibility that the Muse Sounds files can be optionally distributed another way? Perhaps put them into a compressed file with instructions on where the files can be placed, or include a basic, openly readable install script? And could the sampler library required to use them be distributed within MuseScore's packaging instead of through Muse Hub (which for me has been one of the more confusing aspects of this)? This would go a long way toward building trust, I think. For me, on a Linux system, running largely open source software, being forced to install a closed-source program that by default does things without my permission, in order to gain a single (albeit desirable) feature immediately raises red flags and makes me want to push back against this. It make this whole thing seem suspicious, and diminishes trust. Offering the Muse Sounds feature openly, and making Muse Hub just something optional that people can use if they find other installation methods too difficult, frames this in a much better light. It would give those who need it the option to use it, but would still offer those who don't trust it a way around it while allowing the use of all features.
I hope that makes sense. I would like to hear your opinion on this particular piece of this puzzle.
1 -
Hi guys,
Sure, we have definitely heard the concerns and are actively working on a new Linux Hub that no longer features an "always on" privileged helper/background service. This does mean you'll see more prompts for your password to allow the Hub to install updates to e.g the sampler and the Hub itself etc, and as such there may be a few changes here and there in the user experience... but, overall, we hope it should address the majority of the concerns raised.
I can't really speak to the other points. The open vs closed-source software debate is obviously a complex topic... What I can be clear about is that the Hub/FX/Sampler/Sounds etc are all closed-source... one of the reasons the Hub exists is so that we can bring all these experiences in the easiest/most streamlined way to the most users, on multiple platforms, without disturbing the license of any host.
They are definitely optional experiences though - nobody is forcing you to install anything you don't want to. MuseScore is an amazing piece of software, and functions exactly as designed without the additional plugins that Muse Hub provides.
I hope you'll agree that, overall, the Hub is a good step forward. We're working hard to address any security issues the community has raised.
0 -
Hi David,
Good to hear that you are changing the Linux version to address the concerns raised. You indeed heard the concerns and are acting on them. Thank you. Linux user will be very happy about it.
For Windows and MacOS it may seem that these problems do not exist, but actually that is not so. Let me explain.
On Windows, the helper is logged on as LocalSystem (see https://musescore.org/en/node/341517#comment-1166707). LocalSystem is a special account created by Microsoft, who have to say the following, and I quote:
The LocalSystem account is a service account that's used by the operating system. The LocalSystem account is a powerful account that has full access to the system and acts as the computer on the network. If a service logs on to the LocalSystem account on a domain controller, that service has access to the entire domain. Some services are configured by default to log on to the LocalSystem account. Don't change the default service setting. The name of the account is LocalSystem. This account doesn't have a password.
On another page they offer a warning:
One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system. In particular, a service running as LocalSystem on a domain controller (DC) has unrestricted access to Active Directory Domain Services. This means that bugs in the service, or security attacks on the service, can damage the system or, if the service is on a DC, damage the entire enterprise network. (https://learn.microsoft.com/en-us/windows/win32/ad/the-localsystem-account)
For MacOS you are using Apple's recommended architecture for "escalating privileges safely" by concentrating sensitive code in a privileged helper tool (https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/AccessControl.html).
Apple gives a list of sensitive operations that should only be available to trusted code:
Examples of tasks that require elevated privileges include:
- manipulating file permissions, ownership
- creating, reading, updating, or deleting system and user files
- opening privileged ports (those with port numbers less than 1024) for TCP and UDP connections
- opening raw sockets
- managing processes
- reading the contents of virtual memory
- changing system settings
- loading kernel extensions
And they offer a similar warning to Microsoft:
If you have to perform a task that requires elevated privileges, you must be aware of the fact that running with elevated privileges means that if there are any security vulnerabilities in your program, an attacker can obtain elevated privileges as well, and would then be able to perform any of the operations listed above.
As this shows, any bug in the code could inadvertently compromise the system, on both Windows and Mac, and any successful attack on it (and remember it has open ports) could introduce any kind of malware, which than would have unrestricted access. I do not have to detail what that could mean.
These are real vulnerabilities with serious consequences . Again I ask you to do for Windows and Mac users the same you did for Linux users: let go of the privileged helper tools and ask them to install new content and software themselves.
2 -
Hi David,
have you had opportunity to look at my previous post?
What do you think?
Thanks!
0 -
I was very close to installing today until I noticed it asked for admin password to install the helper tool. Glad I avoided. Now I feel the need to examine what all may be running as root on my Mac.
0 -
I’m glad muse hub is changing how they handle admin on Linux but I wonder why it even needs sudo in the first place. Why not install it per user, like Unity Hub or JetBrains Toolbox? That would make it much easier to use on more exotic distros. Right not it’s basically impossible to use on NixOS
0 -
It used sudo to install the Muse Sampler framework itself (which installs to a system level directory so that we can guarantee it's location, which allows Muse Score to find it on every system and localisation without additional configuration etc), and also to install updates to itself if necessary.
We are exploring moving these to user-level actions, but it requires changes to not just Hub, but also Muse Score and Muse Hub.
0 -
David,
Why not just make the sampler framework open source, so you can then include it with MuseScore itself, placed in the same path as the MuseScore program? That way it's always available exactly where MuseScore can know to find it, and there would be no need to mess with MuseHub permissions?
0 -
Disappointing to see the poor practice of unnecessary root processes, but also to see the discussion diverted into questions of ‘trust’. I think the fact that users install MS shows that they have trust in the team. That’s not the issue at all and responses about how little MS Hub does entirely miss the point.
I appreciate the intent to provide a low-friction, background install/update, but it still needs work. I'm not a very regular user of MS, but when I installed I tried changing the download folder, but the file chooser dialog was weird and I’d already started some downloads so it was a bit of a mess, so I stuck with the default.
Really not a user-friendly experience. Whatever direction you go with permissions, the user should be able to easily choose (or move) the location of the samples. Both root and user file systems (many people may still keep these separate) might be low on disk space.
1 -
Has there been any progress on this issue in the last 8 months? I agree with Jim's post that running a background process such intrusive permissions at all times is a pretty big security risk on any OS. Is the team currently exploring any way of allowing these elevated permissions to be disabled when the user hasn't manually requested a download or update, on Windows?
0 -
Someone really wanted me to post an update here about this issue in MuseScore's GitHub repository: https://github.com/musescore/MuseScore/issues/19609#issuecomment-1803518678 in response to this comment from David from earlier: https://musehub.zendesk.com/hc/en-gb/community/posts/8450771193629-MuseHub-runs-with-excessive-privileges-on-Linux-and-MacOS-posing-a-serious-security-threat so here we go:
By now, MuseScore itself is already prepared for a non-privilege-requiring Muse Hub which installs MuseSampler to a non-privilege-requiring location. When it turns out that the Muse Hub team need us to make additional changes on the MuseScore side, they will tell us themselves, so no need to create additional issues on MuseScore's GitHub or on MuseScore.org.
0 -
I haven't thoroughly read this entire thing... so sorry if this has already been said.
On Windows 10, the Muse Hub service runs in the background all the time. Even if you turn off the torrent setting, it still starts on startup. It's impossible to stop, even with admin permissions (although there could easily be ways I don't know of). It remains installed (and running) even after uninstalling Muse Hub.
The ONLY way I've found to stop it is by going into the registry settings for services and changing it from automatic to something else. This will keep it from starting, but will also make Muse Hub useless until you re-enable it and sign out and back in to restart it.
With the torrenting setting off, there is no reason for the service to start on startup. It should start when Muse Hub starts and stop when Muse Hub is closed. It should also be removed when uninstalling Muse Hub (although it's possible that that issue has been fixed in the past few months; I haven't tested that). It should also allow normal users (or at least administrators) to disable it through normal methods.
While it probably isn't malware, it certainly feels like it.
0 -
Hi. New (macOS) user here. I am really grateful for MuseScore being open source, but I just downloaded the default thing and was pretty appalled to find that a privileged helper tool was running as root, persistently, accepting network connections, in the background. This is not the spirit of the privileged helper tool architecture that macOS recommends, which is that the privileged helper be run on-demand and do the absolute minimum necessary to do its job.
I have 7 (not counting com.muse.museservice) privileged helper tools installed. Only one other runs persistently, and for that one (MacUpdater) I had to explicitly opt in to running in the background and installing the helper tool, it wasn't part of the install flow.
I've uninstalled MuseHub now and I will strongly recommend downloading only MuseScore to anyone interested in it. It's a real bummer that this decision is so tightly integrated into the MuseSounds feature, since I now won't even get to try it. I thought I could at least audit the source code to reassure myself but it looks like MuseHub is not open source?
0 -
I simply wish that this tool could become open source so that even if it has all these escalated privileges, we can make sure that it’s not being abused. Simply “trusting” Muse Group is not a valid option or excuse. If this application is just a downloader, why can it not be open source?
0 -
On a windows, if you already did install it, what actions can be taken to uninstall or remove the threat?
0 -
"You can use the Windows "Apps & Features" page from the Windows 11 settings app, or the "Add / Remove Programs" page from the Windows 10 control panel app to remove Muse Hub. Just find or search for it in the list and choose "Uninstall".
According to you Muse Group this will take care of it. Simple enough.
However, if you are a bit paranoid you might consider that for a while a third party program with unlimited permissions has been running on your machine, and that there is no way of telling whether it may have left some backdoor on your system, either through a bug, or by intent, or by some other party that has gained access to MuseHub to compromise your system.
In the latter case your only recourse would be to reinstall Windows.
Hope this helps.
0 -
When I tried to update already installed Audacity (already installed before Muse Hub appeared on computer) there was some network error while downloading.
So my Audacity app just disappeared without any notice and asking me.
I frightened and reinstalled it through Muse Hub, all workspace settings still there, I'm feeling relief.
But still! It looks like something happened behind my back.
0 -
This has been Fixed in Muse Hub V2 (we no longer run with this security model).
In terms of the Audacity issue rusanovski, Muse Hub V1 will uninstall before installing a new update, Muse Hub V2 updates inline (on Windows). Network errors while downloading should not affect existing installations.
0
Please sign in to leave a comment.
Comments
29 comments