macOS High Sierra App Store settings menu not effectively secured by user password

Posted:
in macOS edited January 10
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.
philboogie

Comments

  • Reply 1 of 18
    1. What/who is the greater level of access than administrator ?

    2. The simple solution is not to us an account that has administrator privileges.
    cornchip
  • Reply 2 of 18
    lkrupplkrupp Posts: 6,451member
    Physical access and logged in as an administrator? Really? I’m terrified B)
    smiffy31bonobobchabigStrangeDayswatto_cobra
  • Reply 3 of 18
    smiffy31 said:
    1. What/who is the greater level of access than administrator ?

    2. The simple solution is not to us an account that has administrator privileges.
    Agreed. The user accounts on our Macs do not have admin privilege, there's an admin account for the times that a lot of, err, administration, is required.

    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.
    cornchipivanh
  • Reply 4 of 18
    asdasdasdasd Posts: 5,131member
    smiffy31 said:
    1. What/who is the greater level of access than administrator ?

    2. The simple solution is not to us an account that has administrator privileges.
    1) well it said admin or greater. 

    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. 
    edited January 10
  • Reply 5 of 18
    asdasdasdasd Posts: 5,131member

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    edited January 10 coolfactorfastasleepcornchip
  • Reply 6 of 18
    lkrupplkrupp Posts: 6,451member
    asdasd said:

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    FUD... pure FUD. You are simply wrong. It’s only the App Store preference panel, nothing else. I confirmed this personally on my system. The password flaw only affects the App Store panel. 
    edited January 10 watto_cobra
  • Reply 7 of 18
    Rayz2016Rayz2016 Posts: 4,351member
    I’m missing something. 

    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?
    edited January 10 watto_cobra
  • Reply 8 of 18
    Mike WuertheleMike Wuerthele Posts: 3,607administrator
    Rayz2016 said:
    I’m missing something. 

    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?
    If the pane is locked, it asks you to validate your credentials. If you follow the steps in the link, it will take any password.
    philboogiefastasleep
  • Reply 9 of 18
    coolfactorcoolfactor Posts: 1,308member
    lkrupp said:
    asdasd said:

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    FUD... pure FUD. You are simply wrong. It’s only the App Store preference panel, nothing else. I confirmed this personally on my system. The password flaw only affects the App Store panel. 

    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?


    fastasleep
  • Reply 10 of 18
    lkrupp said:
    asdasd said:

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    FUD... pure FUD. You are simply wrong. It’s only the App Store preference panel, nothing else. I confirmed this personally on my system. The password flaw only affects the App Store panel. 
    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?
    But that's because you can lock the Preference Panes individually. To unlock the pref pane you're on the current view's code takes your input and likely calls some auth API (I'm guessing). I'm guessing each pref pane is its own set of code that makes a hit to the auth API. Perhaps this pref pane instance had some bug on it which the others did not, dunno what or why but that's what it sounds like.

    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.
    bonobobwatto_cobra
  • Reply 11 of 18
    What I don’t understand is how this can happen if the server holds the key to the App Store user account. If you type in a username and password, you’d expect the server to compare the input with the entries in the database table... the client basically becomes a ‘dumb terminal’. So how could the client provide access to information the server wouldn’t be able to give with the wrong credentials submitted? This could be a server issue as well as a client one... 

    Anyway, amateur hour & bad design. Apple needs to revise their processes and get some people fired over this.
    edited January 10
  • Reply 12 of 18
    asdasdasdasd Posts: 5,131member
    lkrupp said:
    asdasd said:

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    FUD... pure FUD. You are simply wrong. It’s only the App Store preference panel, nothing else. I confirmed this personally on my system. The password flaw only affects the App Store panel. 
    I literally said it was the App Store settings in the first paragraph. 

    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. 
  • Reply 13 of 18
    asdasdasdasd Posts: 5,131member

    lkrupp said:
    asdasd said:

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    FUD... pure FUD. You are simply wrong. It’s only the App Store preference panel, nothing else. I confirmed this personally on my system. The password flaw only affects the App Store panel. 
    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?
    But that's because you can lock the Preference Panes individually. To unlock the pref pane you're on the current view's code takes your input and likely calls some auth API (I'm guessing). I'm guessing each pref pane is its own set of code that makes a hit to the auth API. Perhaps this pref pane instance had some bug on it which the others did not, dunno what or why but that's what it sounds like.

    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.
    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. 
  • Reply 14 of 18
    Rayz2016Rayz2016 Posts: 4,351member
    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    Fair point, but consider this:  you and I know it’s bad form to run day-to-day as an administrator, but do the vast majority of Apple’s customers? When MacOS is installed, an admin user is created, and that is how most people will run. This is fair enough, because if they started with a standard user and created an admin user on the fly, people would get confused and lose access to their system in the first day. 

    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. 
    edited January 11
  • Reply 15 of 18
    Rayz2016Rayz2016 Posts: 4,351member
    asdasd said:

    lkrupp said:
    asdasd said:

    lkrupp said:
    Physical access and logged in as an administrator? Really? I’m terrified B)
    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. 
    FUD... pure FUD. You are simply wrong. It’s only the App Store preference panel, nothing else. I confirmed this personally on my system. The password flaw only affects the App Store panel. 
    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?
    But that's because you can lock the Preference Panes individually. To unlock the pref pane you're on the current view's code takes your input and likely calls some auth API (I'm guessing). I'm guessing each pref pane is its own set of code that makes a hit to the auth API. Perhaps this pref pane instance had some bug on it which the others did not, dunno what or why but that's what it sounds like.

    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.
    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. 


    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. 
    edited January 11
  • Reply 16 of 18
    Rayz2016Rayz2016 Posts: 4,351member


    Anyway, amateur hour & bad design. Apple needs to revise their processes and get some people fired over this.
    Yes, what Apple needs to do is listen to someone who read about the problem on a blog site. 
    watto_cobra
  • Reply 17 of 18
    ivanhivanh Posts: 225member
    "The macOS High Sierra 10.13.2 App Store settings can be unlocked with any password entered by an administrator account"?  Confused. 

    I suppose what is needed is an Apple ID and password.  See pic below:




  • Reply 18 of 18
    Rayz2016 said:


    Anyway, amateur hour & bad design. Apple needs to revise their processes and get some people fired over this.
    Yes, what Apple needs to do is listen to someone who read about the problem on a blog site. 
    Did I ever imply they had 'to listen to me'? No. Did I mailed them personally? No.
    I don't need your immature, snarky comment, dude. 
Sign In or Register to comment.