Skip to content

The Eclectic Light Company

Macs, painting, and more
Main navigation
  • Downloads
  • M1 & M2 Macs
  • Mac Problems
  • Mac articles
  • Art
  • Macs
  • Painting
hoakley November 28, 2017 Macs, Technology

Major vulnerability in High Sierra 10.13.1: anyone can gain elevated privileges (updated)

TL; DR Summary:
If you are running High Sierra, stop whatever you are doing and enable the root user, assigning it a secure and robust password. If you don’t, anyone is likely to be able to gain privileged access to your Mac without knowing any usernames or passwords.

How to do that

Log onto your Mac as an admin user, open the Users & Groups pane, and authenticate as that admin user. Click on Login Options at the lower left, and click on the Join button by Network Account Server in the lower section of the pane. In the next dialog, click on the button to Open Directory Utility, then click on its padlock and authenticate again.

If the root user is not enabled yet, use the Edit menu command to enable it, and assign it a secure and robust password.

If the root user is already enabled, use the the Change Root Password… command in the Edit menu to assign the root user a good password. Quit Directory Utility, and close the Users & Groups pane.

Oh, and Patrick Wardle believes that this can be exploited remotely, if you have certain sharing services enabled. So even if you think that physical access to your Mac is restricted, it’s quite possibly still vulnerable.


Here’s how this story developed this evening…

This evening, Lemi Orhan Ergin has revealed a major security vulnerability in macOS 10.13.1 High Sierra, in which any local user can obtain elevated privileges without knowing any username or password.

The key part of this vulnerability is that repeatedly entering the username root with an empty password into authentication dialogs can eventually result in successful authentication. This can even be performed when using a guest account!

A simple demonstration is to enable the guest account in Users & Groups, log out, and then log back in as the guest user. Open a pane in System Preferences which usually requires authentication, such as Users & Groups, or Network. Then click on the padlock to bring up the authentication dialog. There, enter the username root, leave the password blank, and click on the Unlock button.

The first time that you do this, there will be a pause, and the dialog will shake to indicate refusal. Keep trying, and after 3-6 attempts, the pane will suddenly unlock, and give you admin access to its controls.

While Apple works out how to fix this and promulgates an urgent update, High Sierra users should therefore disable guest accounts (that is strongly recommended anyway, but check that yours is), and ensure that unattended Macs are left with the user logged out fully. Hopefully the latter will not prove vulnerable to the same exploit.

Anyone using High Sierra systems to store and process sensitive information might like to re-evaluate their security measures very quickly.

In case Sierra users are concerned that this might affect older macOS, I have tried it on Sierra 10.12.6, and it definitely doesn’t work there: the behaviour of the authentication dialog is quite different, responding slowly and shaking each time. Phew!

Update at 2045:

The suggested workaround seems to be to leave the root account enabled, but to assign it a secure and robust password – thanks to Jack Brewster via Andy Ihnatko.

In practice, until a High Sierra system is protected from this:

  • Anyone can start up and access any Mac (unless it is firmware-protected, or the startup volume encrypted) simply by logging on as root with an empty password. This then gives then admin rights, at least.
  • Anyone can bypass an authentication dialog in macOS, such as that protecting System Preferences panes, simply by entering the username of root and an empty password. This works from guest accounts too.
  • Some access following authentication as root appears fragile, and may not work fully. But a local intruder still has a lot more access to your Mac than you’d want.

It is also much easier to use this exploit to access a Mac if the Login options (in Users & Groups) are set to display the login window as Name and password, rather than a List of users.

Although some have suggested simply disabling the root account would block exploits, that doesn’t currently look to be the preferred workaround.

Ultimately, this is going to require an urgent software update to restore system security.

Update at 2115:

The preferred workaround for this does seem to be to assign the root user a secure and robust password. To do this, log onto your Mac as an admin user, open the Users & Groups pane, and authenticate as that admin user. Click on Login Options at the lower left, and click on the Join button by Network Account Server in the lower section of the pane.

