Muse Hub runs with excessive permissions on Linux

• Dec 20, 2022 - 13:58
Reported version
4.x-dev
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

To get access to Muse Sounds one has to install the muse-hub application. Unfortunately there are major problems with that:

  • Installing the applications installs a muse-hub system service which is constantly running, even when Musescore is not in use
  • The service runs with way excessive permissions. Uid 0 (root) and seemingly no protections for abuse
  • The service opens TCP and UDP ports on all IPv4 and IPv6 interfaces

This is very bad for security and quite questionable for privacy.

Is there any reason this service is not started on demand and running with user privileges?
If any extra permissions are needed (I doubt it), were proper means to mitigate risks considered (dropping root privileges ASAP, confinement to private directories, etc.)?

Workaround:
After installing Muse Sounds pack needed stop and disable the rogue service:

systemctl stop muse-hub.service
systemctl disable muse-hub.service

Comments

For the workaround:
Doing

systemctl stop muse-hub.service
systemctl disable muse-hub.service

will only stop and disable muse-hub.service until the service installs a new package (without you knowing) - at least on debian based systems.
This because it has "vendor preset: enabled"

You need to override the vendor preset.
On my system (could be different on your distribution), edit:
/lib/systemd/system-preset/90-systemd.preset
add at the end:
disable muse-hub.service

sudo systemctl status muse-hub.service
should give vendor preset: disabled.

sudo systemctl status muse-hub.service
● muse-hub.service - Muse Hub Helper Service
Loaded: loaded (/etc/systemd/system/muse-hub.service; disabled; vendor preset: disabled)
Active: inactive (dead)

Regression Yes No
Workaround No Yes

Not a regression, Muse Hub didn't exist before
Workaround is to i stall MuseScore directly, not via Muse Hub. Or the above

That could certainly be done and would stop bittorrent, but the root owned process would still be running and, potentially, compromise your system.

Come on. The thing is insecure, no question about it. You cannot ask end users to fix security design problems with a workaround. (Port 6881 is torrent.)
The main problem is not the torrent protocol, but the the root account.

As mentioned above, the place the Muse Hub team has asked all reports to go is the Zendesk help center. It’s unlikely they will see discussions elsewhere. I don’t know how they run that site, but I do see a discussion area there.m, so that seems like a good place to start.