As Apple fixes macOS root password hole, here's what went wrong

While you patch your Mac, take a look at what upset the Apple cart this week

Code dive Apple has emitted an emergency software patch to address the trivial to exploit vulnerability in macOS High Sierra, version 10.13.1, that allowed miscreants to log into Macs as administrators without passwords and let any app gain root privileges.

The Cupertino iPhone giant kicked out the fix, Security Update 2017-001, today after word of the bug and methods to exploit it ran wild over the internet. It was discussed on Apple's developer support forums two weeks ago, and hit Twitter on Tuesday.

The patch addresses a flaw in its operating system that allows anyone sitting at a Mac to gain administrator access by entering "root" as the username and leaving the password box blank in authentication prompts. This works when altering system settings, logging into the machine, and accessing it remotely via VNC, RDP, screen sharing, and so on. It can also be used to log into system accounts, such as _uucp, and via the command line, which is useful for malware seeking to gain superuser privileges.

If you're running High Sierra, you're urged to install the update as soon as possible.

"An attacker may be able to bypass administrator authentication without supplying the administrator’s password," read Apple's description of the flaw. "A logic error existed in the validation of credentials. This was addressed with improved credential validation."

Grab a disassembler and jump in

Now, let's take a look at this so-called #IAmRoot flaw, and how it affected High Sierra. The problem starts with the fact that the powerful root account is disabled by default. Essentially, it appears to be a fumble in some internal error code handling, leading to the enabling of root with a blank password.

When the OS tries to authenticate a user, in this case root, the security daemon opendirectoryd calls an internal function called odm_RecordVerifyPassword. This attempts to retrieve the shadow hash password for the account to check against the supplied password. Since root is disabled, and has no shadow hash entry, the subroutine returns a fail code. So far, so good.

Seeing as that shadow hash lookup failed, opendirectoryd next tries to retrieve and check a crypt password for the account using od_verify_crypt_password. Weirdly, that function returns the value 0x1, signaling it was successful, and rather than bail out and deny access, the code falls through to function calls that upgrade the crypt password to a shadow hash and stores it for the account.

That means the blank password is stored as the root account's password. This works for any system account that has its login disabled.

Reverse-engineered opendirectoryd code showing the heart of the bug, with od_verify_crypt_password returning 0x1 and screwing up the 0x0 check ... Source: Patrick Wardle

Mac security specialist and Synack chief researcher Patrick Wardle explained the programming cockup in more detail, summarizing it as:

For accounts that are disabled (i.e. don't have 'shadowhash' data) macOS will attempt to perform an upgrade. During this upgrade, od_verify_crypt_password returns a non-zero value. The user (or attacked) specified password is then 'upgraded' and saved for the account.

It appears that od_verify_crypt_password should fail (maybe it does and the check of the return code for 0x0 is just inverted?) Or perhaps the call to odm_RecordVerifyPassword assumes can only be called in a validated/authenticated context?

Fortunately, Apple has addressed the vulnerability. The fact that it was able to slip into production, however, could give fans, particularly in the enterprise market Apple is so keen to grab, pause when it comes to deploying macOS 10.13.

“We greatly regret this error and we apologize to all Mac users,” Apple said in a statement. “Our customers deserve better. We are auditing our development processes to help prevent this from happening again.” ®

Updated on 30 November to add

Oops. It seems that also, in its rush to release a patch, Apple may have bricked filesharing for some users. According to a support document, "If you experience issues with authenticating or connecting to file shares on your Mac" then you should update your network authentication settings in the Terminal with sudo /usr/libexec/configureLocalKDC.

Similar topics

Other stories you might like

  • We sat through Apple's product launch disguised as a dev event so you don't have to
    M2 chip teased plus MacBooks, iOS 16, macOS 13, watchOS 9 and more

    WWDC Apple opened its 33rd annual Worldwide Developer Conference on Monday with a preview of upcoming hardware and planned changes in its mobile, desktop, and wrist accessory operating systems.

    The confab consists primarily of streamed video, as it did in 2020 and 2021, though there is a limited in-person component for the favored few. Apart from the preview of Apple's homegrown Arm-compatible M2 chip – coming next month in a redesigned MacBook Air and 13" MacBook Pro – there was not much meaningful innovation. The M2 Air has a full-size touch ID button, apparently.

    Apple's software-oriented enhancements consist mainly of worthy but not particularly thrilling interface and workflow improvements, alongside a handful of useful APIs and personalization capabilities. Company video performers made no mention of Apple's anticipated AR/VR headset.

    Continue reading
  • Apple offers improved Linux support in macOS Ventura
    Penguin fans will be able to use Rosetta 2 to run x86 binaries in forthcoming update

    Apple is extending support for its Rosetta 2 x86-64-to-Arm binary translator to Linux VMs running under the forthcoming macOS 13, codenamed Ventura.

    The next version of macOS was announced at Apple's World Wide Developer Conference on Monday, and the new release has a number of changes that will be significant to Linux users. The company has disclosed the system requirements for the beta OS, which you can read on the preview page.

    One level of Linux relevance is that macOS 13 still supports Intel-based Macs, but only recent ones, made in 2017 and later. So owners of older machines – including the author – will soon be cut off. Some will run Windows on them via Bootcamp, but others will, of course, turn to Linux.

    Continue reading
  • Workers win vote to form first-ever US Apple Store union
    Results set to be ratified by labor board by end of the week

    Workers at an Apple Store in Towson, Maryland have voted to form a union, making them the first of the iGiant's retail staff to do so in the United States.

    Out of 110 eligible voters, 65 employees voted in support of unionization versus 33 who voted against it. The organizing committee, known as the Coalition of Organized Retail Employees (CORE), has now filed to certify the results with America's National Labor Relations Board. Members joining this first-ever US Apple Store union will be represented by the International Association of Machinists and Aerospace Workers (IAM).

    "I applaud the courage displayed by CORE members at the Apple store in Towson for achieving this historic victory," IAM's international president Robert Martinez Jr said in a statement on Saturday. "They made a huge sacrifice for thousands of Apple employees across the nation who had all eyes on this election."

    Continue reading

Biting the hand that feeds IT © 1998–2022