Slashdot Mirror


MacOS High Sierra Bug Allows Login As Root With No Password (theregister.co.uk)

An anonymous reader quotes a report from The Register: A trivial-to-exploit flaw in macOS High Sierra, aka macOS 10.13, allows users to gain admin rights, or log in as root, without a password. The security bug is triggered via the authentication dialog box in Apple's operating system, which prompts you for an administrator's username and password when you need to do stuff like configure privacy and network settings. If you type in "root" as the username, leave the password box blank, hit "enter" and then click on unlock a few times, the prompt disappears and, congrats, you now have admin rights. You can do this from the user login screen. The vulnerability effectively allows someone with physical access to the machine to log in, cause extra mischief, install malware, and so on. You should not leave your vulnerable Mac unattended until you can fix the problem. And while obviously this situation is not the end of the world -- it's certainly far from a remote hole or a disk decryption technique -- it's just really, really sad to see megabucks Apple drop the ball like this. Developer Lemi Orhan Ergan was the first to alert the world to the flaw. The Register notes: "If you have a root account enabled and a password for it set, the black password trick will not work. So, keep the account enabled and set a root password right now..."

6 of 237 comments (clear)

  1. Why/how though? by Xuranova · · Score: 5, Interesting

    I can understand if it let you in after hitting enter once, because then it's just ignoring something. If it denies entry the first few times and then lets you in, what do the *nix gurus think is happening after the first few denials to have it change its 'mind?

    --
    "There is no real right or wrong, just what the majority accepts at the time."
  2. Re:Am i missing something here? by Anonymous Coward · · Score: 3, Interesting

    Parent is also incorrect, there is always a root account. I would hazard a guess the issue is with sudo as that is the underlying mechanism for privilege escalation.

  3. Re:Am i missing something here? by ShanghaiBill · · Score: 2, Interesting

    Is no root password a requirement for this "bug"? My Macbook has a root password. I followed the directions in the summary, and it did NOT give me root. I tried several variations. Nothing worked. So as far as I can see there is no bug.

  4. Missing software freedom by jbn-o · · Score: 1, Interesting

    From what I gather so far, you're missing software freedom. Whether this is creation of an unprivileged account named "root" or granting admin privileges to anyone patient enough to "click on unlock a few times" (as the story intro claims), something is wrong. Are MacOS users still being denied the permission to inspect what's really going on in the source code, fix the problem, and distribute fixed code to others?

    In the referenced twitter.com thread, Apple wants to "take a closer look at what's happening together" in an unpublished discussion ("Send us a DM that includes your Mac model along with your macOS version. We'll meet up with you there."). There are plenty of skilled programmers willing to help but without software freedom, this makes Apple look even worse than their lame attempt at seeing the problem which it's entirely possible only they have the privilege to really study, understand, and fix.

  5. Re:Am i missing something here? by Rutulian · · Score: 3, Interesting

    No, by default the root account is disabled, but it's there.

    This smells like a misconfigured PAM. Apple does a lot of weird and non-standard stuff with the *nix user land, so they probably introduced the vulnerability that way. An improperly configured PAM stack can, for example, try a particular auth mechanism a preconfigured number of times before moving to the next auth mechanism. That fallback mechanism could be the Apple directory service, which doesn't handle the root user and leaves it to the system, but ignores the *nix convention that a passwordless entry in /etc/passwd is a disabled account. Not sure exactly what is happening and don't have a system to test on.

    Best workaround is to set the shell of the root user to /bin/false. That will block any attempt to get an interactive login.

  6. Perfect name for this bug: SLAP by paulpach · · Score: 3, Interesting

    I propose we give this bug a name: Superuser Login Absent Password, or SLAP for short.