In the next dialog, click on the button to Open Directory Utility, then click on its padlock and authenticate again. Then use the the Change Root Password… command in the Edit menu to assign the root user a good password. Quit Directory Utility, and close the Users & Groups pane.

It is currently unclear whether there is a separate security vulnerability involved here, or whether this is ‘just’ a default misconfiguration of High Sierra. Sierra, in contrast, ships with the root user disabled, which has been standard practice for OS X and macOS in the past.

We will have to wait for further information from Apple confirming the problem and the official recommended solution.

Update at 2135:

The smart money is now on this being a bug in High Sierra, and not a simple misconfiguration. According to MacFormat @MacFormat, High Sierra systems are not configured by default to enable the root user. However, entering the username root and a blank password (as described above) triggers a bug which then enables the root user with that blank password.

This will therefore require an urgent security fix from Apple, and assigning a secure password to the root user is only a temporary workaround. Note also that MacFormat staff have been able to exploit the bug to gain access to a Mac as the root user over a local network, which makes it even more serious.

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Pinterest
  • Email
  • Print

Like this:

Like Loading...

Related

Posted in Macs, Technology and tagged guest access, guest account, High Sierra, macOS, macOS 10.13, security, vulnerability. Bookmark the permalink.

14Comments

Add yours
  1. 1
    Alexander Celeste on November 28, 2017 at 8:34 pm

    Ever since installing High Sierra I have noticed the Root user become enabled now and again. I first stumbled on this after seeing the Other option pop up on the login screen. You can disable the Root user in Directory Utility (at /System/Library/CoreServices/Applications), which I’ve done every week or so since installing High Sierra. No clue why it gets enabled again and again. I hadn’t actually tried using it, though, when enabled. I guess it is being turned on with no password, given what you’ve written here. Really bad major vulnerability indeed. But at least you should be able to stop it by disabling the Root user yourself again and again. Let’s hope this is fixed in the next update to High Sierra.

    LikeLiked by 1 person

    • 2
      Alexander Celeste on November 28, 2017 at 9:39 pm

      Actually, disabling the Root user doesn’t help… Actively setting a password for the Root user seems to be good for now, but I guess that we’ll see if that gets reset in the coming days.

      LikeLiked by 1 person

      • 3
        hoakley on November 28, 2017 at 9:47 pm

        Thank you for your helpful comments. I have updated the article above with the latest news, which indicates that this is a bug, which is going to need a software patch. The actions described above trigger the bug, which activates the normally disabled root account with a blank password.
        So the best workaround for the moment is to enable the root account (if you don’t, an intruder can) and assign it a robust and secure password.
        Howard.

        LikeLike

  2. 4
    Miles Wolbe on November 29, 2017 at 7:53 am

    Hi Howard,

    Turns out this glaring vulnerability has been discussed on Apple’s own Developer Forums since November 13, when chethan177 nonchalantly offered (in part):

    “On startup, click on ‘Other’
    Enter username: root and leave the password empty. Press enter. (Try twice)
    ”

    See also the HN discussion.

    Aloha,

    Miles

    P.S. Can you please tell me the markup for adding a blockquote in the comments without botching the rendering as I did on my first attempt some weeks ago?

    LikeLiked by 1 person

    • 5
      hoakley on November 29, 2017 at 8:17 am

      Thank you, Miles – I have seen the tweets showing this.
      It’s such a staggering vulnerability that I don’t think that anyone recognised its significance at the time.
      As for blockquotes, the official WordPress comment markup is <blockquote>, and demonstrated below.

      But the blockquote style may not be quite what you want to see!

      Howard.

      LikeLike

      • 6
        Miles Wolbe on November 29, 2017 at 8:29 am

        Thanks Howard! The blockquote display in the email notification was correct (or rather, what I would expect), while the styling on the website is quite a bit larger. I recall when I last used the blockquote tag you kindly cleaned up the display. No worries, I’ll just avoid the tag here for now. Thanks again.

        LikeLike

  3. 7
    simonjasimpson on November 29, 2017 at 8:11 am

    Howard, do you know whether this vulnerability applies to any earlier operating systems such as Sierra and El Capitan ?

    LikeLike

    • 8
      hoakley on November 29, 2017 at 8:13 am

      Simon,
      I have tested Sierra 10.12.6, and it definitely does not occur there. I’d be confident that it does not occur in El Capitan either. All the evidence is that it is new with High Sierra 10.13, and present in 10.13.1 too.
      Howard.

      LikeLike

      • 9
        simonjasimpson on November 29, 2017 at 3:06 pm

        Thanks Howard. Good to know. A major “whoops!” at Apple though.

        LikeLiked by 1 person

  4. 10
    Miles Wolbe on November 29, 2017 at 9:58 am

    Hi Howard,

    Another important update, this one from @unsynchronized:

    macos 10.13 bug isn't limited to root in all circumstances; via ARD, you can log in as any existing user (e.g. _applepay) and share the screen of the logged-in user. also _uucp is allowed to log in

    — cstone (@unsynchronized) November 28, 2017

    “macos 10.13 bug isn’t limited to root in all circumstances; via ARD, you can log in as any existing user (e.g. _applepay) and share the screen of the logged-in user. also _uucp is allowed to log in”

    The suggested workaround of setting or changing the root password is important but apparently not sufficient given this new information.

    LikeLiked by 1 person

    • 11
      hoakley on November 29, 2017 at 10:02 am

      Yes, except that you need to enable remote access via ARD (and similar) in order to open those vulnerable accounts.
      So long as you don’t enable those, they’re not exploitable.
      But yes, this is a security calamity. It’s as if someone when testing High Sierra opened this up deliberately, and forgot to close it down. Staggering.
      Howard.

      LikeLike

      • 12
        Tony on November 29, 2017 at 11:53 am

        Yes, left-over test code was my first thought too. I do hope that’s the case so the fix is quick and clean. They really need to look at their regression testing (doing some would be a start).

        LikeLiked by 1 person

      • 13
        Miles Wolbe on November 29, 2017 at 5:43 pm

        you need to enable remote access via ARD (and similar) in order to open those vulnerable accounts.

        Which many admins do!

        Happily, the patch fixes this as well – just confirmed in a 10.13.1 virtual machine.

        LikeLiked by 1 person

        • 14
          hoakley on November 29, 2017 at 8:42 pm

          Thanks for letting us know.
          Howard.

          LikeLike

