Discussion:
Major macOS High Sierra Bug Allows Full Admin Access Without Password - How to Fix
Add Reply
Jim_Higgins
2017-11-28 22:09:25 UTC
Reply
Permalink
Raw Message
The Tim "Me Too" Cook era

Major macOS High Sierra Bug Allows Full Admin Access Without Password -
How to Fix
http://tinyurl.com/yctwnatx
--
The choices we make reveal the true nature of our character
Neill Massello
2017-11-29 00:35:13 UTC
Reply
Permalink
Raw Message
Post by Jim_Higgins
The Tim "Me Too" Cook era
Major macOS High Sierra Bug Allows Full Admin Access Without Password -
How to Fix
http://tinyurl.com/yctwnatx
Another example of the low priority the Mac has at Apple these days.

Only a a partial fix, but wouldn't choosing "List of users" rather than
the "Name and password" in the Login Options at least prevent this hole
from being exploited at startup without having to assign a password to
root? A non-admin user would still be able to escalate and enable a root
account through the Users and Groups pref pane, but at least it would
stop a wholly unauthorized person from getting access.
nospam
2017-11-29 00:40:36 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Another example of the low priority the Mac has at Apple these days.
the mac is not a low priority.
Neill Massello
2017-11-29 01:01:52 UTC
Reply
Permalink
Raw Message
Post by nospam
the mac is not a low priority.
Oh, I forgot: it ranks higher than Apple TV.
nospam
2017-11-29 01:29:34 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Post by nospam
the mac is not a low priority.
Oh, I forgot: it ranks higher than Apple TV.
absolutely. the apple tv is 'just a hobby'.

the macbook pros had a *major* update a year ago, adding a touchbar,
touch id, thunderbolt 3 and a wide gamut dci-p3 display.

the imac pro is a completely new model in the lineup with very high end
specs, expected to ship in a month (likely in limited quantities).

the new mac pro a work in progress, with an unknown ship date.

macos continues to evolve, with yearly major updates.

that is clearly not a low priority.
Your Name
2017-11-29 05:19:30 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Post by nospam
the mac is not a low priority.
Oh, I forgot: it ranks higher than Apple TV.
The iPod is probably the lowest priority product at Apple these days.
Neill Massello
2017-11-29 05:32:02 UTC
Reply
Permalink
Raw Message
Post by Your Name
The iPod is probably the lowest priority product at Apple these days.
The young will soon think that iPod is a typo.
David Empson
2017-11-29 03:42:10 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Post by Jim_Higgins
The Tim "Me Too" Cook era
Major macOS High Sierra Bug Allows Full Admin Access Without Password -
How to Fix
http://tinyurl.com/yctwnatx
Another example of the low priority the Mac has at Apple these days.
Only a a partial fix, but wouldn't choosing "List of users" rather than
the "Name and password" in the Login Options at least prevent this hole
from being exploited at startup without having to assign a password to
root?
No. There is a keyboard combination to get a user/password prompt even
if you don't have the "Other" icon.

In any case, the login screen can't be used to _trigger_ this bug.
Logging in as root only works if you have already triggered the bug via
an authentication dialog.
--
David Empson
***@actrix.gen.nz
Neill Massello
2017-11-29 05:17:37 UTC
Reply
Permalink
Raw Message
Post by David Empson
No. There is a keyboard combination to get a user/password prompt even
if you don't have the "Other" icon.
Never knew that. Could you be enticed to tell us what it is? I only use
two accounts and haven't enabled the root account since the Dark Ages
(10.1 and 10.2), so I never saw the "Other..." icon until I set a root
password an hour ago.
Post by David Empson
In any case, the login screen can't be used to _trigger_ this bug.
Logging in as root only works if you have already triggered the bug via
an authentication dialog.
Thanks for the clarification. Adam Engst made it sound as though the
whole thing could be initiated at login, even remotely.

<http://tidbits.com/article/17650?rss>
Neill Massello
2017-11-29 05:39:44 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Could you be enticed to tell us what it is?
Never mind. I saw your post in the UK group. (For those who are
wondering, it's Option + Return.)
David Empson
2017-11-29 06:21:10 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Post by David Empson
No. There is a keyboard combination to get a user/password prompt even
if you don't have the "Other" icon.
Never knew that. Could you be enticed to tell us what it is? I only use
two accounts and haven't enabled the root account since the Dark Ages
(10.1 and 10.2), so I never saw the "Other..." icon until I set a root
password an hour ago.
Post by David Empson
In any case, the login screen can't be used to _trigger_ this bug.
Logging in as root only works if you have already triggered the bug via
an authentication dialog.
Thanks for the clarification. Adam Engst made it sound as though the
whole thing could be initiated at login, even remotely.
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.

I've also managed to trigger the bug remotely if Screen Sharing or
Remote Management is enabled: a VNC client can attempt to log in as
root/blank, which fails to log in, but it triggers the bug and enables
the root account, then a second attempt with root/blank works.

Ouch.

I was not able to trigger the bug via File Sharing (with default set of
users). That appears to have its own filtering on the account name so
root isn't allowed.

I haven't worked out a way to trigger the bug via Remote Login (SSH)
because I haven't found an SSH client which allows me to enter a blank
password.

Anyone know of one?

Once the bug is triggered and the root user is enabled with a blank
password, you can disable it again using Directory Utility, then test
again.

I've also seen a report (in a discussion thread on Ars Technica) that a
previously enabled root account and password WAS vulnerable to this, but
a newly enabled root account with non-blank password was not. Something
different about the DirectoryServices database entry created by an
earlier OS verison, perhaps?
--
David Empson
***@actrix.gen.nz
Neill Massello
2017-11-29 07:27:45 UTC
Reply
Permalink
Raw Message
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I've also managed to trigger the bug remotely if Screen Sharing or
Remote Management is enabled: a VNC client can attempt to log in as
root/blank, which fails to log in, but it triggers the bug and enables
the root account, then a second attempt with root/blank works.
Ric Ford reports that the bug exists in the login screen after a
re-installation of 10.13.1.

<https://www.macintouch.com/forums/showthread.php?tid=2147&pid=29037#pid29037>

This is mind-boggling. For two months, Macs running High Sierra have
essentially been wide open.
David Empson
2017-11-29 10:37:57 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I've also managed to trigger the bug remotely if Screen Sharing or
Remote Management is enabled: a VNC client can attempt to log in as
root/blank, which fails to log in, but it triggers the bug and enables
the root account, then a second attempt with root/blank works.
Ric Ford reports that the bug exists in the login screen after a
re-installation of 10.13.1.
Reinstalling the OS on top of itself won't change anything. The setting
is in the Directory Services database which is not rebuilt by installing
the OS. (It would go away if you wiped the drive and reinstalled the OS,
but only temporarily because the same bug could be triggered again.)

Once the bug has been triggered, you need to use Directory Utility to
either disable the root account (which is only a temporary solution -
the same bug could trigger it being enabled again), or enable root and
set a long and complex password.

Once Apple releases their update, the bug should be fixed, and I expect
it will also re-disable the root account if it has a blank password, but
if you did enable root with a long and complex password you will need to
manually disable root again.
--
David Empson
***@actrix.gen.nz
Neill Massello
2017-11-29 16:33:17 UTC
Reply
Permalink
Raw Message
Post by David Empson
Reinstalling the OS on top of itself won't change anything. The setting
is in the Directory Services database which is not rebuilt by installing
the OS. (It would go away if you wiped the drive and reinstalled the OS,
but only temporarily because the same bug could be triggered again.)
I suspected that was the case: Ric Ford didn't say that he installed
High Sierra onto a blank drive.
Daniel Cohen
2017-11-29 11:35:28 UTC
Reply
Permalink
Raw Message
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I tried triggering the bug following Adam Engst's discussion, by opening
the Security and Privaccy system preference and attempting to unlock.

There was no issue after at least six attempts, it would not unlock.

I normally run as a non-admin user. I haven't tried yet what happens if
I run as an admin user.
--
<http://www.decohen.com>
The Labyrinth of the Heart: Changed Myths for Changing Lives
book and e-book <http://www.decohen.com/labyrinth.htm>
Send e-mail to the Reply-To address, not the From address.
Huge
2017-11-29 11:53:24 UTC
Reply
Permalink
Raw Message
Post by Daniel Cohen
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I tried triggering the bug following Adam Engst's discussion, by opening
the Security and Privaccy system preference and attempting to unlock.
You need to type in "root" as the user, then click in the password
box, then unlock. It fails the first time. The do it again and bingo.
Post by Daniel Cohen
There was no issue after at least six attempts, it would not unlock.
I normally run as a non-admin user. I haven't tried yet what happens if
I run as an admin user.
Ah, OK, I am an admin user.

TBH, I'd set a root password anyway;

sudo passwd -u root
--
Today is Boomtime, the 40th day of The Aftermath in the YOLD 3183
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
David Empson
2017-11-29 13:08:08 UTC
Reply
Permalink
Raw Message
Post by Daniel Cohen
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I tried triggering the bug following Adam Engst's discussion, by opening
the Security and Privaccy system preference and attempting to unlock.
There was no issue after at least six attempts, it would not unlock.
Do you perhaps already have an enabled root account with a non-blank
password?
Post by Daniel Cohen
I normally run as a non-admin user. I haven't tried yet what happens if
I run as an admin user.
I can trigger it as a standard user, or as an admin user, on a fresh
install of High Sierra.


Initial state: running as admin user, root disabled (as seen in
Directory Utility while unlocked, showing "Enable Root User" in the Edit
menu, indicating the root account is currently disabled).

Went into System Preferences > Users and Groups.

Created a new standard user account.

Logged out of admin account.

Logged into standard account.

Launched Directory Utility, unlocked using my admin account credentials.

Confirmed the menu still said "Enable Root User" so the root account was
still disabled.

Locked Directory Utility.

Tried to unlock it again, this time entering root and no password.

Upon clicking Modify Configuration in the authentication dialog: pause
then rejected (pause implies the bug just struck).

Clicked on Modify Configuration again: accepted this time with root and
no password.

Confirmed that the edit menu now says "Disable Root User" so the root
account is enabled.

Disabled root user, then went into System Preferences and repeated there
twice (using the padlock in Startup Disk, or Security & Privacy; each
time I went back to Directory Utility and disabled root again).
--
David Empson
***@actrix.gen.nz
Daniel Cohen
2017-11-29 20:25:06 UTC
Reply
Permalink
Raw Message
Post by David Empson
Post by Daniel Cohen
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I tried triggering the bug following Adam Engst's discussion, by opening
the Security and Privaccy system preference and attempting to unlock.
There was no issue after at least six attempts, it would not unlock.
Do you perhaps already have an enabled root account with a non-blank
password?
No. So it is something of a mystery why I could not trigger the bug.
--
<http://www.decohen.com>
The Labyrinth of the Heart: Changed Myths for Changing Lives
book and e-book <http://www.decohen.com/labyrinth.htm>
Send e-mail to the Reply-To address, not the From address.
David Empson
2017-11-30 00:22:41 UTC
Reply
Permalink
Raw Message
Post by Daniel Cohen
Post by David Empson
Post by Daniel Cohen
Post by David Empson
So far I've triggered the enabling of root user with blank password at
all prompts for admin credentials (after being logged in), e.g. the one
presented by Installer, by Finder for authorising an operation in a
protected location, in Directory Utility for unlocking, etc.
I tried triggering the bug following Adam Engst's discussion, by opening
the Security and Privaccy system preference and attempting to unlock.
There was no issue after at least six attempts, it would not unlock.
Do you perhaps already have an enabled root account with a non-blank
password?
No. So it is something of a mystery why I could not trigger the bug.
The bug only happens if the root user has no shadow password in its
directory services datbases entry. That is the normal state for a
disabled root user.

Perhaps yours had an abnormal setup with a shadow password despite the
root user being disabled.
--
David Empson
***@actrix.gen.nz
Huge
2017-11-29 09:08:08 UTC
Reply
Permalink
Raw Message
Post by Jim_Higgins
The Tim "Me Too" Cook era
A comment which has exactly no relevance whatsoever.
--
Today is Boomtime, the 40th day of The Aftermath in the YOLD 3183
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Jim_Higgins
2017-11-29 11:34:00 UTC
Reply
Permalink
Raw Message
Post by Huge
Post by Jim_Higgins
The Tim "Me Too" Cook era
A comment which has exactly no relevance whatsoever.
Steve Jobs initiated, Tim Cook imitates
--
The choices we make reveal the true nature of our character
Huge
2017-11-29 11:51:25 UTC
Reply
Permalink
Raw Message
Post by Jim_Higgins
Post by Huge
Post by Jim_Higgins
The Tim "Me Too" Cook era
A comment which has exactly no relevance whatsoever.
Steve Jobs initiated,
Bwahahahahahahahahahahahahahahahahahahahahahahahahahaha[gasp]hahahahahahahhaha
hahahahahahahahaha[splutter]hahahahahahahahahahahahahahahahahahahahahahaha.
--
Today is Boomtime, the 40th day of The Aftermath in the YOLD 3183
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Huge
2017-11-29 11:51:42 UTC
Reply
Permalink
Raw Message
Post by Jim_Higgins
Post by Huge
Post by Jim_Higgins
The Tim "Me Too" Cook era
A comment which has exactly no relevance whatsoever.
Steve Jobs initiated, Tim Cook imitates
More irrelevance.
--
Today is Boomtime, the 40th day of The Aftermath in the YOLD 3183
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Your Name
2017-11-29 20:00:40 UTC
Reply
Permalink
Raw Message
Post by Jim_Higgins
Post by Huge
Post by Jim_Higgins
The Tim "Me Too" Cook era
A comment which has exactly no relevance whatsoever.
Steve Jobs initiated, Tim Cook imitates
And Johny Ive screws it up completely. :-(

If you want to blame someone, blame the idiot box designer who thinks
he knows anything about software programming and hardware creation. Ive
should not be in charge of such things.
Jolly Roger
2017-11-29 16:53:04 UTC
Reply
Permalink
Raw Message
Post by Jim_Higgins
Major macOS High Sierra Bug Allows Full Admin Access Without Password -
Already patched:

<https://support.apple.com/en-us/HT208315>
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR
Neill Massello
2017-11-29 17:26:36 UTC
Reply
Permalink
Raw Message
Fifteen days after it was revealed by a user on Apple's own support
discussions site. Apple now has a major PR problem to deal with.
nospam
2017-11-29 17:32:24 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Fifteen days after it was revealed by a user on Apple's own support
discussions site. Apple now has a major PR problem to deal with.
no they don't.
Jolly Roger
2017-11-29 18:05:31 UTC
Reply
Permalink
Raw Message
Post by Neill Massello
Fifteen days after it was revealed
Cry harder, snowflake troll.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR
Loading...