macOS High Sierra App Store settings menu not effectively secured by user password
The macOS High Sierra 10.13.2 App Store settings can be unlocked with any password entered by an administrator account -- but Apple appears to have already implemented a fix in the beta releases currently in testing.
Filed on Open Radar on Jan. 8, and first spotted by MacRumors, the vulnerability allows any user with physical access to a machine logged into an account with administrator level access or greater to alter App Store settings at will, without having to enter a legitimate password. Assailants can alter password requirement settings, or disable the computer's automatic installation of macOS patches.
As vulnerabilities go, this is a dramatic mis-step in quality assurance and testing, but not one with dramatic security effects to the user. The previous bug that could create and grant access to a Root account had more profound security implications.
AppleInsider reproduced this issue on High Sierra 10.13.1 and 10.13.2. However, the vulnerability appears to have been patched on High Sierra 10.13.3 beta 4, and appears to have not existed on High Sierra 10.13 prior to updates. We could not reproduce it on Sierra, El Capitan, Mavericks, or Lion.
Users can minimize risk by keeping their Mac physically secure, and logging out when leaving the presence of the machine. Further security can be provided by preventing remote access to the machine by untrusted parties.
Filed on Open Radar on Jan. 8, and first spotted by MacRumors, the vulnerability allows any user with physical access to a machine logged into an account with administrator level access or greater to alter App Store settings at will, without having to enter a legitimate password. Assailants can alter password requirement settings, or disable the computer's automatic installation of macOS patches.
As vulnerabilities go, this is a dramatic mis-step in quality assurance and testing, but not one with dramatic security effects to the user. The previous bug that could create and grant access to a Root account had more profound security implications.
AppleInsider reproduced this issue on High Sierra 10.13.1 and 10.13.2. However, the vulnerability appears to have been patched on High Sierra 10.13.3 beta 4, and appears to have not existed on High Sierra 10.13 prior to updates. We could not reproduce it on Sierra, El Capitan, Mavericks, or Lion.
Users can minimize risk by keeping their Mac physically secure, and logging out when leaving the presence of the machine. Further security can be provided by preventing remote access to the machine by untrusted parties.
Comments
2. The simple solution is not to us an account that has administrator privileges.
That said, last time I talked to Apple support (about a year ago I guess), they told me that Apple did not recommend user accounts without admin privilege and urged me to change it. I was surprised by this (no rationale was offered) and I think this incident demonstrates that every simple step to reduce vulnerability is worth taking. Hopefully Apple will revise its guidance, I am currently ignoring it.
2) In general most users install as the admin user, or it is installed by default. So this bug does mean that someone with physical access can lock you out. Its just strange that it wasnt tested.
EDIT:
They can't lock you out as it isnt a widespread system preferences issue.
Admin user is default. This bug means that passwords are broken. Any password works on the App Store settings. Its fairly big.
Something is going on with those preferences panels, somebody has written some test code which makes any password work, and its clearly not defined out on launch.
Also it means the security is skin deep, that each preference panel is using its own mechanism, and not using the security API. Odd anyway.
If I’m logged on as administrator, why do I need to enter passwords to fiddle with the settings? Why am I expected to enter a password here? Or is the problem that I am asked for a password and it lets any password through?
You misunderstood. Rather than the enforcement being on a system-wide level, it seems that each Preference Pane is implementing the password check individually. That's just bad design, and makes the overall system fragile.
Since this is even _possible_ means that the same issue can exist elsewhere, including third-party apps.
How can we trust macOS security checks if they are this easy to bypass?
Unless you write software for a living, it is often tempting to say it should all just work without any bugs at all times. But the reality of building software is setting up a ton of stuff correctly everywhere. It's no more perfect than people are.
Anyway, amateur hour & bad design. Apple needs to revise their processes and get some people fired over this.
By the way it’s a bit insane to always defend a multinational when they make these kind of mistakes. You are a consumer, and Apple sometimes makes mistakes.
There is a specific api that Apple urges people to use to get admin level authorisation. Here it is.
https://developer.apple.com/library/content/documentation/Security/Conceptual/authorization_concepts/01introduction/introduction.html#//apple_ref/doc/uid/TP30000995-CH204-TP1
I cant see why the system preferences wouldn’t use it. In fact they give an example of the system preferences energy pane in the document.
That auth api will show a dialog (or not depending on settings - like if there’s a 15 minute time when you remain authorised, but I don’t think that applies here). So either there’s a general bug in the auth api or the return value is ignored.
So now we have a fresh install with one admin user – and a problem. Strictly speaking, because this is essentially Unix, I should be able to do anything on this system without challenged for a password. Apple, quite rightly, realised this is a bad idea because everyone who isn’t a tech head will be running as an admin user. So they’ve put in an extra check just to make sure. But it looks to me like someone with access to the MacOS source code has bypassed this check and done their own thing.
This is indeed a problem because most users run MacOS as administrators. And if each component of the UI layer is checked separately then there are probably more areas where this will occur.
This points to the same QA failing that let the root access bug slip through. I would like to think that whatever is leading to these security holes is going to be sorted out sooner rather than later.
The generated security token would have to be passed to any other function requiring elevated privileges. You can’t just ignore it and carry on. There could be a bug in the API, but that would show up everywhere. It’s possible that someone with access to the OS source code has done something really stupid.
Yes, what Apple needs to do is listen to someone who read about the problem on a blog site.
I suppose what is needed is an Apple ID and password. See pic below:
I don't need your immature, snarky comment, dude.