Closed mhaeuser closed 1 year ago
Hi,
I don't see a security concern here because macOS checks that only Macs Fan Control is able to use the priviledged helper tool.
Well, if this was not the case, this would not be a "security concern" but an outright vulnerability, which I would have reported privately. The issue is this helper proxies a privileged interface into the unprivileged environment, defeating the security boundary as a whole. Reduced hardening from locally signed complilations, bugs in the unprivileged application, etc. may all lead to performing unintended operations on the privileged SMC interface.
This is not the case, this how apple priviledged tools generally work, but I'll think of reducing API abilities.
Just stumbled over this: https://blog.obdev.at/what-we-have-learned-from-a-vulnerability/ In post 2 you imply SMAuthorizedClients authenticates the peer (which it apparently does not). Is this considered in the code? I didn‘t check.
Thanks, that's a very intereseting and important read.
Will be implemented in the next update for sure.
Security enforcement (as recommended by Objective Development) is implemented and checked to be working fine. Works on macOS 10.14 and later. On 10.13 and older no additional security checks are made.
The latest release of this app ships with a Privileged Helper App that exposes an SMC interface that takes caller-specified key names without a whitelist. There are obvious security concerns with not sanity-checking the key names intended to be exposed at the high-security level (helper). To not entirely eliminate this intentional security boundary from Apple, please consider matching the supplied key names against a whitelist. Or, much better yet, do not have any direct SMC exposure, but instead abstract the operations (e.g. expose
SMCSetFanSpeed
overSMCWriteKey
or alike).