HN Gopher Feed (2017-11-28) - page 1 of 10 ___________________________________________________________________
macOS High Sierra: Anyone can login as "root" with empty password
1205 points by vladikoff
https://twitter.com/lemiorhan/status/935578694541770752___________________________________________________________________
cm2187 - 1 hours ago
It really feels like the only thing that made Apple to be less
prone to hacking and malware (and therefore more secure) than other
OS is the lack of scrutiny by hackers and malware authors. This is
a front door open kind of problem.
kylehotchkiss - 2 hours ago
Does this bypass filesystem encryption?
satysin - 2 hours ago
If it does then it means Apple's encryption implementation is
fucked.
tempay - 2 hours ago
Only if the laptop is locked (as the encryption key is already in
memory).
kylehotchkiss - 2 hours ago
Any chance that self clears after an interval?Might be a bad
day to leave the laptop at the table at the coffeeshop when
ordering.
tempay - 2 hours ago
By default no as most people expect things to keep running
when they lock their laptop.There is a setting to immediately
destroy the key when the laptop sleeps. It might be outdated
but [1] should give you a starting point for setting it
up.[1] http://mattwashchuk.com/articles/2016/01/08
/maximizing-filev...
Someone1234 - 2 hours ago
You have a valid user as far as the OS is concerned, so you'd be
able to access encrypted files and copy them off of the machine.
ams6110 - 2 hours ago
It might, if you added "root" as a user able to unlock the disk.
But you'd probably have needed to set a password for the root
account to do that.
Stephen-E - 1 hours ago
While reading this, my mac just prompted me to Upgrade to High
Sierra. I think I'll hold off...
VeejayRampay - 13 minutes ago
Doesn't matter, Apple gets an automatic pass.
thought_alarm - 1 hours ago
This will be a fun fix.They'll not only have to patch the
vulnerability but they'll also have to disable all of the root
accounts that were inadvertently enabled. What a mess.
sizzzzlerz - 1 hours ago
Fortunately, I'm OK. The latest OS upgrade failed to install and
bricked my computer so that no one could log in, let alone root. I
was able to restore it using Time Machine but I don't think I'll go
through that exercise again for a while yet.
anon1253 - 27 minutes ago
you might be able to fix that. I had that too, had to manually
update the preboot. Details are somewhere in here
https://forums.developer.apple.com/thread/80174
Welytech - 1 hours ago
Dope
adambull - 2 hours ago
Confirmed on 10.13.1. As a workaround, once you login as "root",
you can change the password to something else, and the empty
password will stop working.
mholt - 2 hours ago
The HN title is wrong. This reportedly affects High Sierra, not
Sierra.
jtokoph - 1 hours ago
That explains why I couldn't get it to work on my machines that
are still on Sierra. I'm glad I've put off the update.
sctb - 1 hours ago
Updated. Thanks!
symlinkk - 1 hours ago
How can one of the most wealthy companies on the planet, that every
single software engineer would kill to work for, manage to have a
bug like this?Maybe they need to re-think their hiring process,
because clearly something is not working as it should.
equivocates - 2 hours ago
So ? if you log out and log in as root without a password (EEK!),
you can set your own password as root. Once you do, Mac os will no
longer bypass the password.
mcintyre1994 - 1 hours ago
I'm sure many of us can often see how some kinds of bugs managed to
slip through testing/QA, but this is crazy to me given it works on
the login screen if it's happening for everyone on whatever
version: is "user cannot log in as root when root account is
disabled" not a test case? That seems.. insane?
Xeoncross - 1 hours ago
There are thousands of ways you could test this. Like most tests,
having them isn't the same as having good ones.
DonHopkins - 12 minutes ago
I wonder if you can also defeat Face ID by wearing a white face
mask?https://images-na.ssl-images-
amazon.com/images/I/51I4nsyt9AL...
brucepucci - 2 hours ago
To fix this with a workaround open Terminal.app and run the command
"sudo passwd" to set a password. Can't believe this is happening.
mofino - 43 minutes ago
Not a remote vuln, who gives a shit. Physical security >
dyavuz - 2 hours ago
In the meantime, if you'd like to protect your mac, you can set a
password for root by going to:System Preferences > Users & Groups >
Login Options > Join > Open Directory Utility > Edit > Change Root
Password
fredsted - 1 hours ago
Alternatively, there's `sudo passwd`.
cyberferret - 2 hours ago
Standalone iMac here - the 'Join' button is disabled. So is this
vulnerability only for Macs on a network?EDIT: My bad - editing
was locked on that screen. Got it now...EDIT2: Root user is
disabled on mine. Is that enough, given that this bug seems to
create a new root user each time? Should I enable root user and
set a password rather than leave it disabled?
mikeash - 2 hours ago
The bug enables the root user, so leaving it disabled won't
save you. Set a password for root, then you should be good to
go.
dyavuz - 2 hours ago
Mine is currently enabled and since i've set a password, the
bug seems to be gone. I can't authenticate by just typing root
anymore.
mirekrusin - 2 hours ago
Maybe NSA asked for an easy access. Apple is generally good at
making things simple for users.
ianmcgowan - 2 hours ago
Confirming this works, both from preferences, as well as from the
main login screenIt seems like root has no password by default.
Setting one is enough to close the hole. This is
unbelievable!Curious to see what's in
/var/db/dslocal/nodes/Default/users/root.plist before trying this.
shoghicp - 2 hours ago
These are the contents of the file, after converting them from
binary plist to plain xml:
https://gist.github.com/shoghicp/2b529b54b9d70daf192b68e3564...
ianmcgowan - 39 minutes ago
Ah, there's no ShadowHashData or KerberosKeys nodes.
Presumably the code creating that plist is not aware that later
on it's going to be accessed thru layers of other software and
end up as a usable login. To quote Shrek: "Software is like
an onion".
[deleted]
nerflad - 1 hours ago
I didn't think the BSD's allowed a blank root password.
zeveb - 1 hours ago
Well, if they don't then this is a clear indication of the
improvements possible with closed-source software.At least if
it'd been open, maybe someone could have diffed it ?
hartator - 2 hours ago
I guess they were more focused in introducing bugs and less
performant filesystem than security in High Sierra.
Twirrim - 2 hours ago
Those teams are extremely unlikely to be the same ones.
[deleted]
nkkollaw - 1 hours ago
The new Apple is the old Microsoft, and the new Microsoft is the
old Apple.After 8 months of living hell using their overpriced
MacBook Pro, I'm moving to Surface Pro (running Xubuntu, though).
cortesoft - 2 hours ago
Does this effect people who already have a root user with a
password set up?
samwillis - 2 hours ago
No
yxhuvud - 2 hours ago
No.
dasil003 - 2 hours ago
Why is this so far down the front page? Are people flagging it for
some reason?
donarb - 1 hours ago
No, there are two threads about this.
mholt - 1 hours ago
The title is wrong: it affects High Sierra, not Sierra. Edit:
they've fixed the title
buryat - 1 hours ago
AWS ReInvent 2017 is going right now in Las Vegas, the number of
attendees is about 40000, and I'm wondering how many laptops can be
attacked using this technique. The `root` user stays in the system,
so one just need to create it and open SSH quickly, and later they
can do whatever they please.
joshuaturner - 45 minutes ago
This reminds me of the jailbreaking scene a few years back. I was
at an event centered around jailbreaking, and you were able to
ssh into 80% of users iOS devices by using the default root
password, alpine.
the_duke - 1 hours ago
I really hope there's an extra zero in your 40000.
buryat - 1 hours ago
Maybe closer to 35000, but yeah, that's the scale of ReInvent,
last year AWS reported 24000 attendees. I was there last year,
that's a lot of peoplehttps://aws.amazon.com/blogs/apn/why-
sponsor-aws-reinvent-20...
Washuu - 1 hours ago
Unlikely any AWS imaged employee MacBooks at least. AWS IT back
in the beginning of October forbade employees to not upgrade to
High Sierra.
buryat - 1 hours ago
There're a lot of attendees from a lot of companies, they can
be vulnerable.
jeffisabelle - 2 hours ago
I still can't believe more people complain about this being
publicly disclosed than this being possible in the first place. No
one is obligated to know the procedures on InfoSec 0-days and
follow those steps.
zokier - 1 hours ago
Most likely another from of bikeshedding; people don't have real
input on the main matter, so they comment on circumstantial
matters just so they can throw in their 2c
[deleted]
legohead - 1 hours ago
I wouldn't bash the guy. Someone already let him know about his
technical faux pas in a professional manner on his twitter.My
guess is he found this vulnerability on accident, freaked out,
and tweeted about it. Probably has limited infosec experience.
5ilv3r - 5 minutes ago
Or he cares more about doing the right thing than about
following best practices designed to protect the guilty under
the guise of helping users.
mcbridematt - moments ago
Definitely. How many people outside the infosec industry know
that responsible disclosure channels exist?
zeveb - 1 hours ago
> I still can't believe more people complain about this being
publicly disclosed than this being possible in the first place.I
think the problem is due to the fact that they are fans. In this
case, it's Apple, but there's no reason it couldn't be Linux or
Go or whatever. Regardless, any bad news about their hero is
irresponsible to disseminate. We see this same phenomenon in
politics, in sports and elsewhere ? I daresay it's regrettable
human nature.
saagarjha - 19 minutes ago
> I think the problem is due to the fact that they are fans.I
think this is an unfair characterization. Sure, it's hard to
hear that their "hero is irresponsible", but the real reason is
that this kind of behavior puts everyone at risk while Apple
tries to fix it.
eric_h - 49 minutes ago
I've not commented either way on the subject in this thread,
but personally I would much rather have read this as a writeup
2 or 3 months from now after the discoverer had responsibly
disclosed the vulnerability and Apple had a chance to patch
it.On the other hand, I'm glad that I have this information so
I know not to install High Sierra on my work iMac (sitting on a
desk in a WeWork behind a door whose lock would be very easy to
force open) until this is fixed.[Edit: I now see that there's a
simple workaround (change the root password and keep root
enabled), so I'm all for "irresponsible disclosure" in this
case]
Asmod4n - 2 hours ago
Works with "su - root" too in a Terminal.
Shank - 2 hours ago
With user switching enabled as a username + password combo, I was
able to login to the root account from the login screen with no
password on 10.13.1. It's not just a UI bug, it's a full on
authentication bypass.
coreymayo - 2 hours ago
I'm able to do this as well, login as root with no password from
the login screen.
k4ch0w - 1 hours ago
I just have no words, it seems intentional. They may want to review
their build pipeline to check someone didn't manipulate the source
code before it was signed. I haven't seen an easy root priv-esc
like this in a long while.
donatj - 2 hours ago
I can't seem to reproduce it locally. 10.13.1? Anyone else having
issues?I've upgraded a through a couple versions of OS X on this
machine - maybe that makes a difference?
hrrsn - 2 hours ago
Worked fine for me on 10.13.1.
drunken-serval - 2 hours ago
It took 3 tries for me and then it worked.
yxhuvud - 2 hours ago
Perhaps you have a root password set?
lolc - 1 hours ago
Reminds me of the time Mac OS X would trust any NIS server in the
local net to authenticate local root. Can't find the story though.
Did that even happen?
notanai - 2 hours ago
Can this be used remotely? Edit: Yes, after turning on Remote
Management on my second mac I was able to log into it using Remote
Desktop, account root and no pw. It only works after getting
physical access once.
[deleted]
djrogers - 1 hours ago
I tested this by logging in as root at a preference pane then
attempting to connect via ssh and screen sharing (both enabled)
using root with no password. It did not work.Not sure if you'd
get different results after logging in as root at the login
screen...
rcruzeiro - 2 hours ago
Been wondering that myself since it seems that this also happens
with the login screen.
pilif - 2 hours ago
It only works after getting physical access once to enable the
root user by gibing any password UI the root user with no
password (which will enable the local root account, which is also
why it fails the first time around)
swozey - 2 hours ago
Yes, I just had a coworker test it after I enabled remote
management and they used screensharing.app. I didn't even get
notified a user remoted in.. never used screen share, that seems
awful. Had to look over and ask if he was in.edit: I should say,
I did test this locally first so I don't know if a fresh machine
that hasn't done it will do the same thing and let a remote
account enable root.. Would like to hear if anyone tested it
remotely WITHOUT doing it locally first.
zaro - 2 hours ago
Classical click and bait title. First promises that you'll become a
hacker, and then when you actually click the tweet is deleted.
Murrawhip - 2 hours ago
Isn't deleted for me.
TrueSelfDao - 1 hours ago
Serious 0-day on Twitter. How exciting!
rderewianko - 4 minutes ago
Myself and others blogged about solutions:
https://www.rderewianko.com/10-13-root-password-oh-my/
https://derflounder.wordpress.com/2017/11/28/blocking-logins...
DonHopkins - 35 minutes ago
They could have at least used "rms" instead of a blank password.htt
ps://www.reddit.com/r/linux/comments/7hj6v/i_use_my_login...
tribune - 1 hours ago
I would say I'm surprised such a serious bug made it out, but after
the A ? thing who knows what's going on at Apple
mratzloff - 2 hours ago
Wow. As if I needed another reason to never "upgrade" to High
Sierra...
MentallyRetired - 2 hours ago
Apparently El Capitan is vulnerable too.
LeoPanthera - 1 hours ago
Can't reproduce on El Cap.
mfrw - 1 hours ago
I may not be an apple fanboy, but I admit, I really miss Jobs, and
his commitment to quality. Apple has just been minting money and
forgot all about its core values.
tombrossman - 2 hours ago
Fellow Linux users, please keep the snark in this thread to a
minimum. Here's just one recent example why, there are more:
http://www.omgubuntu.co.uk/2017/05/ubuntu-guest-sessions-log...
MentallyRetired - 2 hours ago
Hypocrisy is a reason to keep snark at a minimum?
trumpRektYou - 5 minutes ago
spotted the applefag.
zeveb - 1 hours ago
I'm a Linux desktop (and laptop!) user, and I agree (I haven't
even used macOS in almost twenty years). Anyone remember the
Debian OSPRNG issue?These sorts of bugs can happen anywhere. We
all need to bear that in mind.One notable difference, though, is
that macOS is proprietary software. Apple have sold their users
a product and haven't respected their users' right to use, modify
& distribute that product; their users have never had the ability
to inspect the macOS source for this kind of problem. Thus,
responsibility for this disaster rests solely on Apple's
shoulders.
igetspam - 2 hours ago
Linux != UbuntuLinux didn't have that problem, a single vendor
did. You could say the same for Apple except they are the single
vendor. That stupid security trick in Ubuntu only impacts subset
of a subset of Linux _desktop_ users which is a pretty small
subset of computer users as a whole. When Apple does something
like this, it impacts a much larger share of the world
population.So how about we keep the snark to an appropriate level
based on the impact to the world population? ;)
arghwhat - 2 hours ago
As Linux user who does kernel-mode development for a living,
root escalation bugs come a dime a dozen. And, well, Linux runs
everything but the average persons laptop, so the impact, while
different, is much greater.So lets keep the snark to an
appropriate level, shall we?
igetspam - 57 minutes ago
Are you arguing that privilege escalation is the equivalent
to passwordless root login? I mean, I guess you squint just
right you could say that a logged out user having zero
privileges being able to login as a user with all privileges
is an "escalation" but that's one hell of a stretch. We
haven't even gotten to snark yet though.We can point to
avenues for remote root all day but I don't recall any that
are/were as simple as "just hit [enter] to get root" that
impacts the shared attack surface that impacts all Linux
systems.NOTE: I did not go and search NVD before writing this
reply but I did stay at a Holiday Inn Express once.
dsp1234 - 2 hours ago
Number of mentions of "Linux" outside of your thread comment
chain: 0
thanatropism - 1 hours ago
Anyone in a position to short AAPL? It's apparently 6bps up in
after hours trading but that's very low
liquidity.https://finance.yahoo.com/quote/AAPL?p=AAPLA higher risk,
higher leverage bet: buy some put options the milisecond markets
open:http://www.nasdaq.com/symbol/aapl/option-chain
bennyg - 1 hours ago
Reminds me of an exploit back in 10.7 where you could create a new
admin privileged user from a non-admin account using some bash
commands. Used that to add Xcode to my work computer at college so
I could fool around with learning how to code when I was at work.
taurath - 1 hours ago
This is near Windows-95 levels of bad - at the very least you need
to already be logged in
myth_buster - 2 hours ago
Is social media the goto for reporting security vulnerabilities in
2017?If I remember correctly, one is supposed to make it public
once patched or in event of no response, no?Edit: What is
"Responsible Disclosure"[0]?[0]
https://en.wikipedia.org/wiki/Responsible_disclosure
FireBeyond - 2 hours ago
Where is Joe Random's obligation to responsibly disclose?To whom
does he owe that obligation? Apple? The public? Both? Why?
TallGuyShort - 51 minutes ago
In my opinion they don't "owe" anyone that obligation, unless
it's a contractual obligation associated with using a Mac. But
just because it's not owed to anyone, doesn't mean there isn't
a nicer way to handle it just to be nice.That said, I don't
immediately see evidence that this gentleman is in the security
field, and perhaps isn't aware of responsible disclosure. Full
disclosure isn't the worst thing in the world.
cotillion - 2 hours ago
This is one of those cases where responsible disclosure just
means you're doing the job one of apples automated tests should
be doing.
DonHopkins - 6 minutes ago
Twitter's also the goto for banning trans people from military
service, attacking freedom of the press, threatening to declare
nuclear war, and all kinds of other things too.
ams6110 - 2 hours ago
Someone notices that they can log in as root with no password. In
2017, reflexively tweeting about it seems pretty unsurprising.
fredsted - 2 hours ago
Seems like the guy just discovered this by accident. It's not
like you'd have to be a security engineer to stumble upon this.
donatj - 2 hours ago
I think the difference is if the problem is discovered by Joe
Schmoe or a security researcher.
testvox - 1 hours ago
Full disclosure is also a form of responsible disclosure.
manwe150 - 2 hours ago
I'm on Sierra and haven't been able to reproduce. But does anyone
know if it respects pam.d "nullok" and I could just delete that
option? /etc/pam.d$ grep -RI nullok /etc/pam.d
/etc/pam.d/authorization:auth required
pam_opendirectory.so use_first_pass nullok
/etc/pam.d/checkpw:auth required pam_opendirectory.so
use_first_pass nullok /etc/pam.d/screensaver:auth
required pam_opendirectory.so use_first_pass nullok
Asmod4n - 2 hours ago
Tested it in the terminal with "su - root". Doesn't help. Or does
one need to reboot after it? UPDATE: No effect after rebooting.
realworldstuff - 1 hours ago
People going on about responsible disclosure when this is such a
gross violation of CUSSE:
https://web.archive.org/web/20170712120031/http://www.cusse....
lostgame - 1 hours ago
#whyidontupgradeUntil Apple forces me to with a required xCode
update for the newest iOS SDK...>.>
pmoriarty - 2 hours ago
Has no one been running password crackers against OSX this whole
time?
fixermark - 2 hours ago
"OSX the more secure OS because nobody tries to hack it,
CONFIRMED." ;)
pilif - 2 hours ago
A quick mitigation workaround: If you follow the steps here
https://support.apple.com/en-us/HT204012 to disable the root
account until the point where you open and authenticate the
Directory Utility, in the Edit menu there's a "Change Root
Password" option.Set a good password there and disable the root
account again.Now people making use of this vulnerability will
still be able to re-enable the root account (that's why it fail the
first time - root is default off, but this bug enables it), but now
there will at least be a useful password set.
Asmod4n - 2 hours ago
if you disable the root account you can log in again without a
password, even when you set one.
aezell - 1 hours ago
Should I leave my Mac unattended until this is resolved?
oneeyedpigeon - 1 hours ago
Enable the root account and set a (obviously, strong) password
for it. Keep calm and carry on.
fulafel - 1 hours ago
You can keep using it.
tomduncalf - 1 hours ago
I wonder what is going on with software quality and testing at
Apple. It feels like recently there have been quite a few issues
like this (the FileVault password bug, numerous issues with iOS 11,
the issue that totally broke iOS Safari a couple of years ago)
which should have been fairly easily caught, especially given the
limited range of devices their software runs on.I know testing is
hard, but a company with Apple?s resources shouldn?t be making slip
ups like this. It suggests some real issues such as lack of
unit/automated tests and/or sufficient release testing, which
pretty urgently need addressing.Anyone got any inside scoop?
cm2187 - 1 hours ago
iTunes had QA problems for more than 10 years, only the early
versions were really solid. I am not sure that it is a recent
problem.
tomc1985 - 1 hours ago
Subjectively it feels like Apple bugs have become larger and
more prevalent, over the last few years. That and IMO clean
OSX/iOS installs don't quite feel as polished as they used to.
(I stopped using Apple products, except for a MBP, for a few
years and recently started using them again, and the MBP still
runs 10.10 for precisely this reason) The last solid OSX
release was Snow Leopard
mholt - 1 hours ago
> Anyone got any inside scoop?I have a feeling that anyone who
does would get fired for commenting here about it.
ianmcgowan - 1 hours ago
You have to think that whoever was responsible for testing this
is going to get fired. This is egregiously bad...
fmihaila - 1 hours ago
This is a management issue. It shouldn't be possible for such
a mistake to slip into production code. It has happened more
than once in recent times.
adamio - 1 hours ago
Repressive collusion to fix salaries and restrict industry
movement, doesn't really inspire your employees to try their best
[deleted]
rogaha - 1 hours ago
I've experienced lots of issues wiht IOS and High Sierra as well.
Apple definitely reduced their software quality since IOS 11.
2trill2spill - 1 hours ago
It seems apple's software has been trending down in quality since
Snow Leopard.
thanatropism - 1 hours ago
I'll agree that Snow Leopard is the high water-mark.
e5an - 13 minutes ago
It can't be a coincidence that this was the last major
release before Steve Jobs died.
sanityUnbounded - 44 minutes ago
I have been in the apple ecosystem for about 10 years. For a
company that has been priding itself on end user security,
the bugs that have been creeping their way into the OS are
just... disappointing. What is the point of paying a premium
for a well polished hardware/software bundle if the OS is
malfunctioning in a non trivial manner. Design? Right now
when I use my calculator app on my iPhone and do 2+2+2 I get
24. That's a pretty awful design. Actually, it's a lie.
mikeokner - 32 minutes ago
3rded. I wish time stopped at 10.6.8.
zaidf - 1 hours ago
Unrelated to Mac OS but I used to wonder all the time why iTunes
connect was so shoddy. I got my answer when I learned Apple had
outsourced a ton of backend work including iTunes Connect, App
Store backend to Infosys in India.They?re now retreating from
that strategy: https://factordaily.com/apple-to-pull-back-
development-work-...
umanwizard - 1 hours ago
Anecdotal but I started noticing a decline in quality after Steve
Jobs died.
mikestew - 1 hours ago
Take this for the anecdata that it is. I interviewed at Apple,
referred by old Microsoft friends that worked there. As I was
trying to get a feel for things before the interview, I asked
about the software testing. I was told, "don't expect what you're
used to at Microsoft". The reference there is from when Microsoft
often had more testers on a team than devs (ah, the good ol'
days). The summary of what I was told by friends, and the
questions I asked during the interview, is that testers at Apple
aren't the testers that Microsoft used to have. Microsoft had
testers working in MS Research, researching ways to better test
software. Apple, from the impressions I got, is doing good to
have testers than can write "hello, world". This was from the app
side of things, not OS; I don't know if it's any different on the
OS side.But since I don't work there, I have no good inside info.
But just from gut feel, I don't think my anecdata is too far off
the mark. Based just on the bugs made public, I just don't get
the impression that there are testers at Apple whose sole reason
for being there is to tear into a piece of software and break it.
There was a bug a few weeks ago posted to HN that I commented on.
I don't have a link without digging through my comments, but it
was something along the lines of "how could a tester not find
this in five minutes of exploratory testing?" This bug is
similar. It would take more than five minutes, but were this my
area to test I'd pick at it once in a while when I had a few
minutes. As I pick at it, I wouldn't expect to find anything, but
I've got a minute between builds, so instead of randomly clicking
Facebook I'll randomly click this dialog. What did the dev
forget? What weird state was not accounted for? Some kind of
state overflow if I click the button enough times? Shove some
Unicode in there, that didn't find anything; meh, maybe I ought
to move o...hey, wait a minute. Did that thing just log me in as
root?But my gut says that Apple doesn't employ a lot of testers
like that.
yodsanklai - 1 hours ago
> But since I don't work there, I have no good inside
infoActually, I've been wondering why I hear less about people
working at Apple than at other big tech companies. It seems
everyone and their mother work at Google or Facebook, but no so
much at Apple. Do they have less software engineers, or their
employees are required to be more discrete?
OJFord - 1 hours ago
> or their employees are required to be more discrete?Yes, I
believe so. I've heard there are strict requirements on even
internal discussion. (Who you can talk to; about what;
where.)
jsmthrowaway - 7 minutes ago
Yes, but social media training is more at play here.
Employees are instructed from day 1 not to discuss Apple
business on social media, and the constitution of "Apple
business" is left intentionally vague. There are people who
actively report seeing it, and people do get walked.General
sentiment is that even saying the word Apple online is a
bad idea. Recently, they've acknowledged that there are
federally protected things you can say, like your salary
sucks or your manager is an asshole, but they don't go out
of their way to explain that to you.
skc - 1 hours ago
Apple probably doesn't take too kindly to their employees
talking about their work. I'd imagine it's a fire-able
offense.
chris_7 - 57 minutes ago
it is everywhere else too, but people do quit...
wil421 - 1 hours ago
Could it be the level of secrecy around Apple? I see
responses for Google and Facebook devs on HN a lot but never
Apple.The only people I know locally that work for Apple are
remote customer support folks.
mikestew - 57 minutes ago
Do they have less software engineers, or their employees are
required to be more discrete?I know but a few that work at
Apple, and of those few they strike me as less forthcoming
than the multitudes I've worked with and know at Microsoft.
I've wondered if part of that is because Microsoft previews
/pre-announces just about everything, whereas Apple (mostly,
and not so much anymore) announces it when the shipping
trucks show up at the local Apple store.So the outcome from
the Microsoftie is, "it'll do this that and the other, but
that's all I can say right now." From a recent conversation
with an Apple employee: "they make me go in a special room to
use the hardware, and I can't work from home. That's all I
can say."Probably more so, last I looked, Apple has
considerably fewer software employees than the other big
companies.
saagarjha - 10 minutes ago
> Probably more so, last I looked, Apple has considerably
fewer software employees than the other big companies.I
don't think this is true. Apple, Google, and Microsoft all
have on the order of 100K employees.
jsmthrowaway - 7 minutes ago
Keep in mind that Apple directly employs retail staff.
[deleted]
jenoer - 55 minutes ago
As a Tester myself, I cannot understand why this is not covered
by either unit tests or behavioral tests. Clicking dialog
buttons in rapid succession is what we (should) do once in a
while. Especially in core functionalities such as the login
screen. It's one of the first screens you see as a tester.
And you have default usernames, be it enabled or not.For
example, I do not own an iPhone, but at work, I made a bet with
my colleague (jokingly) that I could break _something_ on his
phone in a few minutes.I did not have his finger print or pin-
code, so I was very limited, I even joked "I don't need that,
give it here!"Finding out I only had a hand full of options, I
focused on the emergency dialer. As any good tester would be
curious about, I wanted to check the max field length, so I
entered digits, copy/paste it a few times, copy/paste that
string, ("wait, no limit? Not even at 1000? why?") and so on,
until I noticed the interface became laggy, so of course, I
kept going.Boom, suddenly back at the login screen, tried to
open the emergency dialer, but got a full blank white screen,
in the meantime the phone started heating up substantially.
Since it was a new Phone (iPhone 7 with iOS 10.x I believe) and
the dev getting nervous, we decided to reboot it. That fixed
the issue. (Curious if this is still an issue in iOS
11.x)TL;DR: As a tester this simple curiosity should be in your
blood, and especially covered in behavioral tests when your
software has been around for 5+ years.
[deleted]
spamizbad - 1 hours ago
The loss of people like Avie Tevanian and Bertrand Serlet took
its toll.Are there any "(tech) household name" engineers doing
system-level work on iOS/macOS these days? It seems like Google
and Facebook have a slew of them.
socalnate1 - 47 minutes ago
A [?] don't know what you are talking about.
bangonkeyboard - 1 hours ago
macOS and iOS updates at Apple are now inextricably tied to new
iPhone releases. There is a strict yearly deadline that the teams
sprint toward, a timeline imposed by marketing rather than
readiness. This affects prioritization of which features are
pursued, where they lie in the stack, and how polished they
get.Insufficient testing at today's Apple is not limited to
software. They bragged about their extensive input testing lab
[0] when the new line of Magic accessories was released, but the
Magic Keyboard with Numeric Keypad launched last summer had all
of its inventory pulled from the channel last month because users
discovered that the model was so thin that its midsection bowed
over time.[0]: https://medium.com/backchannel/what-i-saw-inside-
apple-s-top...
kifleswing - 40 minutes ago
Where did you hear that the keyboard was pulled from the
channel? It just seems to be out of stock for me.
komali2 - 37 minutes ago
Haven't deadlines at Apple always been driven by marketing? I'm
looking for a source but I remember a story where the product
director for iPod was told by steve jobs "make it simple, fast,
beautiful, and have it done by Christmas."
warent - 1 hours ago
Everything ends in tears when managers mix up targets/estimates
with commitments
nikofeyn - 1 hours ago
it is also that they pursue features just for the sake of it.
things get moved arund in the iPad from release to release for
no good reason, often going backwards in usability. every
release i have to relearn simple things like how to manage the
screen brightness. i really wonder what they are thinking
internally other than ?we need to shake things up to make it
appear we?re doing something with stale products?.
maxxxxx - 14 minutes ago
It seems phones and tablets have reached the stage where
laptops were maybe 15 years ago. All the major features are
done and innovation is pretty much over. So they have to make
a lot of cosmetic changes that look like activity.
wonderous - 1 hours ago
Apple has always had QA issues, the difference now is that
they?re increasingly tested by the users, hackers, etc.
ben_w - 1 hours ago
Difference? MacOS userbase hasn?t changed much since 2011, I
thought?
eric_h - 55 minutes ago
I've no information on how good this site's data is, but
https://www.statista.com/statistics/218089/global-market-
sha... seems to show that from 2013-2017 global macOS market
share has increased from 7.95% to 11.3%.
notanai - 2 hours ago
You can just type root in the login window to get System
administrator access.
sccxy - 2 hours ago
I wouldn't have thought that NSA backdoors are so simple
tempodox - 2 hours ago
On my system, the trick doesn't work. But then, I did explicitly
set a non-empty root password.
TonnyGaric - 2 hours ago
Not cool to disclose this kind of bug on Twitter.
estevaovix - 2 hours ago
The solution for now is to set a passwd for root... this is
ridiculous
mikeash - 2 hours ago
For those who can't make it happen, it requires that the root
account is disabled, which is the default. If you already enabled
the root account for some other reason (which apparently I had on
one of my Macs, although I don't know why) then that prevents it
from working.It seems like the best mitigation for the moment might
be to enable the root user and set a password for it.
Asmod4n - 2 hours ago
Once you disable the root account you can log in without a
password again :/
mikeash - 2 hours ago
Yep. If you keep it enabled and set a good password then you
should be OK. I think.
jmuguy - 2 hours ago
Time to install Afterdark on all the computers in the Apple store.
Confirmed here, 10.13.1.
jrowley - 2 hours ago
And I just googled afterdark at work... haha thanks!
mrkd - 1 hours ago
Title should be changed to 'macOS'I initially saw this thinking it
didn't affect Sierra or High Sierra.
davidkuhta - 1 hours ago
Now you have me confused, is it just High Sierra or Sierra as
well?
perryh2 - 1 hours ago
It does not work for me using Sierra.
davidkuhta - 1 hours ago
Awesome, thanks.
[deleted]
arghwhat - 2 hours ago
It seems to activate the root user with an empty password if you
try, as an admin user, to use "root"/"" as credentials in a System
Preferences authentication prompt.It does not work if you are not
admin. It does not work if your root user is enabled and has a
password set. If you tried the vuln, you should set a password for
the root user ("sudo passwd root").
michaelmcmillan - 2 hours ago
Are we really ready for self-driving cars?
https://www.youtube.com/watch?v=4G1Boh-URIM
naasking - 1 hours ago
> Are we really ready for self-driving cars?Firstly, car
automation is machine learning, not programming. Completely
incomparable.Finally, we've known how to prove the absence of
bugs for decades. It's not a matter of not knowing how, it's
about incentives to do it right.
michaelmcmillan - 1 hours ago
Is the authentication subsystem in a Tesla machine learning as
well?
ky738 - 2 hours ago
I will take malicious improper analogy for 100
michaelmcmillan - 2 hours ago
Please point out the discrepancy.A Tesla has ~ 100.000.000 [1]
lines of code. Considering this post, do you think we are
sufficiently educated in software security to produce secure
self-driving cars?Elon Musk: "I think one of the biggest risks
for autonomous vehicles is somebody achieving a fleet wide
hack" [2].[1] https://bit.ly/KIB_linescode[2]
https://www.youtube.com/watch?v=4G1Boh-URIM
[deleted]
abestic9 - 2 hours ago
These companies have completely different operating systems,
network ACLs, software update policies and subsystems that
affect certain mechanical features.By your logic, we should
not fly any modern commercial or military aircraft or
spacecraft, live within a certain radius of any power or
hazardous chemical plant, place any dependency on any first
world country's health care network, including life support,
or invest in any company or stock.Like most things in life it
comes down to a security/convenience risk/benefit compromise.
michaelmcmillan - 2 hours ago
> These companies have completely different operating
systems, network ACLs, software update policies and
subsystems that affect certain mechanical features.Are you
claiming that this could not have happened with Tesla? If
so, please explain why.> By your logic, we should not fly
any modern commercial or military aircraft or spacecraft,
live within a certain radius of any power or hazardous
chemical plant, place any dependency on any first world
country's health care network, including life support, or
invest in any company or stock.Up until now the benefits
have clearly outweighed the risks, but that does not mean
it will continue to do so.
jessriedel - 2 hours ago
This is a much more interesting comment than your initial
quip. Next time, consider leading with this rather than
unnecessarily antagonizing people.
mikeash - 1 hours ago
How much of that code is safety critical? I occasionally see
misbehavior from my Tesla's center screen, like the network
connection failing, or audio glitches, or even the occasional
spontaneous reboot. This can be mildly annoying but it
doesn't worry me because I know that the center screen is
separate from the stuff where bugs can actually get me
killed.
michaelmcmillan - 1 hours ago
"On Thursday October 24, 2013, an Oklahoma court ruled
against Toyota in a case of unintended acceleration that
lead to the death of one the occupants. Central to the
trial was the Engine Control Module's (ECM)
firmware.Embedded software used to be low-level code we'd
bang together using C or assembler. These days, even a
relatively straightforward, albeit critical, task like
throttle control is likely to use a sophisticated RTOS and
tens of thousands of lines of code. " [1] [2][1] https://ww
w.edn.com/design/automotive/4423428/Toyota-s-kille...[2]
https://www.embedded.com/electronics-blogs/barr-
code/4214602...
mikeash - 1 hours ago
Sure. My point is just that you can't bring up the total
number of lines of code here, because most of those lines
aren't in any way related to any safety-critical system.
If you want to talk about how much code there is which
puts you at risk, you need to look at that particular
subset of code.
michaelmcmillan - 1 hours ago
I think it is safe to assume that complexity is highly
correlated with number of lines of code. And with
complexity grows bugs.On the surface, this particular
exploit on macOS seems to be caused by a totally
unrelated subsystem (security vs. GUI).
mikeash - 1 hours ago
I don't see any evidence that this exploit is related to
the GUI at all. The GUI just happens to be the easiest
way to do it. Other commenters have mentioned that you
can use the exploit with `su`.In any case, in a desktop
system you shove everything together and then try to
modularize it with good design and weak tools like UNIX
processes. In a car, the safety-critical systems are
literally running on separate hardware with limited
communication over a specialized data bus. Of course it's
still possible for them to have bugs or even exploits,
but the complexity of the infotainment system is
irrelevant, aside from making it a potential jumping-off
point for using an exploit in the safety-critical
systems.Counting the infotainment system here makes about
as much sense as counting the number of lines in Windows
when talking about a Mac vulnerability because a Windows
machine could be used to launch an attack.
michaelmcmillan - 38 minutes ago
"Apple root bug appears to be triggered only by logins
coming from http://com.apple .loginwindow. Running "su"
with a blank password won't get you a root shell." [1]As
for your subsystem argument, explain this: https://www.yo
utube.com/watch?v=OobLb1McxnI&feature=youtu.be...[1]
https://twitter.com/0xAmit/status/935609423485169664
Dylan16807 - 18 minutes ago
> I think it is safe to assume that complexity is highly
correlated with number of lines of code. And with
complexity grows bugs.But it's still wrong to focus on
total complexity. You want to look at the complexity of
the relevant system.
michaelmcmillan - 14 minutes ago
Not so sure: "Apple root bug appears to be triggered only
by logins coming from com.apple.loginwindow. Running "su"
with a blank password won't get you a root shell."
https://twitter.com/0xAmit/status/935609423485169664
[deleted]
MentallyRetired - 2 hours ago
As a programmer, the thought terrifies me.
glhaynes - 2 hours ago
As someone who tries to do risk analysis, the prospect of
sticking with human drivers because of fear of software bugs
(which inevitably will kill, just in much smaller numbers)
terrifies me.
jtbayly - 2 hours ago
The fear is not of bugs killing people. The fear is of bugs
allowing people to kill people.If ISIS was able to hack a
major fleet through one such bug, do you think for a single
moment they wouldn't make use of it to kill many people?
ovao - 1 hours ago
Which is a legitimate fear, and substantial effort should
go into preventing such bugs, but any sufficiently
determined person doesn't need to exploit a software bug to
be able to kill others. ISIS appears to be quite effective
at simply convincing its members to directly and
voluntarily engage themselves in such acts.
qrbLPHiKpiux - 2 hours ago
Could a programmer be held liable for any bad outcomes?
[deleted]
zerostar07 - 2 hours ago
technically, after they are hacked they are no longer self-
driving.
crispinb - 2 hours ago
Possibly not, but the death & maiming stats everywhere show we're
absolutely not ready for human-driven ones.
carapace - 1 hours ago
Thank youI imagine a Twilight Zone episode... Go back in time
to before cars were invented and imagine some Mephistopheles
offering the bargain: "You'll fly like the wind over hills and
mountains, making a journey of days in mere hours!" What the
catch? "For each mile traveled a certain number of people
chosen at random must be put to death or maimed."He would go on
about how the chances of someone you love being chosen for
sacrifice were infinitesimal, and the benefits to all were so
great and so obvious...("Also, it will poison the air and
water, and force you to become dependent on fuel sources that
destroy life and engender wars.")
Oxitendwe - 2 hours ago
No. I am also skeptical of more modern cars with complex
computers. The thought of being in one scares me.
ovao - 2 hours ago
I think the question you're fundamentally asking is "are we ready
for imperfect systems with potential vulnerabilities?", and the
answer to that question has been the same since the advent of
software.
therealdrag0 - 2 hours ago
They don't need to be perfect. Just better than humans.
[deleted]
llamataboot - 28 minutes ago
That twitter thread and lots of the comments are missing the point.
MANY people don't know about what the ethics of reporting
vulnerabilities are, they just want to say something and get it
fixed. yes, it probably would have been better if this person had
gone through proper channels, but there's no evidence they did it
for the lulz/fame.In this case the bug is so bad and egregious,
that publicizing it with the fix might have been the best thing to
do -- no telling how many people have already discovered this or
how long it would take Apple to fix.Yes, let's educate each other
about what responsible disclosure WITH A DEADLINE TO FIX looks
like, but don't assume this person just wanted internet points. And
now that the report and a workaround are out there, at least it can
be mitigated personally.Though I imagine there will be some SERIOUS
hijinks that result from this until Apple fixes it because it is so
easy to do. :(
zaro - 2 hours ago
Wow. This is fun. I remember my Windows98 had the same feature. You
just use Administrator with empty password and you're in. Apple is
finally catching up.
ksk - 7 minutes ago
AFAIK, its not really a security bug. Windows 98 didn't really
have any concept of user security. With the default install you
could always cancel out of the login dialog and use the guest
account. Every account was an 'administrator'. The user name /
pwd was mainly to store the OS customization settings like UI
colors and such.
pkaye - 2 hours ago
Did Windows98 even have administrator role? I mean FAT file
systems don't even have file ownership right?
lerpa - 1 hours ago
It did. But didn't have security tied to the fs.
romanovcode - 2 hours ago
Exactly my thoughts. I remember this, I think even early versions
of WinXP had this feature.
Grollicus - 2 hours ago
Exactly early versions of Windows XP had this: They removed the
Administrator user from their graphical login splash but when
booted in rescue mode ("Safe mode") you could just type in
"Administrator" with no password and were in. On Win98, you
could just cancel the login.
anon1253 - 2 hours ago
I believe hitting "cancel" was enough.
https://www.youtube.com/watch?v=DE5PRW-AR7QAlso reminds me of
https://youtu.be/BVL8_ne4WZo?t=19s
dabernathy89 - 2 hours ago
from the only top-level comment on that video:> That isn't a
login screen for Windows 98, it's a login for Microsoft
Networking (which the box shows). If you had any shared mapped
drives, network privileges, etc they wouldn't work if you
cancelled. If you had multiple profiles set up, you wouldn't
get those either. Win98 wasn't intended to have password
security.?
anon1253 - 2 hours ago
Good point. Been a while. Windows 7 also has/had an
interesting one https://www.youtube.com/watch?v=zwO4YqSc4XE
but it's much more involved.
mrkstu - 2 hours ago
verified on latest build of 10.13.1 (17B48).
migueh - 28 minutes ago
If I could just use Mavericks and develop apps for last iOS
release, that will be great. But I should update to High Sierra. I
hate this.High Sierra seems to be focused in Emojis. Urghh
quotha - 1 hours ago
I tried it anyway and it does not work! I'm running version
10.13.1
yborg - 1 hours ago
Try one more time.
erikdared - 1 hours ago
I'm using 10.13.1 and it did work for me. You have to first fail
a login in one of these dialogs (did it with my current user and
no password) before doing root with no password.
thesephist - 2 hours ago
Encouraging users to "try it" is dangerous here. Recreating the bug
enables root user across the system, and most users won't know how
to disable it.TechCrunch, if you're reading this... please
discourage people from reproducing the bug.
sephicr - 1 hours ago
Yes, but the most secure thing to do at this point _is_ to
recreate the bug and then set a password for the root
user.Otherwise the hole is still there for others to exploit.
pilsetnieks - 1 hours ago
If you set a root password, this bug still works, it seems to
reset the root password.Edit: I was partly wrong. The bug still
works if you disable root afterwards, then it reenables and
resets it.
ukblewis - 13 minutes ago
Yeah, you?re safe if you keep the foot account alive and you
set a password for root. At least as far as I can tell...
hw - 1 hours ago
There?s no need to do this yourself to verify it. Doing so
creates a ?root? account that others may be able to take
advantage of if you don?t disable it.That should be much higher
up in the article.
kreeWall - 1 hours ago
Can you talk about how to correctly disable the root account if
someone did try it?
martin-adams - 40 minutes ago
If you're wondering how to disable it, the menu option can be
found here: https://support.apple.com/en-gb/HT204012
devindotcom - 2 hours ago
I was wondering about that. I'm going to change this.
[deleted]
eganist - 1 hours ago
Thanks :)
AdamJacobMuller - 2 hours ago
Enables root access in what way?
selectodude - 2 hours ago
Mac OS X doesn't have a real root account, it uses sudo
exclusively. This enables a true root user shell.
AdamJacobMuller - 1 hours ago
The root account always exists.Playing around with
disable/enable and the exploit: Root always has a /bin/sh
shell "Disable root user" removes the ShadowHashData from the
directory services entry for root The bug sets ShadowHashData
to the hash of an empty string.Now, ShadowHashData is a
complex DS entry. I've never seen passwords represented this
way in other OSX versions. I think this password storage
format is new.I strongly suspect the bug here is one related
to OSX attempting to upgrade the password to the new storage
format and when it does that, it inadvertently stores the
password with a hash of null.This should be very trivial for
Apple to fix that (and thus "disable" the root user) by just
removing any ShadowHashData that is solvable by an empty
string.
arghwhat - 1 hours ago
Your comment suggests that it is related to users with
older, pre-High Sierra directory entries. That is, upgraded
rather than freshly installed machines that leave older,
pre-ShadowHashData intact. Is this correct?
jsmthrowaway - 14 minutes ago
No, I reproduced on freshly-installed High Sierra on two
machines.
Asmod4n - 1 hours ago
Works with El Capitan too.
[deleted]
thomastjeffery - 1 hours ago
It can already be activated remotely:https://gfycat.com/gifs/deta
il/sentimentalnaiveantelopegroun...
CrendKing - 1 hours ago
This bug exists regardless of user reproducing it or not. If
there is anything good, reproducing it actually brings awareness
to the user (make them change the password maybe). Hacker will
"enable" the root user anyway.What should be done is that Apple
releases fix to this problem.
devindotcom - 1 hours ago
Yeah that was my thought initially too but there may be
invisible ways to leverage an existing root user that we're not
aware of. After all, this bug exists...
stingraycharles - 1 hours ago
The issue is that the bug leaves a password-less root account
available through other means as well. Once you try to
reproduce the bug, an attacker could potentially do a remote
root login without password.As such, it's very dangerous for
people to try to verify and should be strongly discouraged.
mcintyre1994 - 1 hours ago
If you have remote login enabled does root/no password not
work already because of the bug? It apparently does from
the login screen if you have username/password mode on, so
I wouldn't be surprised if it worked over remote login by
default.
djrogers - 1 hours ago
Does not work via ssh or screen sharing based on my
testing here. Seems to require physical access to the
machine.
pilsetnieks - 1 hours ago
No, it doesn't work for remote login.
jldugger - 1 hours ago
On most systems, root without password isn't available
remotely. Is this not true on OSX?
Jedd - 1 hours ago
Not the case.Once you enable root access - by 'testing' this -
others can remotely & silently access the system as root.GP is
right - don't encourage people to test this, as there's nothing
to gain from it. If you're on a shared machine you need to
mitigate. If you're on your own dedicated machine you need to
not share it until this is fixed.
thomastjeffery - 1 hours ago
> others can remotely & silently access the system as
root.They already can:https://gfycat.com/gifs/detail/sentimen
talnaiveantelopegroun...
sitharus - 41 minutes ago
This does not work if the root user has not been enabled
locally.Source: Just tried it myself.
biktor_gj - 1 hours ago
No, root is root and has always been there. It's the super
user account and cannot be removed, I think, from any modern
unix like os (well, you can rename it to whatever you want in
linux but UID 0 will always be there). The difference might
be that if you do log in for the first time you will have
lots of stuff on /private/var/root (talking from memory but
it was something like that in OSX) and lots of preferences
will be set, maybe even a /Users/root folder I hope that the
SSH server, which is disabled by default, will also handle
root login in a sensible way, but given the size of the f*
up, I'm not so sure.Really bad stuff
tekacs - 1 hours ago
Even if you're on a dedicated machine, this vulnerability
enables a local user to bypass the authentication prompt on
things like System Preferences or other auth checks.I'm
advising folks (incl. non-tech) to set a root password and
then re-disable the account (specifically via shell), which
prevents this from re-occuring:https://www.facebook.com/amar.
sood/posts/10209545863036116
djrogers - 1 hours ago
> Once you enable root access - by 'testing' this - others
can remotely & silently access the system as root.That's not
accurate. The user appears to be there either way, but
attempting to log in to a machine remotely using 'root' and
no password does not work - even after doing the preference
pane thing...
Jedd - 1 hours ago
I don't have access to a vulnerable machine -- just going
by comments in the other HN thread.root account is 'there'
all the time, yes. This process enables the account proper
(rather than just sudo). Evidently some remote mechanisms
using root work after the account is enabled.
arghwhat - 1 hours ago
This vulnerability lets users activate the root user without
using their password.Once done, you have opened for root
without password globally. That's bad.What they should do, as
responsible disclosure dictates, is report it in secret to
apple, and at most publicize a workaround (activate root user,
set password) without reporting the details of the
vulnerability.EDIT: It does not appear to be limited to admin
users. It appears to be related to disabled root accounts of
older origin, such as through upgrades. I cannot reproduce on a
fresh High Sierra install, but I reproduced on an upgraded
install.
jmuguy - 1 hours ago
I run as a standard user and was able to reproduce the bug.
arghwhat - 1 hours ago
Updated. I was unable to reproduce on another machine as a
standard user, but it appears to be related to it being a
fresh install of High Sierra, not an upgraded install with
old disabled root user entries.
throwaway2048 - 1 hours ago
"responsible disclosure" isn't some morally unassailable high
ground, but companies like apple sure want you to believe it
is.
arghwhat - 1 hours ago
Care to explain the comment about Apple? I can think of a
few companies (DJI, for example) that try to screw over
security researchers, but big IT companies usually don't go
on the list.
lawnchair_larry - 1 hours ago
Most of the big companies will take their sweet time to
fix something if it suits them. Not always, but sometimes
they just won't feel like getting around to it, and they
know that as a "responsible" researcher, you will keep
your mouth shut about it. I'm talking like a year. I've
seen this with the "researcher friendly" companies.In my
opinion, there's a point at which it becomes
irresponsible to let them sit on issues for so long, but
their newspeak for the disclosure policy tries to pre-
empt that idea.
saagarjha - 30 minutes ago
That's when you put a clear timeline for how long you
will wait before disclosing when you report these bugs.
sounds - 1 hours ago
I agree that we need more responsible disclosure. But as
https://www.eff.org/deeplinks/2017/10/drms-dead-canary-
how-w... explains, blame the DMCA.Somebody in Turkey has no
expectation that they will be treated with respect. It's much
more likely they will be attacked as in "shoot the
messenger." (So, please don't attack the person who brought
this to our attention.)I think they made a reasonable
decision, due to the critical nature of this bug, and tweeted
about it.
arghwhat - 1 hours ago
But throwing it on twitter doesn't stop you from using the
DMCA, and having the DMCA used against you doesn't stop you
from posting it on Twitter as counter-measure (which might
make the company retract the use of DMCA to avoid publicity
about suing "messengers"). If you're afraid of DMCA, keep
your mouth shut and stay away from the US.The DMCA is a
disgusting and absurd set of laws that can always make me
angry. Its existence alone proves very much how big
companies can rule with money, placing capitalism over
democracy.
sugavaneshb - 1 hours ago
*macOS High Sierra
anon1253 - 2 hours ago
wat. confirmed on 10.13.1 (17B48). I was even able to add another
super user.Edit: changing the login method to "Name and password"
under login options, then logout and login with "root" with empty
password also works.Fortunately, it doesn't work on cold boot with
FileVault enabled, at least it doesn't appear so. `sudo su root`
also doesn't work with an empty password.
cortesoft - 2 hours ago
well, `sudo su root` would be using the user password for the
logged in user, not for root. Does `su root` work, with no
password at the prompt?
anon1253 - 2 hours ago
Good point. Force of habit. Unfortunately I can no longer try
since I set the root password under the Directory Utility,
which probably changed the state of the system.Apparently
someone verified that it /does/ also work with `su - root`.
AdamJacobMuller - 2 hours ago
Wow, setting a root password seems to fix this...
jonny_eh - 2 hours ago
Looks like changing root?s password blocks the exploit but if you
disable the root user, it re-enables the exploit.Protect yourself
by changing root?s password: ? (Command) + Space, Directory
Utility, click the lock and enter your password, Edit -> Change
Root Password?, then do NOT disable Root User.Or open a terminal
and do: sudo passwd
AdamJacobMuller - 2 hours ago
> click the lock and enter your passwordor just enter root with
no password
jonny_eh - 2 hours ago
Ha, ya. That way you know it's still needed!
thomastjeffery - 1 hours ago
sudo passwd Does that change the password for the current
user without authentication, or does it change the password for
root without authentication?I think it would be best to recommend
an unambiguous sudo passwd root
LeoPanthera - 55 minutes ago
"sudo foo" with no other arguments runs "foo" as root. "passwd"
with no other arguments changes the password of the user it is
running as."sudo passwd" unambiguously changes the password of
root.
josho - 3 hours ago
Confirmed that root with no password unlocks the preferences pane.
But, changing the require password after screen saver setting
doesn't take effect. So, it seems to be a bug in the UI not an
actual vulnerability.edit: I stand corrected. The 'require
password' setting under Security Preferences didn't change, but
other settings do. Yikes
nsnick - 2 hours ago
10.13.1 can't make it happen
jameskilton - 3 hours ago
Oh this is a real vulnerability. It's possible to switch your
user to System Administrator using "root" and no password.
vladikoff - 3 hours ago
I have "Guest User" disabled normally. This allowed me to switch
Guest User on, log out, login as `root` into OS X. lol
thrusong - 58 minutes ago
There have been some really horrible bugs at Apple lately. I'm
still waiting on them to patch the camera bug in iOS 11 where if
you try to use the camera in a web app pinned to the home screen,
it shows the camera UI on a black screen. This dates back to June.
How can it be that hard to patch such a glaring and embarrassing
problem?
milesokeefe - 47 minutes ago
How many people are using the camera in pinned web apps? What's
the app you use? I'd imagine most camera-related functions are
already best served by native apps.
thrusong - 39 minutes ago
Does that make it OK? I mean, something as important to the web
as getUserMedia is broken on websites only if you pin it to the
home screen. Forcing people into Apple's walled garden doesn't
seem like an acceptable excuse.
[deleted]
alpb - 25 minutes ago
[meta] I think this thread is currently being downvoted, or dragged
down by the mods somehow. It should be in the #1 right now. I
suspect people are flagging/downvoting because there is no
responsible disclosure in this case.
dwighttk - 2 hours ago
I mean, I only tried 15 times, I don't know if that counts as
"several" but this doesn't work for me.It looks to me like my root
user is disabled.When I type "root" into the username field and
click unlock (in System Preferences > Users & Groups) "root" is
replaced with my username and the dialog shakes... I have to type
root in each time, but it never unlocks. 10.13.1Edit: trying it
after logging out keeps "root" in the username field, but never
logs me in... tried 20+ times
DonHopkins - 25 minutes ago
Pyramid's OSx version of Unix (a dual-universe Unix supporting both
4.xBSD and System V) [1] had a bug in the "passwd" program, such
that if somebody edited /etc/passwd with a text editor and
introduced a blank line (say at the end of the file, or anywhere),
the next person who changed their password with the setuid root
passwd program would cause the blank line to be replaced by
"::0:0:::", which then let you get a root shell with 'su ""', and
log in as root by pressing the return key to the Login:
prompt.https://en.wikipedia.org/wiki/Pyramid_TechnologyHere's the
email in which I reported it to the staff mailing list. And the
origin story of Pete's "Gymble Roulette" nick-name is here:
http://art.net/~hopkins/Don/text/gymble-roulette.html Date: Tue,
30 Sep 86 03:53:12 EDT From: Don Hopkins
Message-Id: <8609300753.AA22574@brillig.umd.edu> To:
chris@mimsy.umd.edu, staff@mimsy.umd.edu, Pete "Gymble
Roulette" Cottrell In-Reply-To: Chris
Torek's message of Mon, 29 Sep 86 22:57:57 EDT Subject:
stranger and stranger and stranger and stranger and stranger
Date: Mon, 29 Sep 86 22:57:57 EDT From: Chris Torek
Gymble has been `upgraded'.
Pyramid's new login program requires that every account have a
password. The remote login system works by having special,
password-less accounts. Fun. Pyramid's has
obviously put a WHOLE lot of thought into their nifty security
measures in the new release. Is it only half installed, or
what? I can't find much in the way of sources. /usr/src (on the
ucb side of the universe at lease) is quite sparse. On
gymble, if there is a stray newline at the end of /etc/passwd, the
next time passwd is run, a nasty little "::0:0:::" entry gets added
on that line! [Ye Olde Standard Unix "passwd" Bug That MUST
Have Been Put There On Purpose.] So I tacked a newline onto the
end with vipw to see how much fun I could have with this....
One effect is that I got a root shell by typing: % su ""
But that's not nearly as bad as the effect of typing: % rlogin
gymble -l "" All I typed after that was : you don't
hasword: New passhoose one new word: se a lonNew
passger password. word: se a lonNew password:ger
password. Please use a longer password. Password:
Retype new password: Connection closed Yes,
it was quite garbled for me, too: you're not seeing things, or on
ttyh4. I tried it several times, and it was still garbled. But I'm
not EVEN going to complain about it being garbled, though, for
three reasons: 1) It's the effect of a brand new Pyramid
"feature", and being used to their software releases, it seems
only trivial cosmetic, comparitivly. 2) I want to be able to
get to sleep tonight, so I'm just going to pretend it didn't
happen. 3) There are PLEANTY of things to complain about that
are much much much worse. [My guess, though, would be that
something is writing to /dev/tty one way, and something else
isn't.] Except for this sentence, I will also completely ignore
the fact that it closed the connection after setting the password,
in a generous fit of compassion for overworked programmers with
ridiculous deadlines. So then there was an entry in
/etc/passwd where the ::0:0::: had been: :7h37OHz9Ww/oY:0:0:::
i.e., it let me insist upon a password it thought was too short by
repeating it. (A somewhat undocumented feature of the passwd
program.) ("That's not a bug, it's a feature!") Then
instead of recognizing an empty string as meaning no password,
and clearing out the field like it should, it encrypted the null
string and stuck it there. PRETTY CHEEZY, PYRAMID!!!! That means
grepping for entries in /etc/passwd that have null strings in the
password field will NOT necessarily find all accounts with no
password. So just because I was enjoying myself so much, I
once again did: % rlogin gymble -l "" Password:
[ message of the day et all ] # Wham, bam, thank you man!
Instead of letting me in without prompting for a password [like
it should, according to everyone but pyramid], or not allowing
a null password and insisting I change it [like it shouldn't,
according to everyone but pyramid], it asked for a password. I
hit return, and sure enough the encrypted null string matched
what was in the passwd entry. It was quite difficult to resist
the temptation of deleting everyone's files and trashing the root
partition. -Don P.S.: First one to forward this to
Pyramid is a turd.
MagerValp - 57 minutes ago
To block this, set a random password for root:sudo dscl . -passwd
/Users/root $(uuidgen)
nkrisc - 2 hours ago
I don't know much about OS development but isn't this just the sort
of thing you'd automate testing for?
nixpulvis - 1 hours ago
If they are even a little smart, they'll now have a test for this
;)
mikestew - 1 hours ago
In order to create the test case that you would automate, you
first must create the repro scenario. IOW, automation has nothing
to do with this until the bug is found in the first place.
Arguably, one could create a test model that might have found
this but raise your hand if you even know what I'm talking about
when I say "test model".The only mitigation that automation would
bring is if the bug was found in earlier versions, and test case
was subsequently written. IOW, and very much a generalization,
automation is to find regressions. But if the bug is new...(To be
clear, this bug still should have been found. But automation is
unlikely to have found it.)
couchand - 1 hours ago
Respectfully disagree. "User cannot log in as root if root
user is disabled" is absolutely a test case that should be
written regardless of previously seeing the bug.
mikestew - 1 hours ago
Meh, you're probably right. If nothing else, I'd want to
verify the result of trying to use a disabled account (text
in the dialog is localized, et. al.) Run through the scenario
before I formally write the case and...WTF? Yeah, I could see
that.
olalonde - 1 hours ago
I guess not. I recall reading somewhere that the Linux kernel
doesn't even have automated tests. (edit: found the link:
https://stackoverflow.com/a/3177643/96855)
dandr01d - 2 hours ago
Have you seen iOS11? Apple doesn't seem to value testing too much
[deleted]
tbarbugli - 23 minutes ago
So far the best mitigation I could find out is to enable the root
account and set a strong password for it. Hopefully we'll get a
security update quickly so that I disable root access again. While
checking on this I also realized I was running 10.13 instead of
10.13.1 which fixes another major security flaw (key chain saves in
plain text)
FiveSquared - 1 hours ago
Oh my goodness. I have a High Sierra MBP. I am scared right now
BADLY
LeoPanthera - 1 hours ago
It can't be exploited remotely. Only by someone sitting at your
computer.
valine - 2 hours ago
This is deeply troubling. How does this even happen?
andrewstuart2 - 2 hours ago
All too easily. There's so much to keep track of in modern
systems engineering. We should all have a healthy dose of
awareness that we could be/create that weakest link even on our
best days.
kowdermeister - 1 hours ago
Errr... umm... unit tests? Tests?
lanius - 2 hours ago
Good thing I haven't updated yet. I wonder how many machines are
vulnerable?
_jomo - 2 hours ago
Current workaround / fix:1) open Directory Utility app (via
Spotlight or other) 2) Click lock to make changes, log in with
admin account 2) Click Edit -> Enable Root User 3) Click Edit ->
Change Root Password? 4) Set a password 5) Do NOT disable root
user!If you disable the root user, the admin prompt will create it
again with an empty password.
saagarjha - 12 minutes ago
Once the fix for this issue is out, you should disable the root
user.
[deleted]
steeleduncan - 2 hours ago
To workaround this before Apple have had a chance to patch
it(thanks @lemiorhan), it seems you can:- Open Directory Utility
(/System/Library/CoreServices/Applications/Directory Utility.app)-
Authenticate with the lock icon- From the Edit menu you can enable
the root user and set a proper password (it would already be
enabled if you had tried out the exploit)Having that root user
enabled isn't great overall, so it would be best to set a reminder
to disable it using the same Directory Utility app once the
security hole is patched.
2trill2spill - 21 minutes ago
Besides for APFS what user visible killer features has Apple made
to Mac OS since 10.6.8? I'm sure they have made internal non user
visible improvements to their kernel and userland. But it seems
most of the "changes" to Mac OS is just churning code, or at least
it seems that way from the outside.To me personally 10.6.8 +
Security Updates + APFS is extremely close to the ideal operating
system.
saagarjha - 14 minutes ago
APFS is not an example of something I would consider "user
visible"?for the average user there's no difference between HFS+
and APFS.
fredsted - 2 hours ago
This is very, very bad.
patcheudor - 2 hours ago
Apple makes it pretty easy to report vulnerabilities to:product-
security@apple.comThey also respond to security@apple.com but
prefer the product-security address.Further, there are any number
of legit bug bounty programs out there like ZDI that would pay for
a bug like this then immediately disclose to Apple for it to be
fixed.Disclosing an 0Day root authentication bypass vulnerability
on Twitter isn't cool, even if it is local: think of the impact to
shared iMacs on university campuses.
LeoPanthera - 2 hours ago
It's not local if you have Remote Desktop enabled. Works over
that too. From there you can enable ssh and all bets are off.
notanai - 1 hours ago
"It only works after getting physical access once" - quote form
somewhere else in the thread
thomastjeffery - moments ago
...or if you enabled root for some reason, but didn't set a
password.
kristofferR - 2 hours ago
I really disagree - this needs to be reported as much as possible
publicly to create a huge thunderstorm of negative publicity for
Apple.This isn't the first extremely serious and dumb High Sierra
password bug this year [1] [2], and unless Apple is severely hurt
by it, so they're forced to change, it won't be the last. High
Sierra is full of bugs and seemingly not just annoying bugs, but
also security bugs.Let's hope Apple gets sued for the damage
they'll cause by including this bug in High Sierra so they make
sure that next release of macOS won't be another bug filled
mess.[1] https://arstechnica.com/information-
technology/2017/09/passw...[2]
https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...
aquova - 45 minutes ago
I think there's a middle ground to this. Submit your report to
Apple security, allow them time to develop a patch, and then in
a week go ahead and tweet at the big media outlets about it.I'm
a die-hard Apple user myself, but I agree that the long list of
severe bugs in High Sierra is absurd, and a big public backlash
might be enough to kick them into gear. On the other hand, I, a
university student with next to no understanding of computer
security, can simply walk onto campus, sit down at a Mac, and
within seconds have complete access to the computer. It's
ridiculous, it's horrendous that it shipped like this, but it's
not something that needed to get out, especially something so
easy to utilize.
kristofferR - 36 minutes ago
The fact that you as the ordinary student can become root and
create a lot of damage so easily is the only reason the
public will care.Us geeks have been complaining about the
horrible QA in macOS for years, yet nothing has been done.
The fact that this is so simple to do will probably/hopefully
get ordinary people to start talking about it too ("Hey, have
you heard that you can hack Macs without a password? Very
insecure"), which would force Apple to improve.
openasocket - 1 hours ago
You could let them know about the vulnerability and wait until
it's been patched before commenting, with some timeout where if
they don't patch in a reasonable amount of time you announce it
anyway.
mozumder - 39 minutes ago
Zero-day disclosures aren't about negative publicity in order
to prevent problems further down the road some time in the
distant future.It's about protecting systems RIGHT NOW from
immediately causing harm to people's lives.
hw - 1 hours ago
Why does it need to create a lot of negative publicity for
Apple? Is there something you don't like about them?
Responsible disclosure needs to be valued given the number of
macs out there in the wild that could potentially be
susceptible to issues like this, and the impact it could have
on people (including you) not just directly but indirectly.How
would you feel if someone discovered a 0day at a company that
exposes credit card and identity info, published the 0day, then
hackers steal all that info (including yours)? I'm sure
'creating a thunderstorm of negative publicity' would be the
last thing you would want.
soneil - 52 minutes ago
I don?t see it as either/or. You can disclose responsibly,
and go for publicity once the fix is in circulation.
Responsible disclosure is nothing to do with protecting
Apple, it?s about protecting the users.
[deleted]
CGamesPlay - 1 hours ago
Don't forget the Disk Utility password disclosure!
https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...
kristofferR - 1 hours ago
Thanks, added!
sounds - 1 hours ago
I agree.https://www.eff.org/deeplinks/2017/10/drms-dead-canary-
how-w...Blame the DMCA. This guy is in Turkey - does GP really
think he can expect fair treatment and equal compensation as a
"western world" security researcher?
vatueil - 1 hours ago
There's no reason why the person who discovered the bug would
be safer publishing the vulnerability on Twitter than
disclosing it to Apple directly. If nothing else, they could
always post it on Twitter later. The link to the DMCA is a
digression.
gnulinux - 4 minutes ago
How does him being from matter in this case?
bradrydzewski - 1 hours ago
Responsible disclosure does not prevent negative publicity. It
provides the vendor with a grace period during which they can
fix the vulnerability. There can be plenty of negative
publicity once the vulnerability is patched and publicly
disclosed.Encouraging irresponsible disclosure because one
wants to see Apple hurt is a reckless and selfish attitude
because it puts millions of Apple customers at risk in the
process.
joe_the_user - 13 minutes ago
A bug like 'can log in with password "root"/""' just isn't
going to get you a grace period no matter what security
researchers might want.I mean, this bugs has been reported
already - by every cheesy hacking movie ever, by every
beginners book on social engineering and so-forth. Heck, it
was "reported" by Richard Feynman talking about cracking
safes during the Manhattan.
r3bl - 3 minutes ago
Grub's "backspace 28 times to a rescue shell" was also a
stupid one, but it first got fixed, and then made it to the
news.
camus2 - 1 hours ago
And Full disclosure is about protecting users of a software,
not letting the vendor off the hook. Here, the hack and the
fix are so trivial the responsible thing to do is to publicly
call out Apple for its lack of QA and warn users directly. It
affects everybody who runs High Sierra.> it puts millions of
Apple customers at risk in the process.Nah, it's Apple which
put millions of customers at risk, not the person who
disclosed the vulnerability. let's not shift away the blame
from the guilty here.Apple one of the richest company in the
world is obviously just cutting corners in QA here. This is
unacceptable.it's seems some people here are more concerned
about negative publicity than user security. This is a
pattern that have been seen countless times in big tech
corporations(such as Yahoo), not disclosing hacks that put
their users and their data at risk. This is unacceptable for
a company that claims to be all about their users.
joshuaturner - 52 minutes ago
I would argue that releasing this vulnerability as
irresponsibly as he did is showing he cares more about
negative publicity than user security.Yes, it's Apple's
fault for poor QA that this was released, but this guy also
put users at risk by telling the entire world about it
without giving Apple a chance to fix it.You're right, it's
about user security before publicity. So make sure users
are safe first.
SirZimzim - 45 minutes ago
The defense will stem primarily from users invested in the
Apple ecosystem. If anything that is very concerning on its
own.
kristofferR - 1 hours ago
Closed disclosure does, to a large degree, prevent negative
publicity. I don't think it is in dispute that this bug would
receive vastly less media coverage if it were only revealed
as a bug in outdated/patched versions of the OS.I don't want
to see Apple hurt (I'm an Apple-guy myself, using Macs,
iPhone, iPad and Apple Watch), I want to see them improve. I
doubt they start will start caring about QA unless they're
forced to.One absurdly serious and stupid password bug like
this can be a honest mistake, but three (that we know of,
that were full disclosures) in a few months is negligence
that should be criminal if it isn't.
ukblewis - 44 minutes ago
I actually do think it is in dispute. This is a tweet after
all. This guy could totally tweet about it in much the same
way after Apple released a patch. The negative publicity
would still exist because the bug would be equally stupid
and disastrous, just fewer people would be harmed along the
way.
mark-r - 27 minutes ago
It wouldn't be as clear that the bug is widely
reproducible after the patch is put out. And it certainly
wouldn't gather as much attention.
freedomben - 2 minutes ago
Exactly. Everyone I know on Mac immediately tried
reproducing this bug the moment they heard about it. On
those systems where it didn't reproduce, they immediately
dismissed it as a false report.
sydney6 - 1 hours ago
Not the attitude of the people reporting the issue have put
"millions of apple customers" at risk, but the company which
allowed to let issues like this one slip through their Q&A
process.IMO, this behaviour is part of the problem, the
reason why tech companies take security only on a
superfiscial level seriously.Don't kill the Messenger.
bradrydzewski - 1 hours ago
I think this incorrectly interprets my comment. I am not
defending apple or blaming the individual that disclosed
the vulnerability on Twitter. I am simply pointing out that
putting users at additional risk because you want to see
Apple hurt may be misguided. We have responsible
disclosures in place for a reason.EDIT: putting users at
_additional_ risk
sydney6 - 38 minutes ago
I dont understand the implied correlation between, what
you call, irresponsible disclosure and "wanting to hurt
apple". Where did you get this impression from?edit:
Typo.
xapata - 28 minutes ago
> Let's hope Apple gets sued ...
threatofrain - 27 minutes ago
I do get the impression that you do blame the individual,
as you have attributed unsavory motivations to his
behavior. Why do you care to make such a loose statement
about this person having a petty motive of malice?
blowski - 19 minutes ago
One of the grandparent posts specifically said they
supported the tweet because it would hurt Apple, and I
think bradrydzewski is responding to those comments.
philipwhiuk - 52 minutes ago
They were already at risk.
mark-r - 24 minutes ago
Making an exploit widely known increases the risk
dramatically.
jackhack - 1 hours ago
I'm more concerned that the "exploit" works "after a few tries"
and not the first-time-every-time, or not at all.One would
think that something as simple as a login would be
deterministic.
michaelbuckbee - 1 hours ago
My understanding is that the first attempt is
creating/enabling the root account with a blank password and
that the subsequent login is actually utilizing it (which is
kind of bizarre and probably why this was missed in testing).
justadudeama - 2 minutes ago
Does this user have admin privileges? root != admin on
macOS if I recall correctly.
alexwebb2 - 2 hours ago
Does anybody have any info on how much Apple would've been likely
to pay for a responsible disclosure in this case, given the scope
and severity of the issue?I'm just curious how much of a payday
this guy missed out on by not disclosing responsibly.
pault - 1 hours ago
That was my first thought. Based on some bounty reports I've
seen recently I would assume at least high five figures.
alexwebb2 - 1 hours ago
Ouch. This guy's going to kick himself pretty hard. The 15
minutes of infamy seems like a pretty bad tradeoff.
sounds - 1 hours ago
Do you honestly believe Apple will pay out the same to
someone located in Turkey?
alexwebb2 - 1 hours ago
I wouldn't think they'd care about the geography of it -
a good tip is a good tip, and they want to encourage
responsible disclosure.
thanatropism - 1 hours ago
Do they release statistics on bug bounty payouts?
FireBeyond - 46 minutes ago
They barely acknowledge bugs being submitted to Radar...
lawnchair_larry - 1 hours ago
For a local root with physical access? Not a chance. Maybe
low 4 figures.
rcruzeiro - 50 minutes ago
If the mac has screen sharing enabled, physical access is
not required
ken - 46 minutes ago
AFAICT, Apple's security bounty program is officially only for
their preselected group of security researchers.In the course
of developing my current application, I've discovered a couple
security bugs in macOS, which I reported to Apple product
security in PGP-encrypted emails. The only thing offered to me
was to have my name/company listed in the release notes (which
they are, for the latest 10.13 update, along with a CVE#).
albertTJames - 8 minutes ago
Yeah, the guy is an attention whore, he just wants to buzz.There
is no justification for releasing a 0day publicly.
thomastjeffery - 1 minutes ago
There is a simple workaround. Publicity means security
here.It's trivial to find. He can't presume he is the only one
who found it. Telling any individual that doesn't have
malicious intent is a good thing, therefore telling everyone is
a good thing.
ig1 - 1 hours ago
Responsible disclosure is pretty much a security industry
concept, it's not something that most developers know about,
complaining on Twitter is probably what an average person would
do.Although for what it's worth last time I reported a security
vuln to Apple using their official process they took around 2
years to fix it (admittedly low priority security vuln, passwords
being sent over http).
ben_w - 48 minutes ago
> admittedly low priority security vuln, passwords being sent
over httpWait, what?
ig1 - 36 minutes ago
Unfortunately it's still more common than you think.The other
day I actually ran across some AWS docs which suggest you
send your AWS root key in the url of http requests:http://doc
s.aws.amazon.com/AlexaWebInfoService/latest/index....
bangonkeyboard - 2 hours ago
If you urgently want Apple to fix something, you do not file
quiet bug reports. Apple only responds reliably to PR storms.This
vulnerability is ridiculous, unacceptable, and braindead to
execute.
saagarjha - 39 minutes ago
You can go about it both ways: file a bug report, put a
reasonable date that you want them to fix it by. Then you can
disclose it.
patcheudor - 33 minutes ago
> Apple only responds reliably to PR stormsThey've been quick
(within 45 days) to patch every major bug I've reported to them
and where the bugs were cross platform, impacting Windows,
Android, etc., they've consistently been amongst the quickest
to issue a patch so I'm not sure how you qualify that
statement.
Scoundreller - 1 hours ago
We need to come up with a witty name to get it fixed faster.
bhhaskin - 1 hours ago
AppleGate
maephisto - 11 minutes ago
iRoot. uRoot. Everybody Root.
patcheudor - 5 minutes ago
rootStorm
neverartful - 52 minutes ago
i0wned
[deleted]
teamhappy - 2 hours ago
You can't expect everybody who uses a computer to be aware of
that.
dsp1234 - 2 hours ago
think of the impact to shared iMacs on university campuses.I'm
sure Apple will in the future.
oneeyedpigeon - 1 hours ago
Let's wait until Apple release their patch so we know just how
long they left everyone's machines vulnerable for. That will be a
factor in determining whether this disclosure was irresponsible
or not. It's been two and a half hours so far.
[deleted]
sillysaurus3 - 2 hours ago
It's the neighborly thing to do, but people are under no
obligation to report vulns privately. The blame lies squarely on
Apple, not on the messenger.The fact that we know about it means
we can take steps to mitigate the damage.
collinmanderson - 1 hours ago
Mostly, they're just missing out on an up to $200,000 bug bount
y.https://www.theregister.co.uk/2016/08/05/apple_joins_the_bug.
..
[deleted]
e40 - 2 hours ago
The blame lies squarely on Apple, not on the messenger.There is
blame on both.If you leave your key in your front door lock and
I blast out on twitter your address and tell people about it, I
think I have some responsibility.
ZenoArrow - 2 hours ago
You may say so, but really the level of incompetence of not
setting a password for a root account is pretty high. The
fact that someone reported it in a way you don't agree with
shouldn't distract you from the fact that this highlights a
serious oversight.The main question that should be asked is,
how did this get overlooked? How is it that your average
website has better password security than the OS of one of
the richest tech companies in the world?To be fair to Apple,
Microsoft had similar issues back in the 1990s. Perhaps it
takes a string of security blunders for some tech companies
to take security seriously.
teamhappy - 2 hours ago
Your analogy makes no sense. He's just as vulnerable as you
are.
asejfwe8823 - 1 hours ago
A better analogy would be "if the lending bank left the door
to your new house open..."Other than buy an Apple product,
the users did nothing intentional to undermine security.Since
this is a subjective argument, based more on historical
instances of "responsible disclosure" and not law, I'm gonna
lean in this case of it being Apple that failedThey built the
entire "walled garden" without getting outside help. They
want the control, they have billions of dollars, can hire
whatever talent...Failed to spot a password-less root login
issue.People need to know today to be even more cautious
about using Apple gear in public places or around plain ol'
tech jerks that like to fuck with people for a gag.Society
has no legal or moral obligation to make sure Apple stays in
business.
[deleted]
interfixus - 2 hours ago
If you leave keys in other people's doors all over the
neighbourhood, I damn well have a rigtht, and possibly an
obligation, to make it publicly known that such a thing is
taking place. So that everyone may take their own
precautions.
godelski - 2 hours ago
Let's say keys were hidden around the neighborhood. Would
you rather everyone in the whole town know about it or
quietly and quickly go pick up all the keys before someone
notices and breaks into one of the houses?Personally I
think if you report through the proper channels and nothing
is changed THEN broadcast, but not as an opener.
[deleted]
thanatropism - 1 hours ago
This very excellent comment lies "dead", so I'll repost
it:asejfwe8823 24 minutes ago [dead] [-]A better analogy
would be "if the lending bank left the door to your new house
open..." Other than buy an Apple product, the users did
nothing intentional to undermine security. Since this is a
subjective argument, based more on historical instances of
"responsible disclosure" and not law, I'm gonna lean in this
case of it being Apple that failed They built the entire
"walled garden" without getting outside help. They want the
control, they have billions of dollars, can hire whatever
talent... Failed to spot a password-less root login issue.
People need to know today to be even more cautious about
using Apple gear in public places or around plain ol' tech
jerks that like to fuck with people for a gag. Society has no
legal or moral obligation to make sure Apple stays in
business.
mholt - 2 hours ago
Wrong. This is Apple -- not the homeowners -- leaving
everyone's key in everyone's door without them knowing.
giobox - 2 hours ago
Responsible Disclosure is widely regarded as a good
practice in these situations. Blame isn't the key issue -
fixing the problem quickly and safely is. Widespread
disclosure before Apple have even a chance to respond in a
timely fashion is inherently unsafe.You would hope the
self-described twitter bio "Agile Software Craftsman" might
have thought about this a little before tweeting.>
https://en.wikipedia.org/wiki/Responsible_disclosure
lawnchair_larry - 1 hours ago
"Responsible Disclosure" is a term rejected by the
industry as a loaded phrase that favors vendors, instead
preferring the term Coordinated Disclosure. Even so,
reasonable professionals still disagree that this is the
best option, in a debate that has existed for decades, so
it's by no means settled as the "proper" way.
dsp1234 - 2 hours ago
The poster practiced Full Disclosure, which is also a
valid disclosure policy.Since we're just making up
statements, I guarantee that Apple would never
voluntarily disclose this issue if it was reported
privately. So Full Disclosure is the only way to put
Apple's feet to the fire, as it's the only way in which
this issue would have had any visibility whatsoever.https
://en.wikipedia.org/wiki/Full_disclosure_(computer_secu..
.
Bud - 1 hours ago
On what basis do you "guarantee" this?
eyelidlessness - 37 minutes ago
It's used as an idiom, meaning roughly "I have total
confidence".
SahAssar - 1 hours ago
Private Disclosure does not prevent you from publicly
disclosing it after a grace period.
falcolas - 24 minutes ago
What grace period is appropriate for a 0 day root login
vulnerability?This guy is, with all probability, not the
first one to have found it.
pcwalton - 2 hours ago
The problem with that analogy is that the probability that
the "bad guys" already know about this vulnerability is
vastly higher than the probability that thieves know about
how well some random house in the neighborhood is secured.
tn_ - 1 hours ago
How many more people now know about this vulnerability
cause of this knuckle-head tweeting it? At least 100k
impressions? Now think of how many more "bad guys" have
access to this hack that are going to abuse it.
godelski - 1 hours ago
But do they? And what portion of them do? And are they
using it? There's a lot of speculation here. But surely the
average person doesn't know and with this being public
knowledge, AND easy to execute there is a bigger chance for
crime of opportunity.
ben_w - 52 minutes ago
It?s always reasonable to assume that black-hats (and?
what do you call government hackers ? black-suits,
helicopter-hats, ???) know everything that white-hats
know, and that they either have or are already in the
process of selling that exploit to less skilled
criminals.It?s not like being good morally correlates
with being good at security.
patcheudor - 2 hours ago
I get it, I really do, but it's not like he was complaining
about a bad Uber driver. Disclosure in this way has real-world
impacts up to and including harming people and we shouldn't
ever consider it as something which is remotely acceptable. Is
it acceptable to publicly disclose that an airport has a self-
destruct switch which can be accessed near the NW mens
bathroom? No. You contact someone who can fix the problem,
then publicly disclose.
testvox - 1 hours ago
But everyone can fix this problem by setting a root password.
So telling everyone is the right call. Otherwise people would
be sitting vulnerable while Apple comes up with a patch.
openasocket - 1 hours ago
But a tweet isn't really the most effective way to tell
everyone. Technical people, including those who would use
this vulnerability for malice, will find out far far sooner
than my grandmother.It seems to me the right thing to do is
to tell Apple privately, tell them to either push a fix or
put out some kind of release letting all their customers
know how to mitigate this in the next, say, 3 days, or I'll
just tweet about it. What's the downside? At the worst
case, you just prolonged the status quo for another 3 days.
thomastjeffery - 5 minutes ago
It's not the most effective, but that doesn't make it
bad, or malicious.
sillysaurus3 - 2 hours ago
It's as remotely acceptable as "root" with no password,
apparently.The question is large and complicated, and people
can agree to disagree. There's nothing wrong with tweeting
vulns: The company is at fault, we can defend ourselves now
that we know about the vuln, and it's a big PR disaster for
Apple.A past conversation:
https://news.ycombinator.com/item?id=14009937No, no it's not
strictly more ethical. It's not even strictly safer, which
should be an even easier question to answer. The baked-in
assumption in your logic is that users have no options other
than waiting to patch. But, obviously, they do, and keeping
vulnerabilities secret deprives them of those options.
openasocket - 1 hours ago
> The question is large and complicated, and people can
agree to disagree> There's nothing wrong with tweeting
vulnsThose two statements seem to be contradictory. It
seems to me there is still quite a lot of debate about
which disclosure policy is best,
arghwhat - 2 hours ago
... And means that others can utilize this to cause damage.The
idea of responsible disclosure is to minimize harm for you, the
user. Not to minimize bad publicity.
dolson - 8 minutes ago
In a case like this, I think it would be best to maximize the
bad publicity. Bad publicity is the minimum Apple deserves
for a bug like this. In my idea world they'd get a lot of
bad publicity, and a significant financial penalty.
zerostar07 - 2 hours ago
People are already fixing their machines because he tweeted. this
is too much of a huge blunder to wait for the official channels.
jrochkind1 - 1 hours ago
they are? Where's the fix?
Veen - 1 hours ago
Create a root password.
saagarjha - 38 minutes ago
This isn't a fix, it's a hack. A computer with a root
password is inherently more insecure than one without a
root account at all.
5ilv3r - 8 minutes ago
If setting a root password is a hack, I'm Donald Duck.
saagarjha - 3 minutes ago
I really can't respond to you unless you explain your
reasoning?
will4274 - 22 minutes ago
Actually, no. For all computers, running macOS High
Sierra, a computer with a root password is a whole heck
of a lot more secure than one without a root account at
all :)But seriously, a fix is whatever fixes the problem.
saagarjha - 18 minutes ago
It is now. There's going to be a whole lot of people who
are going to set a root password because they read an
article online recommending it, then install the update
that fixes this issue. Now they're stuck with a root
password when they could have not had one at all.
yumraj - 31 minutes ago
I agree in general, but calling it uncool and laying any blame on
the person reporting is not fair.You may know the protocol,
security researchers and people in the tech industry may know
that, but why is an ordinary Joe expected to know, or research,
that email address and/or the protocol regarding 0-day
vulnerabilities.
zeveb - 2 hours ago
> Disclosing an 0Day root authentication bypass vulnerability on
Twitter isn't cool, even if it is local: think of the impact to
shared iMacs on university campuses.It gets the word out
quickly.Releasing proprietary software with such a hilariously
insecure authentication system isn't cool. This isn't free
software, produced by people & corporations out of the goodness
of their hearts; rather, it's something for which people pay a
good deal of money and which they have a right to expect is at
least somewhat secure.Getting the word out, fast that a) there's
a huge insecurity and b) it's in Apple software provides benefits
to those running macOS (so they can fix their systems) and to
those considering running macOS (so they can evaluate whether an
alternative is more appropriate).
na85 - 24 minutes ago
This is one of the sillier things I've read today. The only way
something like this slips through is a culture of complacency, or
incompetence.And the only way Apple gets motivated to fix either
of those two things is massive Pr damage.
dhimes - 2 hours ago
Is this address easily discoverable without needing too much
insight into tech company workings? Like, do they have a help
menu that tells people where to report stuff? I'm not an apple
user.
0care - 1 hours ago
I disagree. Being unaware of the flaw doesn't make you more
secure.
fixermark - 2 hours ago
Is it likely it's just an error due to the discoverer not being
immersed in the Infosec space? "Don't disclose a 0-day publicly"
is good 'common' sense, but only among the 'common' of people who
are steeped in security issues and the ramifications of
publicizing them.
mikeash - 2 hours ago
Indeed, discovering this bug wouldn't take any security skill
(I imagine it could be harmful since you might skip really dumb
stuff like this) and could easily happen by accident.
Responsible disclosure is standard for security researchers but
I don't think this person was one, and it's not very fair to
blame him for not doing it right.
lawnchair_larry - 1 hours ago
That is not the case among infosec professionals either. Many
respected professionals believe that the right thing to do in
many cases is full public disclosure. Google Project Zero are a
notable example.
Veen - 1 hours ago
Project Zero does full disclosure 90 days after informing the
relevant organization. Full disclosure comes after there has
been a chance to fix the problem. Otherwise everyone is put
at risk until a fix is available.
mwfunk - moments ago
Google Project Zero does not support full public disclosure
immediately- quite the opposite. They support full public
disclosure after giving the vendor an opportunity to ship a
fix to their customers in a reasonable period of time.
Nobody's debating whether or not security flaws should be
publicly disclosed- of course they should. The only debate
is, what is the most responsible way to handle such a
security issue such that it harms the fewest users.Project
Zero (and infosec professionals, at least all of the ones
I've ever worked with) would tell you that this was the most
irresponsible way to handle the issue, short of not saying
anything and selling knowledge of the exploit to someone
other than the vendor who could fix it. Publicizing something
like this in this way is something people do because they
want publicity for themselves. It is not something someone
does if their biggest concern is for the users who might be
affected by it. It is something someone would do if they
didn't care about the users, and just wanted public credit
for pointing it out.
mirekrusin - 2 hours ago
There must be some kind of scale 1-10 of how serious the issue
is. This one goes up to 11 as hilarious, not sure if proper
reporting ethics apply here anymore.
williamscales - 1 hours ago
This situation is much more akin to a fire rapidly spreading
through a village at night. I would go outside and start
hollering in the hopes of saving anyone.
saagarjha - 32 minutes ago
A better analogy is that there's a fire somewhere in your
village, but it's mostly contained (it's not spreading, because
other people don't know about it yet). By hollering about it,
you've made it possible for anyone to go to the fire, light a
torch with it, and burn down the village. Instead, you could
call up the fire department and they could put it out?and then
you could tell everyone about it.
5ilv3r - 7 minutes ago
You are comparing an arsonist to a fire department.
saagarjha - 5 minutes ago
Uhh, no. How are you getting that impression? I'm simply
saying that arsonists exist, and it's probably a good idea
to make it harder for them to burn things down than to
publicly advertise a way for them to do it.
callesgg - 2 hours ago
In what version did the issue appear?
devindotcom - 1 hours ago
we've seen it only in 10.13.1 (17B48) so far
mithr - 1 hours ago
It also works on 10.13 (17A365)
shavingspiders - 1 hours ago
I can confirm that, too. Took 2 attempts.
overcast - 2 hours ago
Excuse my language, but this was a dick move to post this publicly,
especially on Twitter. Go through private bug channels properly for
something as serious as this. Of course doing it that way doesn't
give you your 15 minutes of interweb fame.
mikeash - 2 hours ago
Maybe he didn't know about the proper procedures to handle a
security vulnerability. You wouldn't have to be a security
researcher to discover this bug, and I don't see any indication
that he is one.
overcast - 1 hours ago
I would say it's pretty basic common sense, not to publicly
announce ANYTHING that could immediately affect millions of
people. Unless he's just a sociopath.From his Twitter account,
he's not just some layman stumbling across it.Agile Software
Craftsman, iyzicoder @ http://www.iyzico.com , Founder of
Software Craftsmanship Turkey @scturkey, The community guy
http://bit.ly/lemiorhan
mikeash - 1 hours ago
If that were true, then the security community wouldn't have
spent years fighting about whether responsible disclosure was
the right approach. That's for people who actually understand
this stuff. It's unreasonable to expect an outsider to derive
it all on their own from first principles.
overcast - 1 hours ago
So someone stumbles upon a lost cache of chemical weapons.
Rather than reporting to the authorities, they post its
location on Twitter. That's called just using your brain.
testvox - 1 hours ago
Security though obscurity is no security at all. Don't
you think the people living around the chemical weapons
should be informed too so they can take precautions to
protect themselves?
mikeash - 1 hours ago
You're coming at this from a position of knowledge and
assuming everyone else knows as much as you do, or should
be able to figure it out in short order. That's not how
it works. It's really hard to see how other people might
think in situations like this.
always_good - 1 hours ago
Also, it's reasonable for someone to think that making a public
stink about it is in the best interest of all the people then
that can immediately patch it themselves instead of having to
wait for Apple to push a patch and then for everyone to
download that patch.I'm not convinced private disclosure is
without its downsides nor a panacea.
Jedd - 1 hours ago
Maybe. Look at his twitter page though:
https://twitter.com/lemiorhanNot impossible to believe he's
unaware of the right way of handling this kind of issue, but
that banner photo (Enthralling My F-ing Audience) [1] and stats
there suggest he should be aware that there probably are
sensible and polite procedures for this, even if he didn't
immediately know what they were.[1] http
://jesuschristsiliconvalley-blog.tumblr.com/post/4653787...
mikeash - 1 hours ago
How do the banner or stats suggest he should have known about
this?
Jedd - 52 minutes ago
He is giving a technical talk to a large audience. Slides
refer to development, and bio implies this means software
development. Bio uses the phrase 'founder of software
craftsmanship Turkey'.Following the link to his home page
we find:"He has worked as software architect, software
craftsman, technical leader, team leader, technical
coordinator, Scrum Master and Agile coach in dozens of
software projects at BYM, GittiGidiyor / eBay and
Sony."and"Lemi Orhan Ergin is a Software craftsman,
passionate developer, technical architect, Agile culture
cultivator, Agile coach, Scrum / Kanban practitioner and
trainer, Management 3.0 trainer, experienced mentor,
engineering booster, Git trainer and lover, the TDD guy,
clean coder, infected with the technical side of Agile,
presentation and visualization freak, non-stop learner,
full time apprentice of my masters, the community guy."It's
possible this guy was oblivious to the idea that there's a
good way to share this information with Apple / The World
At Large, and consequently did not attempt to find out the
preferred way of doing it, but I don't buy it.
zerostar07 - 2 hours ago
this is too serious to hide. better to tell users how to fix it
than wait until apple releases something
overcast - 2 hours ago
Yeh, except for the millions of MacOS users out there, like my
parents who don't read Twitter, or HN or any of the other sites
people think that everyone stays up on. They are the targets.
fixermark - 2 hours ago
Not technically. Exploitation still requires physical access
to the machine or remote access to have been enabled, right?
Did your parents who don't read Twitter or HN enable a
feature that generally only power users want or need?
pkaye - 2 hours ago
I think it is only a local exploit. The bigger risk are the
Macs in schools and libraries.
glhaynes - 2 hours ago
That's not how responsible disclosure works.
testvox - 1 hours ago
But it's how full disclosure works which is more responsible
then coordinated disclosure.
giarc - 2 hours ago
Probably could still get 15 minutes of fame if you disclosed
privately then blogged about the back and forth and a picture of
the $10,000 cheque from Apple.
CameronBanga - 2 hours ago
Apple doesn't pay bounties for this sort of report, even if
direct to their team. They have a private bounty program, for a
select few.
bredren - 2 hours ago
That this would be the prevailing understanding is exactly
why a bug like this would live in the wild at all. There are
plenty of other orgs out there who would have paid big money
for this.
3pt14159 - 2 hours ago
Source? I've heard of iPhone vulnerabilities getting high six
figures from Apple (for root access via sms). Why wouldn't
Apple pay for something like this?
fixermark - 2 hours ago
When I put it into my personal malice / ignorance balance, it
weighs out to the likelihood that the discloser isn't plugged in
enough to the infosec scene to be aware that there are already
best practices for this kind of disclosure.It's a big world out
there, especially nowadays. And nothing I've seen in recent
history suggests to me the average user knows or cares about
infosec concerns beyond basic hindsight understandings.
overcast - 1 hours ago
Sure, now look at his Twitter account. He looks pretty plugged
into the software community.Agile Software Craftsman, iyzicoder
@ http://www.iyzico.com , Founder of Software Craftsmanship
Turkey @scturkey, The community guy http://bit.ly/lemiorhan
fixermark - 59 minutes ago
Yes. And from his personal site
[http://www.lemiorhanergin.com/]:He's a manager. CSM, PSM1,
PSD1, Scrum Master, Kanban Practitioner. Code retreat
facilitator. Translated Agile Manifesto into Turkish. The
only thing that immediately makes me think he even touches
code is "git trainer and lover." Notably lacking from his
r?sum?: references to specific open source projects he's
worked on or code he's written (though personally, I'd be
concerned because his r?sum? does list "Restful Services" and
I'd expect that to have given him a taste of infosec basics,
but maybe it's a bit of r?sum? padding... shouldn't it be
spelled "RESTful services?" ;) ).It feels weird to say for
those of us deeply immersed in the internet / telecoms / web
app side of software development, but depending on your
focus, you can do an awful lot of software development
without ever brushing up against the sharp edge of infosec.
testvox - 1 hours ago
Isn't the best practice full disclosure? It seems like it was
followed well.
singularity2001 - 2 hours ago
Is http://hckrnews.com/ buckling from the tremendous traffic this
issue generates?
spsful - 20 minutes ago
workaround: ENABLE ROOT USER AS FAST AS
POSSIBLEhttps://support.apple.com/en-us/HT204012
saagarjha - 16 minutes ago
As I had said above, this, in the long run, is actually less
secure than not having a root account at all. If you do this,
make sure to revert it once the issue is patched.
abritishguy - 1 hours ago
If you have `osquery` deployed to your fleet you can detect
compromise with this query:SELECT * FROM plist WHERE path =
"/private/var/db/dslocal/nodes/Default/users/root.plist" AND key =
"passwd" AND length(value) > 1;
sounds - 1 hours ago
That only detects enabled root users, which is a start but may
include innocent people who have set a root password to protect
their machines.
[deleted]
[deleted]
mrmondo - 1 hours ago
1. Ensure you always have FileVault enabled (you should regardless)
and shutdown after work until the bug is fixed.2. Add a complex
root passphrase and clean this up after the fix is released.3.
Reflect on how irresponsibly this serious security bug was
?reported?, he didn?t just potentially miss out on $200,000, he put
an enormous number of people at risk of local intrusions when
instead if it was properly reported there?s a good chance Apple
would have released a bug fix for this quicker thus reducing the
potential impact and spread of misinformation.https://en.m.wikipedi
a.org/wiki/Responsible_disclosurehttps://support.apple.com/en-
au/HT201220 (See ?Security and privacy researchers?)
thomastjeffery - 1 hours ago
It's not irresponsible to make a bug public.He did not put people
at risk, he showed people they are already at risk, so they would
know to set a root password, and thereby not be at risk.Security
by obscurity does not work!
sdmadf2834 - 43 minutes ago
This is the most idiotic thing I've heard in a long time. Yes,
they were already at risk, but with the way he disclosed the
information, the risk increased exponentially. This guy's
actions were either stupid or malicious.
thomastjeffery - 35 minutes ago
Obviously this isn't the best way to disclose a security
flaw.That does not make it malicious.Sure, there are more
malicious people aware of this security flaw, but there are
also more users aware of this security flaw, and the simple
steps they can take to mitigate it.
sdmadf2834 - 33 minutes ago
Yep, just saying that if he's not malicious (intending to
maximize harm to users), then he's an idiot for disclosing
it this way.
thomastjeffery - 25 minutes ago
Or just didn't know what the best practice was.Since this
is a flaw any user can run into, I wouldn't get so mad
about someone who doesn't know best practice running into
it.I am much more concerned that such an obvious
tractable flaw exists in the first place.
mrmondo - 1 hours ago
It?s not an example of security by obscurity, it?s a straight
out security flaw and bug.If it?s not publicly known and is a
security risk it is far more effective to directly contact the
developers / companies security team so they can immediately
work on actually protecting people by developing a patch. If
they don?t respond quickly (subjective, I?d call it within 12
hours) or fail to issue a fix in a timely manor (subjective,
I?d say 24 hours) then yes - go public, start by logging a bug
report and link to that bug report or if you can?t - the bug
number / reference.
[deleted]
thomastjeffery - 56 minutes ago
The fact is that the devs certainly do know about it by now,
yet users do not have a fix yet. Users do, however, have a
workaround, and knowledge that the security flaw exists in
the first place.Waiting for a fix before disclosing a
security flaw is security by obscurity, even if it is to be
replaced soon.It is best for users to know that their system
is vulnerable, and how to fix that without waiting for a
system update.
mrmondo - 47 minutes ago
> "The fact is that the devs certainly do know about it by
now, yet users do not have a fix yet."Citation needed.> "It
is best for users to know that their system is vulnerable,
and how to fix that without waiting for a system
update."Stepping outside the 'tech' social bubble, most
general users likely won't create a root account and
password from something they see on TV or their local news
site or at least not before a patch would have been
released.--Further to previously provided examples:https://
www.cloudflare.com/disclosure/https://access.redhat.com/sec
urity/team/contacthttps://www.xenproject.org/security-polic
y.htmlhttps://about.gitlab.com/disclosure/https://help.gith
ub.com/articles/responsible-disclosure-
of-s...https://www.kernel.org/doc/html/v4.10/admin-
guide/security-b...https://www.drupal.org/drupal-security-
team/general-informat...https://www.cisco.com/c/en/us/about
/security-
center/security...https://www.juniper.net/us/en/security
/report-vulnerability/
thomastjeffery - 41 minutes ago
> Citation needed.Has there been an update released yet?
I wouldn't know, I don't use OS X.Is this the best way to
report a security flaw? Of course not! Is it a bad way?
No! The only bad way to report a security flaw is to not
report it at all.
mrmondo - 32 minutes ago
>> Citation needed.> Has there been an update released
yet? I wouldn't know, I don't use OS X.I think you might
have misunderstood what I meant when when asking for
citation, it's based on the statement you made in
relation to citing sources for what something that could
be opinion stated as
fact.https://libguides.mit.edu/citing> Is it a bad way?
No!OK this is where I stop feeding the troll.
mk89 - 19 minutes ago
Apple proves they still care about UX: finally, I found a way to
login without typing.
rubatuga - 2 hours ago
While this true, please keep in mind that rebooting your Mac into
single user mode also allows anybody to login as root
2trill2spill - 2 hours ago
You can set a firmware password to prevent this.
mikeash - 2 hours ago
Not if I use FileVault, surely?
danra - 1 hours ago
These bugs are getting ridiculous. With Apple's budget, finding
such bugs in a security architecture review or just in QA should be
as easy as 1+2+3.
symlinkk - 1 hours ago
> 1 + 2 + 3https://www.macrumors.com/2017/10/24/ios-11
-calculator-anima...
api - 19 minutes ago
But there are new emojis, and emoji karaoke works!
abritishguy - 19 minutes ago
Just in case it is relevant for anyone here this is what our
security team have established thus far:- Can be mitigated by
enabling the root user with a strong password- Can be detected with
`osquery` using `SELECT * FROM plist WHERE path =
"/private/var/db/dslocal/nodes/Default/users/root.plist" AND key =
"passwd" AND length(value) > 1;";`- You can see what time the root
account was enabled using `SELECT * FROM plist WHERE path =
"/private/var/db/dslocal/nodes/Default/users/root.plist" WHERE key
= "accountPolicyData";` then base 64 decoding that into a file and
then running `plutil -convert xml1` and looking at the
`passwordLastSetTime` field.Note: osquery needs to be running with
`sudo` but if you have it deployed across a fleet of macs as a
daemon then it will be running with `sudo` anyway.
fiatpandas - 1 hours ago
Worked for me on the second try (10.13.1)
LeoPanthera - 1 hours ago
root is disabled by default. The first try, somehow, enables it
with no password. The second try will let you in.
2trill2spill - 2 hours ago
Apple has a serious software quality problem. Last night I was
helping a friend with their computer. Safari couldn't even render
apples website correctly. Nor could Safari connect to any site with
HTTPS. Installed FireFox and HTTPS sites worked and apples's site
renders. But the submit button on their developer site is
broken[1]. Mail on my Mom's fully updated laptop crashes every time
it's opened. Once I reported a bug in ptrace like 4 years ago and
no response yet. Also the archive utility fails often to extract
tar files that the tar command has no problem extracting at all.
Quicktime can't play most videos, etc, etc. And now shipping an
operating system with a root account with no password by
default.Come on Apple you have a quarter trillion dollars in the
bank why don't you spend some on improving your software.[1]:
https://forums.developer.apple.com/thread/60763
minusSeven - 1 hours ago
Its not just Apple though. Microsoft had the similar problems in
the past. Edge did not support silverlight causing people to move
to other browser. It was strange to see Microsoft's own software
not supported by Microsoft.
2trill2spill - 1 hours ago
> Its not just Apple though. Microsoft had the similar problems
in the past. Edge did not support silverlight causing people to
move to other browser. It was strange to see Microsoft's own
software not supported by Microsoft.In my personal experience
Windows has been much better than MacOS for me. I've been using
Windows 7 for the last year at work and I'm having
significantly less problems with Windows then MacOS. But
Windows and MacOS both give me more problems then a FreeBSD or
Linux box ever has.
anko - 1 hours ago
> I'm having significantly less problems with Windows then
MacOS.I'm interested.. What kind of problems?> But Windows
and MacOS both give me more problems then a FreeBSD or Linux
box ever has.I switched from linux on the desktop to MacOs
precisely because of the problems linux had - driver support,
even LTS updates breaking functionality, and overall
clunkiness. I run linux on all my servers.
kylemuir - 1 hours ago
Really? What driver support on a desktop were you
experiencing?I've run Linux mint on my desktop at home for
a few years now and have had zero problems at all (Intel
i5, Nvidia gfx, wired connection).The last time I had
driver issues with Linux was ~10 years ago and it was for a
laptop running Ubuntu.
snowpalmer - 1 hours ago
Windows 7 has been on the market since 2009 while High Sierra
has been out since June of this year. I feel like we're not
comparing apples to apples here.. I'm sure both companies are
releasing security fixes consistently and Win7 has clearly
had more of them in 8 years.
strictnein - 1 hours ago
Silverlight was EOL'd five years ago.
reaperducer - 1 hours ago
Tell that to Dish Network.
oefrha - 2 minutes ago
EdgeHTML sure has advanced a lot from Trident, and I appreciate
their openness with Platform status, but Edge as a browser is
still a joke IMO.The other day I had to use vanilla Windows 10,
and wanted to save a text file from Edge. Nope, there's no such
functionality. The closest thing to save is print to PDF.
will_hughes - 55 minutes ago
It was partly a marketing thing, but Edge is not IE, and Edge
has never supported any plugins (which Silverlight is).
[deleted]
eridius - 58 minutes ago
> Safari couldn't even render apples website correctly. Nor could
Safari connect to any site with HTTPS.Sounds like something's
wrong with your friend's computer, because neither of those
issues are reasonable to expect no matter what your opinion of
Apple's software is.> But the submit button on their developer
site is brokenGiven the number of people who've successfully gone
through that form, I'm willing to bet it's a content blocker
extension that's blocking some dependency the form needs.> And
now shipping an operating system with a root account with no
password by default.The OS actually ships with root disabled. The
bug isn't that there's no password (after all, a factory-set
password isn't any more secure), the bug is that the login form
is somehow re-enabling the root user when it's not supposed to be
able to do so.
2trill2spill - 13 minutes ago
> Sounds like something's wrong with your friend's computer,
because neither of those issues are reasonable to expect no
matter what your opinion of Apple's software is.Doubtful
Firefox and Chrome work just fine.> Given the number of people
who've successfully gone through that form, I'm willing to bet
it's a content blocker extension that's blocking some
dependency the form needs.Brand new install of Mac OS on a new
SSD. So Safari was clean no extensions, no custom
configuration.> The OS actually ships with root disabled. The
bug isn't that there's no password (after all, a factory-set
password isn't any more secure), the bug is that the login form
is somehow re-enabling the root user when it's not supposed to
be able to do so.Mere semantics, It doesn't matter if root is
being "reenabled" or not. From an attackers point of view High
Sierra effectively ships with root with no password.
Unknoob - 2 hours ago
Confirmed here on 10.13
swat535 - 2 hours ago
This is comical at this point. I have no idea how such vulnerable
software makes it to production.It is really ironic that a company,
making billions of dollars and branding itself as the leaders of
quality, stability and so on, to have this kind of vulnerability.I
have truly lost faith in Apple.
gluestic - 48 minutes ago
Agreed.iOS 11 was the tipping point for me (can't delete photos
using trash icon, wrong orientation when unlocking phone, random
lag/freezes etc).Apple just doesn't care any more.
mcintyre1994 - 49 minutes ago
I guess Apple aren't the kind of company that would do it, but I'd
love to read a frank post mortem about how this happened.
jcoby - 2 hours ago
Be careful testing this! It appears that you're creating a "root"
superuser with no password. Be sure to clean up that user
afterwords.https://twitter.com/a_hailes/status/935601901839806464
mschuster91 - 2 hours ago
The "root" superuser is always there, I'm not sure if it's
possible to actually delete it.
tempay - 2 hours ago
It is disabled by default[1] (meaning you can't login as it),
this vulnerability appears to enable the root user without
setting a password. If the root user has already been enabled
it doesn't work.Anyone who does this should probably set a
password for now and then disable the root user account once it
has been patched.[1] https://support.apple.com/en-us/HT204012
srathi - 2 hours ago
This is the best workaround for now. Enable the root user
with a strong password till the bug is fixed by Apple.
martinp - 2 hours ago
This support article explains how to disable the root user:
https://support.apple.com/en-us/HT204012
jameskilton - 2 hours ago
Do note that this doesn't fix the problem. The system (at least
High Sierra) will happily re-enable the user for every attempt
at logging in.
LolWolf - 1 hours ago
Just change the root password once the account is enabled;
this fixes the hole.sudo passwd -u rootIt's sad we have to do
this, though.
tekacs - 53 minutes ago
If you disable the root user using `dsenableroot -d` from the
Terminal, this seems to disable the account in a way that
leaves its password intact.
pwinnski - 33 minutes ago
The bug isn't in the disabling, it's in the auto-enabling
on attempt.
tekacs - 25 minutes ago
Having tested this by both approaches (disabling through
GUI & shell), the above (through shell) seems to prevent
this from re-occurring when you attempt to perform this
bogus login again. Disabling the account via the GUI
causes the failure to re-occur.
psychometry - 2 hours ago
You're not creating it, but rather enabling it. When the bug is
triggered, the root user is enabled (per Directory Utility).
ringaroundthetx - 1 hours ago
oh my god
rwc - 2 hours ago
It's worse than that. You're enabling the root user EVERY time
you use this vulnerability. Even if you disable the root user in
Directory Utility, logging in with root and no password will re-
enable the root user.
mcintyre1994 - 2 hours ago
I haven't upgraded to High Sierra yet and this doesn't happen
on my install atm. Does adding a password to the root user stop
this vulnerability? If it does then that seems way better than
disabling the account until this is fixed.
LeoPanthera - 2 hours ago
You can simply set a root password with "sudo passwd" to close
the hole.
tekacs - 1 hours ago
And you might want to disable the root account again with
`dsenableroot -d` as well, so that the root account stays
disabled after the vulnerability is patched.Unlike doing this
through the GUI, this seems to retain the root password and
prevent this vuln from re-occuring.
LeoPanthera - 38 minutes ago
Don't disable root. The bug re-enables it with a new blank
password.
tekacs - 26 minutes ago
It doesn't if you disable it from the shell like this, as
I note in my comment.I've tested both approaches -
disabling via the GUI causes this bug to re-occur next
time you try, disabling via the shell does not.
ukblewis - 4 minutes ago
Bizarrely though, you can still use the root user (with
the password that you set) to login to the Directory
Utility even while it is supposed to be disabled... This
behaviour seems super weird.
thomastjeffery - 1 hours ago
Then you better remember the password you set, or be sure
that you will always have sudo access.
DavideNL - 2 hours ago
...unless you set a password, right?
thought_alarm - 2 hours ago
Until this is fixed it's probably better to use Directory Utility
to enable root with a strong
password./System/Library/CoreServices/Applications/Directory
Utility.appEdit > Change Root Password
senko - 1 hours ago
Am I missing something or does this require the attacker to have
access to an unlocked computer? In which case all bets are off
anyways.
valine - 1 hours ago
It works remotely if remote login is enable.edit: Screen sharing
is is vulnerable not ssh. Either way its bad.
djrogers - 1 hours ago
No it does not. I tested this rather carefully, and both ssh
and screen sharing do not allow the user root with no password.
ehntoo - 1 hours ago
I have not been able to trigger this with ssh, but certainly
have been able to with Screen Sharing, even after explicitly
re-disabling the root account.
jonny_eh - 1 hours ago
What if it's a stolen laptop with an encrypted hard drive?
jzwinck - 1 hours ago
It requires the attacker to be able to type a few characters into
a logged in session. If the session is not an administrative one,
it's not fair to say all bets were off.If I give you a Mac logged
in with an unprivileged account and you can use only the keyboard
and mouse to gain root access, the security has failed.I think
you've conflated this with the attacker having (full) physical
access to the machine, which conventionally means access to its
ports and perhaps a screwdriver. This is not that.
senko - 1 hours ago
Fair point, if that works with a guest account.I was thinking
along the lines of, if I have write access to your .bashrc (or
a multitude of other config files that you as an unprivileged
user have write access to, and can be used to trick you later
into running code of my choosing), all bets are off.
code_duck - 1 hours ago
The 'attacker' could be someone like your 12 year old son or an
employee, who already has access to the computer but not
necessarily everything on it at all times.This would have been a
pain for me when i was using parental restrictions to lock a 12
year old out of 18 hour a day Minecraft.
woodrowbarlow - 1 hours ago
an unlocked computer, or:* a computer with remote login enabled*
a computer with the main login screen set to "username and
password" mode* a computer with a guest account
EpicEng - 1 hours ago
>In which case all bets are off anywaysHow are all bets off if
they don't have access to a root user? This isn't Windows we're
talking about.
senko - 1 hours ago
If they have access to the account that is being used normally,
they can modify the (user-accessible) settings to trick the
user into running malicious code and giving them access (or
causing trouble even without access to the root account).
mholt - 1 hours ago
If you lose physical control over the machine, all bets are off
because an attacker can modify the hardware to do nefarious
things.
apetresc - 1 hours ago
I know the theory, but practically there's a huge difference
between that type of physical access and "the victim left the
room to go to the bathroom for 2 minutes" type of physical
access
EpicEng - 1 hours ago
ok, sure, but in practice that is pretty unlikely.
devindotcom - 1 hours ago
nope. you can log in at the login screen, it creates a new root
admin user
senko - 1 hours ago
Missed that part in the text, thanks.Yikes!
[deleted]
perfectstorm - 1 hours ago
What's going on with Apple's QA team ? Here's another serious bug
that I came across:I've two factor authentication on my Apple
account and now every time I use a new browser (or after clearing
the Cache) and try to log into one of the Apple developer sites it
sends me the authentication code to the same machine that I'm
using. How is that two factor ?I've an iPhone which is connected to
the same account but it's not my primary phone so it's most likely
not ON when I do this. I guess Apple tries to send the code to my
phone and when it fails sends to the next online device which
happens to be the same machine I'm using to log in. So all I have
to do is click Allow and enter the 6 digit code which is displayed
in a different app.
rgrove - 59 minutes ago
> I've two factor authentication on my Apple account and now
every time I use a new browser (or after clearing the Cache) and
try to log into one of the Apple developer sites it sends me the
authentication code to the same machine that I'm using. How is
that two factor?Your password is something you know. Your
computer (which is associated with your Apple ID) is something
you have.If someone tries to log in using your password from
another computer, your account is safe. If someone steals your
computer but doesn't know your password, your account is safe.
You're only in trouble if someone steals your computer _and_
knows your password.
sillysaurus3 - 2 hours ago
This is the first time I've felt happy I rarely upgrade.
gaius - 2 hours ago
But someone at Apple got their bonus for shipping the animated poop
icon in time for this release.
LeoPanthera - 52 minutes ago
If you think the team that makes animojis is the same team in
charge of security or QA, I have news for you.
orbitur - 1 hours ago
I've been a developer for a long time. I understand bugs happen,
even bugs with terrible consequences. A lot of bugs seem
understandable, like I can see the chain of ifs/thens required to
end up at some hilarious broken state.But I'm breaking my brain
trying to figure out how in the hell a login attempt for "root"
will enable it if it's disabled. Why is this is a possibility, to
just enable root, no questions asked?
emmelaich - 1 hours ago
Identity management is complex and boring.Apples user management
is even more complex than most Unixes.
e12e - 9 minutes ago
I'm reminded of: "Solaris Telnet 0-day vulnerability", 2007:
https://m.slashdot.org/story/80056But this does indeed seem to be
an extra level of user-friendly stupid.
zach43 - 1 hours ago
Maybe something like this was added to make debugging/testing of
the OS easier? maybe they just forgot to remove it before
shipping the new macOS
mk89 - 16 minutes ago
That could be the case - I can't find any other possible
logical explanation, because it doesn't make any sense.
martin-adams - 34 minutes ago
Like an illusionist hiding the truth, this bug too will have a
logical explanation that will leave us in wonder for as long as
we aren't told how it happened.
migueh - 33 minutes ago
Exactly, how can this happens and no one asks.
tylerhou - 1 hours ago
Another user suggested it may have to do with Apple?s new file
system: https://news.ycombinator.com/item?id=15801643
LeoPanthera - 57 minutes ago
You misunderstood. He's talking about a password hash storage
system, not a filesystem.
OkGoDoIt - 1 minutes ago
Seems to be something related to a backwards-compatibility code
path for upgraded systems. According to multiple posts on this
thread it only affects systems upgraded to High Sierra, not fresh
installs. See https://news.ycombinator.com/item?id=15802622 for
example. Adding extra layers for compatibility complicates
testing and debugging. With this many eyes on it hopefully
someone will be able to deduce exactly what's going on.
dec0dedab0de - 1 hours ago
I'm having a hard time understanding how this could happen too.It
would have to be that looking up the root account enabled it,
maybe users go dormant or something, and this was a way to readd
them? then once it was enabled it defaulted to a blank
password, but you would think that it needs sudo to enable root
in the first place.
inetknght - 7 minutes ago
Login screen is probably already running as root in the first
place, so it already had permission to enable shell/GUI access
pishpash - 14 minutes ago
Not only enabled it but actually set an empty-string password.
Usually the stored hash for a disabled account is not in the
hash space, so it was either overwritten, or root account
password was actually empty string out of the factory. That and
the enabling of the account both point to debug code
accidentally left in (or intentional backdoor by the
disgruntled).
quicklime - 2 hours ago
Anyone else think it was a bad idea to disclose this so publicly
over Twitter? I thought that the usual practice was to let the
development team know first.
[deleted]
5ilv3r - 2 minutes ago
Time and time again we have been shown that the way to a
company's heart is through it's PR department. This is a dev
complaining to Apple like a lunchgoer would complain to Mc D's
about a bad burger. Expect more of it.
[deleted]
SAI_Peregrinus - 1 hours ago
Letting the development team know first is nice to the
development team, but not so nice to the users (especially not-
nice if there's a workaround, which there is in this case.)My
personal policy: If there's a workaround or mitigation, then full
disclosure is more responsible. If there isn't then report to
developers and CERT or similar. Never report only to developers,
always have a deadline for full disclosure, and always have a
third-party (CERT, Project Zero, etc) to disclose if you come
under legal fire.
alexwebb2 - 1 hours ago
I asked this in the other thread, but... does anyone know how big
of a bounty the guy missed by not disclosing this responsibly?I'm
guessing it probably would've been a fairly big chunk of change.
silencio - 1 hours ago
Apparently there is no macOS bug bounty:
https://twitter.com/i0n1c/status/935608248027303936
afiler - 3 hours ago
Even on El Capitan, I was able to unlock with "root" on my first
try. From there, I could add a new admin user. This seems... not
good.
joshvm - 3 hours ago
I wasn't able to do it on 10.12.6 (Sierra) though, so perhaps
there's something else odd here?
uuuuuuuuuuuu - 2 hours ago
Doesn't work for me either on 10.12.6.
jobu - 2 hours ago
When I tried to make a new user after unlocking as "root" it
ended up making a group instead. (High Sierra 10.13.1)
cthalupa - 2 hours ago
I cannot reproduce this on Sierra or El Cap
JustSomeNobody - 2 hours ago
Especially not good is Apple likely won't fix it in El Cap.
They'll tell all of us to upgrade. I don't want that buggy HS
mess.
cmurf - 2 hours ago
I can't reproduce this on a clean 10.13.1 (17B48) system, either at
the login window or an authentication dialog.Update: And even after
attempting it, checking Directory Utility the root user is still
disabled. So I wonder if something 3rd party has enabled the root
user and left it passwordless.
srathi - 2 hours ago
Confirmed on 10.13. I was even able to add a user as an
administrator after unlocking with root.
romanovcode - 2 hours ago
Who needs security when we have animoji!
tzakrajs - 2 hours ago
Can't reproduce on multiple High Sierra machines.
mikestew - 2 hours ago
Can't repro on a 2012 retina MBP running 10.13.1, attempting the
original repro and others suggested here. Until the wife walks
away from hers, it's the only machine I have available. I'm
curious as to the difference, given the high number of repros.
pault - 1 hours ago
Apparently you have to have the password field focused before
you submit. Anything in the password field (including nothing)
will be saved as the root password.
tzakrajs - 1 hours ago
Does it work if you set the root password and try again?
tekacs - 1 hours ago
Now that this is public, it's likely worth passing this message on
to non-technical folks too (e.g. share this or write a similar post
- this is my only public
post):https://www.facebook.com/amar.sood/posts/10209545863036116
jtokoph - 1 hours ago
Important error in your instructions. They should set a very
strong password and keep the root account enabled. Disabling the
root account opens up the vulnerability again.
tekacs - 1 hours ago
Edit: Okay so it seems that my shell based suggestion of
`dsenableroot -d` prevents the bug from re-occurring, but not
the GUI version. :facepalm:I updated the post to include the
word 'strong', although I would expect most users to simply set
their own password, which should provide identical security to
what they currently (should) have.Disabling the root account
does not open up the vulnerability again.This vulnerability
doesn't reset the root password, it only enables the root
account and checks the password against that. The default root
password out of the box on OSX is blank which is what allows
this to work as-is.By setting a root password, the next time
you attempt this (and I tried it), the attempt fails since the
'root' account now has a password set.Disabling simply puts the
root account back in a dormant state, where it should be for
most users, for after this vulnerability is fixed and it can't
be enabled maliciously.
[deleted]
joe_hills - 3 hours ago
I just tested this on a Sierra (10.12.6) machine, and verified this
bug isn't present in that earlier OSX version.
Cshelton - 2 hours ago
Same, I'm on 10.12.6, could not reproduce anywhere.I think I'll
hold off on that 10.13.1 "security update" it keeps bugging me
about. Seems to let anyone use my computer...Edit: After looking
a little further, it seems staying on Sierra will always be a
10.12.* version, and High Sierra is 10.13.*?
m11r - 2 hours ago
Yes, that's correct. Recent macOS (nee OS X) versions:-
Mavericks (10.9.x)- Yosemite (10.10.x)- El Capitan (10.11.x)-
Sierra (10.12.x)- High Sierra (10.13.x)
nathancahill - 2 hours ago
Fix this by setting a password for root (or disable).Instructions
here: https://support.apple.com/en-us/HT204012
Asmod4n - 2 hours ago
Doesn't help to disable it, you have to change the password.
UPDATE: if you disable the account after setting a password, a
login without a password is possible again ..
3pt14159 - 2 hours ago
Yeah, confirmed it myself too. Enable root with a strong
password works though.
bsaul - 1 hours ago
I wonder who they're going to ask to write a public letter of
apology this time.This isn't just a snarky comment. They have just
released the most awfull iOS upgrade for a long time, and now this.
Something's messed up, and they better fix it soon.I've think i've
read somewhere they merged the iOS and macOS teams, i suppose the
wrong people were promoted during the operation.
romanovcode - 1 hours ago
They will use some clever words to make it sound like a trivial
issue like they did when password was appearing instead of
password hint couple of months ago.
rimliu - 1 hours ago
> They have just released the most awfull iOS upgrade for a >
long time, and now this. Something's messed up, and they >
better fix it soon. I keep seeing this written after each major
iOS release sinc at least iOS 7.
bsaul - 58 minutes ago
For me, the most painful is that this time they managed to
screw up the damn keyboard while bringing absolutely nothing
new. I can't even use hangout or chat on my iPad Air , i have
to wait 3 seconds for my words to appear.That's just wrong.
There's no excuse for that. We're not talking about fancy
animation or new features that we think aren't a great idea.
Just a basic regression on one of the most fundamental things
you can do with this device (the other being displaying
things).Another thing is that they usually fix slowdowns and
stability with the following release soon after. Not this time,
so my guess is that it'll be a "change your device" kind of
upgrade.
saagarjha - 13 minutes ago
> I can't even use hangout or chat on my iPad Air , i have to
wait 3 seconds for my words to appear.Obviously, something's
wrong with your keyboard, but how do you know it's iOS's
fault instead of your app's?
davidkuhta - 1 hours ago
Cue "incorrect elevation of privileges" joke. sudo laugh edit:
spelling
nolok - 59 minutes ago
Nah you don't need sudo for that anymore, now you're root
intelliot - 1 hours ago
Cue
davidkuhta - 1 hours ago
doh, thanks. Can you tell what abstract data type I've been
working with lately?
butterisgood - 14 minutes ago
Doesn't work for me on a freshly installed MacOS High Sierra, but
does work on an upgraded laptop to High Sierra.Interesting...Also
the UX is different. Typing root on the fresh installed one fails,
then resets the user text box to my name, and if I type root again
it doesn't let me it.On the upgraded laptop, if I type root, it
sticks and clicking unlock twice gets me in.