·Comments are closed.

Quick Links

  • Downloads
  • Mac Troubleshooting Summary
  • M1 & M2 Macs
  • Mac problem-solving
  • Painting topics
  • Painting
  • Long Reads

Search

Monthly archives

  • February 2023 (4)
  • January 2023 (74)
  • December 2022 (74)
  • November 2022 (72)
  • October 2022 (76)
  • September 2022 (72)
  • August 2022 (75)
  • July 2022 (76)
  • June 2022 (73)
  • May 2022 (76)
  • April 2022 (71)
  • March 2022 (77)
  • February 2022 (68)
  • January 2022 (77)
  • December 2021 (75)
  • November 2021 (72)
  • October 2021 (75)
  • September 2021 (76)
  • August 2021 (75)
  • July 2021 (75)
  • June 2021 (71)
  • May 2021 (80)
  • April 2021 (79)
  • March 2021 (77)
  • February 2021 (75)
  • January 2021 (75)
  • December 2020 (77)
  • November 2020 (84)
  • October 2020 (81)
  • September 2020 (79)
  • August 2020 (103)
  • July 2020 (81)
  • June 2020 (78)
  • May 2020 (78)
  • April 2020 (81)
  • March 2020 (86)
  • February 2020 (77)
  • January 2020 (86)
  • December 2019 (82)
  • November 2019 (74)
  • October 2019 (89)
  • September 2019 (80)
  • August 2019 (91)
  • July 2019 (95)
  • June 2019 (88)
  • May 2019 (91)
  • April 2019 (79)
  • March 2019 (78)
  • February 2019 (71)
  • January 2019 (69)
  • December 2018 (79)
  • November 2018 (71)
  • October 2018 (78)
  • September 2018 (76)
  • August 2018 (78)
  • July 2018 (76)
  • June 2018 (77)
  • May 2018 (71)
  • April 2018 (67)
  • March 2018 (73)
  • February 2018 (67)
  • January 2018 (83)
  • December 2017 (94)
  • November 2017 (73)
  • October 2017 (86)
  • September 2017 (92)
  • August 2017 (69)
  • July 2017 (81)
  • June 2017 (76)
  • May 2017 (90)
  • April 2017 (76)
  • March 2017 (79)
  • February 2017 (65)
  • January 2017 (76)
  • December 2016 (75)
  • November 2016 (68)
  • October 2016 (76)
  • September 2016 (78)
  • August 2016 (70)
  • July 2016 (74)
  • June 2016 (66)
  • May 2016 (71)
  • April 2016 (67)
  • March 2016 (71)
  • February 2016 (68)
  • January 2016 (90)
  • December 2015 (96)
  • November 2015 (103)
  • October 2015 (119)
  • September 2015 (115)
  • August 2015 (117)
  • July 2015 (117)
  • June 2015 (105)
  • May 2015 (111)
  • April 2015 (119)
  • March 2015 (69)
  • February 2015 (54)
  • January 2015 (39)

