Live data from Hacker News

AppStore Preferences can be unlocked by a local admin with any bogus password

openradar.appspot.com

41–50 of 190 posts

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#41

The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.

My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake. If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank pa…

It's concerning there's a UI element that displays as a padlock and shows the standard auth dialog but then doesn't actually do any auth. If this is easy to do by mistake, where else is this hiding?

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#43

This does not help at all for the drubbing that macOS High Sierra has been getting recently. Long term OS X users have been waiting for a Snow Leopard like release, but it seems like Apple isn’t taking as much care as required on security and stability on the Mac. Something has to give — either Apple’s organizational structure needs a change or Apple needs to abandon certain things completely instead of releasing sub…

The thing that I don't understand, as a developer, is how these types of bugs even make it in to these releases. Was the "lock" functionality in System Preferences changed at all in any meaningful way for the App Store panel. It doesn't seem like anything about that functionality is sufficiently different so how did this break? Did they bypass the check in order to work on the panel and forget to re-enable it or something? I just don't see how these things happen...

Edit: I just checked an old work machine that we have and the lock isn't even included on the App Store pane in Sierra. This leads me to believe that the only bug here is the inclusion of the lock icon and prompt without the actual code behind it to do the authentication. Seems like the bug is that someone put a lock where it wasn't supposed to be or it was added for a future addition to this panel. Either way, definitely not as major as I first thought.

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#44

The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.

My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake. If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank pa…

I would imagine it's because changing the system date/time could be used nefariously whereas iCloud, Internet Accounts, and Network would all require passwords for the individual accounts/networks to do anything with them.

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#45

The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.

My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake. If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank pa…

> it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password

This is also the behaviour of the App Store preferences in version 10.13.1

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#46

sorry if this is a dumb question, but: why is it unreasonable for a local admin to have the power to change AppStore preferences? without knowing much about the osx security model, this sounds like not a big deal?

For certain features, they want you to reconfirm that the user presently at the keyboard is the real admin at the moment that you do it. This prevents a situation where the actual admin logs in, their attention is taken away from the computer, and someone sits at their chair and does awful things with the computer.

What "awful" things could be done exactly in the App Store panel?

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#47

The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.

My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake. If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank pa…

Indeed, App Store pref box has no lock in 10.11.

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#48

The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.

My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake. If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank pa…

Most OS's require admin rights to change the date/time because of the ability to mess with things like kerberos ticket TTL's, and other security issues.

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#49

Earlier quoted context omitted.

My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake. If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank pa…

I would imagine it's because changing the system date/time could be used nefariously whereas iCloud, Internet Accounts, and Network would all require passwords for the individual accounts/networks to do anything with them.

Date time manipulation can be used to bypass expired certificates.

Re: AppStore Preferences can be unlocked by a local admin with any bogus password

#50

This does not help at all for the drubbing that macOS High Sierra has been getting recently. Long term OS X users have been waiting for a Snow Leopard like release, but it seems like Apple isn’t taking as much care as required on security and stability on the Mac. Something has to give — either Apple’s organizational structure needs a change or Apple needs to abandon certain things completely instead of releasing sub…

Edit: El Capitain doesn't have the padlock on that pane

Other panes validate the password correctly

Post reply on HN