Distribute Sunshine on macOS as an app bundle signed by a trusted certificate

[cathyjf]

Sunshine should be distributed as a proper app bundle, and signed by some trusted certificate (perhaps owned by a trusted maintainer) as part of the GitHub build process. Then the Homebrew formula should be replaced by a cask that just installs the trusted binary. This will solve the following problems:

1. Permissions will not need to be removed and re-granted each time Sunshine updates any code.
2. Sunshine will not be a gaping vulnerability on the host machine. Currently, once you grant Sunshine any permissions, you're actually granting those permissions to all programs, because any program can trivially inject code into the Sunshine process. To avoid this, it's necessary for Sunshine and all its dependencies to use the hardened runtime, and be distributed as an app bundle.

(See LizardByte/Sunshine#3348 (comment) for context.)

[ReenigneArcher]

There were a lot of issues with distributing a bundle previously (LizardByte/Sunshine#186), which is why it was never promoted and eventually removed in favor of the macports build (although homebrew is now the preferred option). You're free to make an attempt at a new app bundle if you want and submit a PR.

This should also be a feature request so I will convert it to that.

[cathyjf]

Considering this is a security issue, I'm not sure it should be relegated to a feature request, but it's up to you.

[ReenigneArcher]

Currently, once you grant Sunshine any permissions, you're actually granting those permissions to all programs, because any program can trivially inject code into the Sunshine process.

Please open a security ticket using the "security" tab in the Sunshine repo, with the detailed steps required to accomplish this.

[cathyjf]

You apparently don't actually want people to file bugs against Sunshine, because you make it a grossly excessive amount of work to do so, and then nitpick those bugs for asinine reasons. That one sentence you quoted already gives a full description of the issue. You can do whatever you want with that information.

[cathyjf]

Let me try this again. The bug here is that Sunshine is not distributed as an app bundle. As a consequence, once Sunshine has been granted, say, the Accessibility permission, any process can take advantage of that permission by injecting code into Sunshine. The only way to avoid this problem is to distribute Sunshine as an app bundle, using the hardened runtime for Sunshine and all its dependencies. It is not something that can be solved in another way. The Security bug template indicates that the bug will be secret. This does not make any sense for a tracking bug for a long term task, like distributing Sunshine as an app bundle. This kind of tracking bug should be public, not relegated to a discussion along with a million support questions, or kept as a secret bug that no one can see.

You can certainly argue that the security problem is not serious, but it's definitely a bug, and distributing Sunshine as an app bundle is the only way to fix it. I don't necessarily plan to make a pull request to fix it any time soon, and if that means it can't even be tracked as a bug, you're free to run the project that way, although it's odd.

[ReenigneArcher]

The bug here is that Sunshine is not distributed as an app bundle

I understand what you're saying, although, we provide a macport and homebrew option out of convenience only. Many projects provide absolutely no packages, and leave it up to the community to do so. Not saying that packaging can't be improved, as it certainly can... assuming you can solve all the issues we previously faced when trying to address LizardByte/Sunshine#186. I don't own a mac and I do not personally plan on fighting the issues associated with packaging into a bundle or dmg again. If I recall the biggest issue is related to dependency linking. Without homebrew you need to ensure the user has the same version of the dependencies used at build time, unless you static link everything which can be somewhat complicated. We static link everything on Windows, but it's easier to get static libraries for the dependencies.

If code/commands can truly be injected into the sunshine process that absolutely needs to be reported using the security tab, with specific details on how to expose the vulnerability. It is intended to be secret so users cannot be taken advantage of before a fix is publicly available. This is a standard practice across ALL of GitHub to address security concerns, and work through the CVE processes. Relevant developers are able to see and be added to the security report if needed.

I don't necessarily plan to make a pull request to fix it any time soon

You're not obligated to, although no one else is either. This is a volunteer project that people work on in their free time.

[cathyjf]

The security issue here is arguably minor, but it's not something that really requires further explanation. This isn't some tricky attack. It's just what I said. In general, if a binary isn't using the hardened runtime, other applications can inject code into it. Here's one of many ways you might do it. Take a look at the dynamic linkages of the sunshine binary:

$ otool -L (which sunshine)
/opt/homebrew/bin/sunshine:
        ...
	/opt/homebrew/opt/miniupnpc/lib/libminiupnpc.18.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/homebrew/opt/opus/lib/libopus.0.dylib (compatibility version 11.0.0, current version 11.1.0)
...

A local attacker can replace one of those libraries to escalate from one privilege context (i.e., not being able to record the screen) to a different privilege context (i.e., whatever privileges Sunshine has, such as recording the screen).

Now you might say, those libraries just shouldn't be writeable by ordinary users -- but they are, because of how Homebrew works. But even if they weren't, it wouldn't solve the problem, because any user who can run the Sunshine binary can just inject arbitrary objects when launching it by specifying DYLD_INSERT_LIBRARIES in the environment of the process being invoked... no filesystem permissions required.

This isn't something specific to Sunshine. It's a flaw in any application that requests special permissions on macOS (such as screen recording) and isn't using the hardened runtime as part of an app bundle. I wrote more about this, in a different context, here: https://github.com/cathyjf/keychain-interpose

Obviously, because this is just a local privilege escalation, you can say it's not serious. But it does circumvent the macOS security model, and it is a bug. It's not a secret. It's patently obvious to anyone with a basic knowledge of macOS security principles. Treating it as a secret would be laughable. Rather, it's something that requires a long term plan to address, preferably with a top-level tracking bug and a series of sub-bugs.

Another reason you might not think that this is serious is that the bug, such as it is, just reduces security to be the same as it would be on Windows or GNU/Linux, where there is no special process for gaining access to record the screen. That is true. But macOS normally has hardened security in this regard, and it would be nice not to undermine it, particularly since the screen recording permission is so powerful.

[Hazer]

I have a handful installed right now, it picked my interest, as supply chain attacks are indeed increasing, but I guess this is a yes if not code signed and permission required then?

Right now, I cannot evaluate efforts to do it, and I already didn't deliver my past promises, but if I get room to take a jab at it and see if I can do something, I'll try taking a look how that could be done. First thing that takes me aback is that statically compiling dependencies would be a HELL of an effort, and the whole compilation is already a burden to maintain and for codesign we'd need an Developer Account right? Not sure how worth is the effort since macOS barely has any maintainers, and I for one, barely know any cmake, then include in that the cost of the Developer Account... If not required a Dev Account, I may look at it in the future.

[cathyjf]

It's not necessary to statically compile all dependencies. I already have a solution for encapsulating the dependencies along with the application. See here: https://github.com/cathyjf/keychain-interpose/blob/main/src/encapsulate-app.cpp. In due time, I'm planning to make that file into its own repository, with proper documentation and options.

The cost of an Apple developer account is trivial at $100/year. I already have one, but ideally the official builds should be signed by an existing trusted maintainer.

[Hazer]

Interesting, when isolated in your own repo, could you guide me on how to try it on Sunshine? I can't look into it this month, I was away for health reason and is kinda already overwhelming reading past issues and PRs like yours to get me back again.

Regarding the dev account, I can't afford it right now, it's almost my rent cost (I'm not from USA) and at the moment, I'm not in a great place financially. Idk about other members tho.

[Hazer]

I think an account would be useful if anyone wants to create an DriverKit emulation to support gamepads too, but I'm not sure how those efforts are doing right now

[cathyjf]

I think the hard part of creating a DriverKit driver for emulated gamepads would be writing the code, not signing it. It's possible to test unsigned drivers locally.