Tags

APFS Apple AppleScript Apple silicon backup Big Sur Blake bug Catalina Consolation Console diagnosis Disk Utility Doré El Capitan extended attributes Finder firmware Gatekeeper Gérôme HFS+ High Sierra history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 malware Mojave Monet Monterey Moreau MRT myth narrative OS X Ovid painting Pissarro Poussin privacy realism Renoir riddle Rubens Sargent scripting security Sierra SilentKnight SSD Swift symbolism Time Machine Turner update upgrade Ventura xattr Xcode XProtect

Statistics

  • 13,775,357 hits
Blog at WordPress.com.
Footer navigation
  • About & Contact
  • Macs
  • Painting
  • Language
  • Tech
  • Life
  • General
  • Downloads
  • Mac problem-solving
  • Extended attributes (xattrs)
  • Painting topics
  • Hieronymus Bosch
  • English language
  • LockRattler: 10.12 Sierra
  • LockRattler: 10.13 High Sierra
  • LockRattler: 10.11 El Capitan
  • Updates: El Capitan
  • Updates: Sierra, High Sierra, Mojave, Catalina, Big Sur
  • LockRattler: 10.14 Mojave
  • SilentKnight, silnite, LockRattler, SystHist & Scrub
  • DelightEd & Podofyllin
  • xattred, Metamer, Sandstrip & xattr tools
  • 32-bitCheck & ArchiChect
  • T2M2, Ulbow, Consolation and log utilities
  • Cirrus & Bailiff
  • Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma
  • Revisionist & DeepTools
  • Text Utilities: Nalaprop, Dystextia and others
  • PDF
  • Keychains & Permissions
  • LockRattler: 10.15 Catalina
  • Updates
  • Spundle, Cormorant, Stibium, Dintch, Fintch and cintch
  • Long Reads
  • Mac Troubleshooting Summary
  • LockRattler: 11.0 Big Sur
  • M1 & M2 Macs
  • Mints: a multifunction utility
  • LockRattler: 12.x Monterey
  • VisualLookUpTest
  • Virtualisation on Apple silicon
  • LockRattler: 13.x Ventura
Secondary navigation
  • Search

Post navigation

Telling Modern Stories: the narrative painting of Benjamin West, 3, Penn to the Death of Chatham
Does Woodpile crash on you when trying to start? This should fix it

Begin typing your search above and press return to search. Press Esc to cancel.

  • Follow Following
    • The Eclectic Light Company
    • Join 3,130 other followers
    • Already have a WordPress.com account? Log in now.
    • The Eclectic Light Company
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Copy shortlink
    • Report this content
    • View post in Reader
    • Manage subscriptions
    • Collapse this bar
%d bloggers like this: