-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More secure helper tool to avoid possible abuse of SMC interface by malware apps #601
Comments
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/ |
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. |
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).The text was updated successfully, but these errors were encountered: