
About the security content of Security Update 2017-001 - cmg
https://support.apple.com/en-us/HT208315
======
tomduncalf
See Apple's comment on this, given to BuzzFeed I assume:
[https://twitter.com/JohnPaczkowski/status/935909264362586112](https://twitter.com/JohnPaczkowski/status/935909264362586112)
/ [https://www.buzzfeed.com/josephbernstein/apple-released-a-
pa...](https://www.buzzfeed.com/josephbernstein/apple-released-a-patch-for-
that-massive-security-flaw-in)

"Security is a top priority for every Apple product, and regrettably we
stumbled with this release of macOS.

When our security engineers became aware of the issue Tuesday afternoon, we
immediately began working on an update that closes the security hole. This
morning, as of 8:00 a.m., the update is available for download, and starting
later today it will be automatically installed on all systems running the
latest version (10.13.1) of macOS High Sierra.

We greatly regret this error and we apologize to all Mac users, both for
releasing with this vulnerability and for the concern it has caused. Our
customers deserve better. We are auditing our development processes to help
prevent this from happening again."

(posted to
[https://news.ycombinator.com/item?id=15808164](https://news.ycombinator.com/item?id=15808164)
if separate discussion is preferred)

~~~
0x0
Why is all communication from Apple on this case, both yesterday and today,
being channeled via screenshots of text appended to random twitter users posts
or blogs? It's weird that there's no official page on apple.com for these
statements. (Beyond the actual "security update 2017-001" announcement
webpage, which wasn't published until the patch was available)

~~~
robotresearcher
Apple's answer is on that page:

"For our customers' protection, Apple doesn't disclose, discuss, or confirm
security issues until an investigation has occurred and patches or releases
are available."

~~~
0x0
I'd say that works against the purpose of protecting customers. Every blackhat
in the world had probably heard about it last night, but if Apple had
announced details earlier, even without a patch, informed customers could take
preventive action (such as not connecting to public wifi, disabling screen
sharing, etc).

------
sccxy
Real problem is that if you are nobody then your private bug reports mean
nothing. Only public shaming helps here.

[https://medium.com/@lemiorhan/the-story-behind-anyone-can-
lo...](https://medium.com/@lemiorhan/the-story-behind-anyone-can-login-as-
root-tweet-33731b5ded71)

Author of this tweet said that Apple was informed at least week before tweet,
but zero response.

~~~
londons_explore
Lots of companies are quite good at handling security vulnerabilities, but
somehow still neglect to reply to the original reporter.

Usually there's a long chain of people involved in creating tickets,
allocating resources, finding the bug, fixing the bug, QA, release processes,
documenting the problem, making security bulletins, translating security
bulletins, etc.

Each of those people communicates via internal processes the reporter doesn't
have access to, and none of them think to ping the original reporter saying
'yo - bugfix complete, qa next, then release'

------
bsaul
"Description: A logic error existed in the validation of credentials. This was
addressed with improved credential validation."

I hope they won't stop to this brief summary, because a "logic error in the
validation of credentials" shouldn't be able to allow the creation of a root
super user with empty password.

I'm hope they'll go deep in the gory details, to show us how it's in fact much
more complicated than a "if !password { createEmptySuper()}" line written by
mistake.

~~~
Bogdanp
That's kind of what it was: [https://objective-
see.com/blog/blog_0x24.html](https://objective-see.com/blog/blog_0x24.html)

~~~
zbentley
It seems to me that the biggest problem highlighted by the link in parent is
backwards compatibility of authentication metchanisms. OSX seems to support
typical /etc/passwd hashed-user-credential authentication. However, it tries
to "upgrade" that authentication mode to "shadowhash or securetoken", which
appear to be two new auth schemes integrated with Open Directory.

All of those things might be fine, on their own.

However, the biggest issue is that there are now _more than one primary way to
get authenticated on the system_. This is likely true because network accounts
need to be supported in addition to local ones (I.e. apple accounts, LDAP
accounts, etc.). However, my (admittedly uneducated) impression is that the
systems for handling those accounts are totally separate--the part of the auth
system that is swappable between shadowhash/old-school-passwd/etc. is . . .
basically the whole auth system.

I'm sure that's a very quick and easy way to write authentication code, and it
also preserves backwards compatibility of users doing the old method, but it
seems inherently prone to more issues (even if you don't make screw-ups as
obvious as this one). You have more auth stacks (and thus code) to debug in
total, to say nothing of code that migrates credentials between different auth
stacks.

Preserving backwards compatibility is important, to be sure, but only
sometimes. This seems like a case where things would have been easily
mitigated if Apple had done something like "everyone must sign in with their
Apple account, now, as the sole authenticating credential for this operating
system" during some OS upgrade (or "/etc/passwd no longer works; all these
systems have been refactored to use a single central credential database in
Keychain Services, update any code that cares since it's being aggressively
deprecated", though that would probably have been both harder to implement and
harder to sell to the user/developer-base). However, I'm far from an expert
here, so maybe the "just expand on the existing UNIX local auth system" option
is less-infeasible than it seems (linux ditched this too for network accounts,
though, which doesn't give me confidence).

Either way, an old-auth-system removal like that would have crippled some of
my workflows/code, and others', but it also would have allowed Apple (if they
followed it up with a dead-systems-removal pass) to remove many of the then-
redundant authentication systems in OSX.

TL;DR Linus isn't always right, backwards/userland compatibility shouldn't
always be held paramount, especially when you're developing parallel systems
for something as critical as authentication. Sometimes the pain caused by
deprecation is worth the removal of a security risk.

~~~
biggieshellz
Mac OS X has always used POSIX compliance as a selling point. Would the change
you're suggesting break that?

~~~
zbentley
I think they have already broken POSIX compliance in this area. A lot of the
/etc/passwd entries don't do anything by default (like the root entry, in this
case, whose significance in that file changes based on an external, second,
unrelated-to-POSIX auth system).

While the file is still there in the same form it would be on a truly POSIX
compliant system, the functionality is not.

The change I proposed, or other equivalent changes, might "loudly"/fatally
break programs that rely on the /etc/passwd style of auth, but if those
programs are depending on POSIX-compliant behavior based on that file on OSX
systems already, they are likely "silently"/more subtly broken (which, when it
comes to code that interacts with the security system, is a much worse thing,
I think). It's the same old accessibility/security compromise as ever though.

------
cptskippy
> it will be automatically installed on all systems running the latest version
> (10.13.1) of macOS High Sierra

So uh... where are all those people who lost their mind about Windows 10
forcing updates?

[http://i2.kym-
cdn.com/photos/images/newsfeed/001/042/619/4ea...](http://i2.kym-
cdn.com/photos/images/newsfeed/001/042/619/4ea.jpg)

~~~
benchaney
People weren't upset about windows installing _security_ updates. If this
update adds nagware to OSX or forces people to restart their computer in the
middle of whatever they are working on, your comment will be a fair point.
Until then, it is an stupid comparison.

~~~
arachnophobe
As of the latest update macOS has started to nag me to allow automatic
updates, so I think the comparison is probably valid.

FWIW I told it No, for the same reason my Win10 laptop has been nagging me to
update but I've not let it install for a month - until I've finished whatever
work I'm doing I'm not going to let a possibly badly written patch stack the
OS and leave me rebuilding the machine from scratch (yes - I'm looking at you
Windows - TWICE) or dealing with whatever beta-level release macOS is going to
throw out that breaks remote access etc. that I need on my build server.

~~~
cptskippy
Oh geez. Have you ever tried to skip iCloud setup? Or Cloud Keychain? Or two
factor authentication?

It's like trying to leave a time share presentation.

------
bonaldi
Apparently this forced update breaks file-sharing(!):
[https://forums.macrumors.com/threads/security-
update-2017-00...](https://forums.macrumors.com/threads/security-
update-2017-001-breaks-file-sharing.2091913/)

(SMB still works)

~~~
LeoPanthera
NFS is still working for me. I thought "file sharing" _was_ SMB. AFP is
deprecated. What other kind of file sharing is there?

~~~
bonaldi
I think they're talking about AFP, which is still in use in a lot of places
(you can't share ADFS over AFP, but you can connect to/share non-ADFS disks)

------
spatulon
Not to be confused with the other 2017-001 update they released one month ago:
[https://support.apple.com/en-gb/HT208221](https://support.apple.com/en-
gb/HT208221)

The App Store Updates page on my mum's Macbook Air now shows that she has
installed two updates called "Security Update 2017-001", and she started to
worry that she didn't have the correct update installed today.

They both link to the same page ([https://support.apple.com/en-
gb/HT201222](https://support.apple.com/en-gb/HT201222)), so it took me a while
to figure out what was going on, and that she really had installed two
distinct security patches (one before upgrading to High Sierra, one after).

------
prophesi
I heard the bug was working on El Capitan for some people [1]. Some Mac
devices aren't able to upgrade past El Capitan; will they just forever have
this vulnerability?

[1]
[https://news.ycombinator.com/item?id=15800817](https://news.ycombinator.com/item?id=15800817)

~~~
geofft
The link you post claims that root/empty password worked on the first try, not
the second, which probably means that the system in question had the root
account enabled with an empty password already (which is a thing you can
intentionally configure and then forget about).

~~~
prophesi
Ah, that makes sense. I haven't heard of any other instances of this, so I
think it's safe to say El Cap isn't vulnerable.

------
robin_reala
Earlier today I set a root password. Can anyone confirm what the steps are to
get back to the original state of a disabled root account with no password?

~~~
mikeash
Open Directory Utility.app, click the lock to make changes, then Edit ->
Disable Root User.

~~~
robin_reala
Ah, looks like it was automatically disabled again by the patch, so nothing to
do.

~~~
mikeash
That's interesting, it seems to have disabled mine as well, even on the
computer that already had a root user enabled from before. I'd guess they
can't distinguish between root accounts deliberately enabled by the user and
accidentally enabled because of this bug. Fun stuff. No trouble for me, at
least, I'm not even sure why I had it enabled in the first place.

------
pandalicious
Does their patch also disable root accounts that were enabled using the
exploit?

~~~
myfonj
That last sentence [0] suggests that the patch will disable every single
activated root account.

[0]

> If you require the root user account on your Mac, you will need to re-enable
> the root user and change the root user's password after this update.

~~~
londons_explore
Which could lock some users out permanently if the root user was the only user
they knew the password to.

~~~
geofft
It's impossible to have full-disk encryption with that config, right? (i.e.,
does FileVault work for the root user?)

If you can get in from an install CD, you can reset passwords as needed.

If I were writing this patch, I'd probably check to see if the root user's
password was indeed blank, but given that use of the root account only is
extremely unsupported I cannot get too upset about Apple breaking that use
case as long as you can get back in.

~~~
comex
The issue wasn’t actually specific to a blank password. You could try to log
in as root using _any_ password, and as long as root had never had a password
set, it would fail but set root’s password to whatever you entered.

------
m6g6a
Kinda aggressive. I don't even clicked on update and they already did that for
me.

~~~
sillysaurus3
They force-pushed code to your box without you agreeing to this? Can anyone
else confirm?

~~~
bpicolo
It's a massive global security vulnerability with huge amounts of public
exposure (so any malicious user is well aware they can take advantage). If
they did, wouldn't be surprised and I'd be glad they did.

~~~
inetknght
If they did for this, great. But the fact that they _could_ for any other
update, too, is what's scary.

~~~
0x0
They do this all the time with invisible updates.

Click AppleMenu > About this mac > System Report, and scroll down to Software
> Installations, and click on the "Install Date" column header twice to sort
by install date descending, and you will discover apple pushing updates very
frequently for things like "MRTConfigData", "XProtectPlistConfigData", "Voice
Update - Samantha", "Gatekeeper Configuration Data", "Chinese word list
update" etc etc.

It's not without flaws; at least once they slipped up and pushed a blacklist
for their own ethernet adapter driver (cutting off their own patch life-line,
I guess, for those affected) : [https://www.digitaltrends.com/computing/mac-
update-breaks-et...](https://www.digitaltrends.com/computing/mac-update-
breaks-ethernet-fix/)

------
eklavya
Haven't seen this mentioned anywhere so far but this was not a remote
vulnerability right? Only from login screen, right !! ??

~~~
jorisw
I read that it worked even with Remote Management and Screen Sharing.
[https://twitter.com/voretaq7/status/935609138725425153](https://twitter.com/voretaq7/status/935609138725425153)

~~~
crankylinuxuser
Yep. We blocked VNC at the border routers. Now you need to use our VPN in
order to use VNC.

And we are very glad to know we can triage and log. Yeah internal users could
still exploit machines. But that fact is recorded. Fired and criminal charges
are not a light thing.

~~~
jlgaddis
So you log and audit this kind of unusual event, but you didn't require VPN
access for critical resources?

~~~
crankylinuxuser
I'm not going to talk about our intricacies of security. But it should go
without saying that all the critical stuff is much more locked down.

This policy applies to everyone. Students, faculty, staff. Previously, a
student could set up VNC to allow remote access to their machine in their
dorm. Now it takes VPN to do so.

------
exabrial
> We are auditing our development processes to help prevent this from
> happening again

The root of the problem is the CEO has put an emphasis on flashy useless
features rather than quality. Jobs realized that quality was ultimately what
sells first, followed by practicality, which was driven by need and
innovation.

The Steve Ballmer of Apple thinks has squeezed creativity at Apple dry. Sad to
see problems from the hardware division start to creep into the software
division. :(

------
ratsimihah
Wow I'm glad that happened BEFORE Apple hired me. Not that they hired or will
ever hire me but, just saying.

