About the security content of Security Update 2017-001 | Hacker News Reader

About the security content of Security Update 2017-001

support.apple.com

337 pointscmg145 comments

See Apple's comment on this, given to BuzzFeed I assume: https://twitter.com/JohnPaczkowski/status/935909264362586112 / https://www.buzzfeed.com/josephbernstein/apple-released-a-pa...

"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 if separate discussion is preferred)

Original source of Buzzfeed article, if you'd like to avoid giving them traffic:

https://twitter.com/lemiorhan/status/935578694541770752

Demo: https://twitter.com/0xAmit/status/935607313368481793

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

That's great to hear even if it took multiple stumbles for them to finally admit - but surely they should be also audit their QA/testing processes? Or does development in AppleSpeak mean everything?

It sound to me like the "development process" points to the whole soup-to-nuts system.

From "brainstorming" and new feature development, to development, to testing, to QA, to deployment.

If so, that's going to be a big undertaking :)

Or a big lip service.

I don't know how you could expect QA to be able to have a rigorous process to catch security problems of this type. It's one thing to audit the strength of crypto protocols, quite another to rigorously test every conceivable attack surface for privilege escalation. That space is vast.

Actually entering blank passwords and automated password entry should be Test Cases #0 and #1 for any thing that has a login. OS and other critical infrastructure vendors should go beyond that and explore the vast space to make sure nothing like this ever happens.

They may have even had a test case that entered "root" and no password and hit OK once, but that wouldn't have caught it. What if you'd had to hit "OK" forty-one times to trigger the bug? It's deeply unsatisfying to just say "the problem space is so vast that it's hard to even know what to try beyond the basics that every QA person knows" but I don't personally have a better answer than that. Maybe those that study the space do, though?

Fuzzing inputs

Where are all the unit/integration tests for the APIs that this damned button is calling? Hindsight being 20/20, but I cannot imagine not asserting that a newly created/re-enabled root user has a non-empty password.

I don't think empty password on root is the issue here; enabling root when the user did not intend to and did not have permission to is. Isn't empty password for root a default state for systems where direct root login is not enabled? And isn't enabling root with no password the intended behavior when booting into Single User Mode?

Exactly, testing the UI may be hard, but whatever API that UI is calling is amazingly horribly broken.

And fascinatingly wasn’t broken until very recently...

Following and furthering your logic, what the hell could they have been doing in the codebase to revert a control mechanism that was effective up to and including 10.12.6, but unsafe as of 10.13.0 onwards???

A graceful upgrade mechanism towards a new password hashing algorithm.

Change is so, so risky.

There's a lot that can go wrong, which is why writing testable code and then /actually/ testing it, matters so much.

The code was not supposed to enable the root user in the first place, so I'd be surprised if someone added an assertion that anything about the root user's account was set. It was only supposed to check the root user's password.

I suppose you could write an assertion that the code didn't enable the root user, but I'm pretty sure that no password-validation routine anywhere in the history of the world has ever had a test case to make sure it didn't modify the account while validating it.

These are unknown unknowns. If you knew enough to write the right test, you wouldn't have written the bug in the first place.

But if the 2nd attempt does something different, there must be some sort of logic happening, and whoever built this magic (maybe it's an if-block like: (if loginAttempts++ > 0) ... ) should've tested it.

We cam see that the function f(a, b) { return a+b; } should return the same value for the same a and b, so testing that once is enough. But if there's something in there that reads a global variable, maybe check who changes that global variable, and what happens with different values of that global variable?

The "logic" in this case is the first attempt failed because the root user was disabled, but as a side-effect it enabled the root user. The second attempt worked because the root user was now enabled. There's no explicit logic in here that says the second attempt should have behaved differently.

Oh it's never that easy. It happens 20 layers deep, with configuration set a certain way... only every Friday the 13th.

I.e. MacOS is based on UNIX/BSD, root is all powerfull. So root is disabled form login with <star> password, but it's still there. Then there is the Apple autentication framework on top of that, here root is disabled. But if you try to log in with root, it gets enabled but can't login because password is still <star> an disabled. Then somebody decides new password hashes are safer and we should update old hashes whenever possible. So now when a disabled root account gets enabled, the update routine mishandles <star> password and updates the root password hash with <empty string>.

And I'm sure they've had privilege escalation vulns before and a workflow already in place for catching a lot of them. I mean, it's not like Apple's totally asleep at the wheel here. OSX may not be a front-burner project anymore, but they're still supporting it better than Microsoft manages to support Windows.

But that's the nasty thing about InfoSec. It's a never-ending process. There's always realms you haven't considered yet. I'd bet that they had a process in place that they thought could catch these, but it managed to fail somehow. You're always in a hindsight-is-20-20 situation.

> but they're still supporting it better than Microsoft manages to support Windows.

I don't know what metric if any you're using to make that statement but any person working Enterprise/Corporate IT will tell you what MS manages to pull year over year with Windows, Office and bunch of other stuff is fairly monumental given the demands of their operating space. Only way Apple can survive there with their current Engineering setup/culture is if they only did simple stuff and told the customers no interop and you only get to do what we think is best for you!

I bet Microsoft really does do a great job supporting corporate users. Apple does a miles-better job supporting consumers.

(I am not a developer, nor a sysadmin, but a casual programmer and intensive power user, and I get the instant bleah factor when I come across consumers or enterprises using it.)

I’m a longtime NeXT-then-MacOSX user with an experience in commercial UNICES ante-2000 and a predilection for Linux and DragonFlyBSD for my server needs. That said, I am gaining a begrudging respect for Microsoft. They make you pay for your nose, and their stuff looks and feels clunky, but the solidity and backwards-compatibility is utterly amazing.

No way. Microsoft has teams of people who own features. Their errors tend to be regressions related to some other workaround they need to support.

Apple leaves stuff to rot, then marketing cooks up some new requirement and a few programmers rush to build it.

Disk utility is the canonical and obvious example of this. There are many others.

> Apple leaves stuff to rot, then marketing cooks up some new requirement and a few programmers rush to build it.

Is this actually true? I have a hard time believing that. Are Apple developers really jumping around product to product? I'd be very interested to get some insight into their internal processes.

I worked on mobile games few years back. Our tester always did everything that was sane and most things that were not sane. For every version. He tried to break the game. He was randomly and wildly tapping the screen. He was repeatedly going through menus. The most things he did us developers thought: who would do that? We caught lots of bugs this way.

It was a company that you never heard of. It's a normal thing for me to require such things from QA.

I also worked in big corporation that you heard about, developing embedded software. Same thing happened.

Testing is doing things that most users do. But most of all testing is monkey bashing trying to break the thing. That's the mindset that QA must have.

EDIT: typos, thanks

I've frequently seen people use "break" when they mean "brake", but I don't think I've ever seen someone get it the wrong the other way around.

Do you realize for all the unexpected bugs your manual tester caught, an equal number were simply never found?

No one said that you can't do automatic tests. Manual tests do not exclude automatic tests. But I dare to say that manual tests are essential, because that's how the software will really be used. Especially for release candidates. Apple has resources to do both repeatedly.

In this big corporation I mentioned tests were also done automatically. A device receives via infrared programmed set of commands in a loop for 24h. The test simulates a user with a remote.

Even so called gravitational tests are useful. A test where "only" gravitation acts on a device for 24h.

Those may seem dumb, but bugs can be hunted this way, that no automatic test could find. Because real hardware and release environment is messy.

That approach works for behavior and UX, but is woefully inadequate for security, sadly. The space for shenanigans is exponentially greater.

What do you mean? That is literally the job of QA. Even the worst QAs I've worked with test every input field into oblivion.

> Or does development in AppleSpeak mean everything?

It's a press release. It doesn't mean anything.

Top google search result for "software development processes" says:

What are the steps in software development?

    1. Requirement gathering and analysis.
    2. Design.
    3. Implementation or coding.
    4. Testing.
    5. Deployment.
    6. Maintenance.

So, yes, it is step 4, QA & testing.

Off-topic, but it blows my mind how poorly proofread many articles are nowadays. In this example, there's a 3-word sentence fragment - "That login gave" - hanging out in between two other sentences. If the author even read what he'd written once before posting, he ought to have caught that.

The ability to write is largely ignored at tech firms these days. Grammar is viewed as a bunch of stodgy rules to be ignored at will. Some are indeed silly throwbacks, but the basic structures are what allow us to communicate effectively. Drop them and errors in understanding creep into nearly every email.

Yesterday I had a back-and-forth with a boss over "login", "log in", "log in to" and "log into". That might seem silly but little things really do matter. (fyi, login = noun. Log in = verb. We never settled on 'into' or 'in to'.)

Surely:

    log into -> write to a specific log
    log in to -> access a certain host

no?

Fwiw, I've always used "log to" for writing out logs. "Log to stderr". So, you know, extra fun deciding what's "correct".

Sure, but that wasn't one of the options, and doesn't (to me) make the "into" case ambiguous :)

In my tech writing class for the sciences, my teacher said, "Never use a noun when you could use a verb".

Meaning, she would suggest saying: "Write a log to" and "User logs in to"; which are far more clear in their intent. :)

I think it's amazing we can even understand each other sometimes; English is quite a terrible language.

Check the dictionary -- "login" is also used as a verb: http://www.dictionary.com/browse/login?s=t

With a usage note that some people dislike it:

> And yet, this gluing together of terms like login, logon, backup, and setup as verbs is common, especially in writing about computers. Not for everyone, however. Some well-known software companies, for example, carefully maintain the distinction in their programs and documentation. But habits are difficult to change. Those who react to the one-word verb as an error will probably have to get used to it, and those who use the one-word verb will have to recognize that others will see it and wince.

It's "log in to," as "log" is a verb whose meaning changes when it accepts the preposition "in".

Dutch has this much more systematically than English, where when this happens you can form the infinitive for the verb by prepending the verb with the preposition. So "someone who breaks in" would be an "in-breaker" and the infinitive form is "to in-break". (In modern English one would have to say a "breaker-inner" to convey the idea of one who breaks in.) Similarly the Dutch might look at the verb "with-hold" and assume that you would say "the company held with that information, not disclosing it" rather than "the company withheld that information."

Anyway, since the verb is "in-log" you "log in", as opposed to the conventional meanings for the verb "logging" (writing down something or clearing trees) where you might "log into" (respectively writing down into, or clearing trees from).

I'm no journalist, but I guess that being first to report is more important than minor errors in the article.

I don't know what timezone the article is in, but it's been at least an hour. Even if "post, then edit" were the strategy, the author clearly didn't read it after hitting publish either.

Most writers for online establishments have quotas of multiple articles/day, these days. Don't blame the writer.

> worldwide computer vulnerability

hey, your preposition is auditing process is broken

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)

it's all part of the fun

> which wasn't published until the patch was available

answered your own question?

They knew the patch would be quick and was in progress, why bring extra attention to it. A few tech blogs and devs on twitter is good enough.

Exactly. They don't want this in the MSM and the MSM is usually a few days or even weeks behind the internet when it comes to things that aren't relocatable to the vast majority of people.

easy: apple never acknowledged and confirmed that it made a serious mistake/offence/liability. big difference in court if someone decides to sue.

disgusting.

This is nonsense. There are plenty of real issues here - please don’t make more up and waste our time.

I don't think it's particularly cynical-conspiracy-minded to believe that Apple's messaging, here and in every situation, is guided by a legal team. That's standard practice for every major company.

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."

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).

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...

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

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'

> On Nov 23, the staff members informed Apple about it.

For everyone kvetching yesterday about "responsible disclosure".

"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.

That's kind of what it was: https://objective-see.com/blog/blog_0x24.html

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.

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

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.

i think the problem is it is difficult to upgrade a password from one scheme to another scheme without the user presenting the password so they just decided because they are changing both systems and password schemes they would do the migration from the old system to the new system when the user logs in.

After all the shit MS got for very strongly nudging users into using MS accounts instead of local accounts and Apple's low key effort to promote OSX and iOS as better for the user (including privacy) than Windows/Android, I can't see mandatory apple account usage being a realistic probability.

The user root always existed as a disabled user. The problem was that the logic error (whatever it was) resulted in the user being enabled.

> I hope they won't stop to this brief summary

Why <blank> Gets You Root: https://objective-see.com/blog/blog_0x24.html

> 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...

I realise that this is a facile topic for engendering scandal amongst our geek demographic (and rightly so), but given the gravity of the underlying issue it’s actually entirely reasonable and indeed preferable to the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole.

I don't disagree about the necessity of being able to force updates for bugs of this severity. I'm simply pointing out that, when Microsoft does forced updates, people lose their minds with outrage.

You could argue that severity plays a role in the level opposition to such a feature however severity is an arbitrary assessment applied by the person issuing the update.

> the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole.

Last I checked macOS hadn't crossed the 50 million user mark. The combined iOS/macOS user base only just surpasses Windows.

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.

People were upset with Windows 10 for it's update policies for a number of different reasons but those very different reasons have all been lumped together into a singular general objection so that addressing one of those reasons will never solve the objection thus making the only possible solution disabling Windows Update. It's silly.

Feature updates and quality updates are handled differently in Windows 10. You can delay feature updates for a year, quality updates (security) can only be delayed for a month.

I'm not sure what specific thing you're referring to when you say "nagware", seem my first paragraph, but there's no persistent nagging in Windows 10.

Really? How do you do that? My windows machine informed me it was going to install the fall creators update when I shut it down for the night with no option not to (only to choose a different 8 your max active period)

Argh! It looks like it's only an option on Pro, my Home machine doesn't have it. That's lame...

It's under Settings -> Updates & Security -> Advanced Options on Pro.

That is the really worrying trend in personal computing as of late. Treat consumers like dumb sheep, and "professionals" are barely competent children (only devs are "responsible adults", according to themselves)...

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.

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.

It's only automatic if you have the option enabled which is the default behaviour, it isn't 'forced'. This update doesn't even need a restart.

That's not what is being reported on daringfireball (emphasis added):

"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."

I'm telling you how it is because I just did it myself, in App Store -> Software Update the update was there asking me to install it. There are options in App Store system prefs panel that let you change the default behaviour.

That being said, there's no reason why this shouldn't be applied automatically.

By default, all systems have the "Install system data files and security updates" setting in the App Store Control Panel enabled, so they will indeed automatically install it.

Apple still allows users to control their system's update behavior.

"Install system data files and security updates" is turned on by default in the App Store Control panel, but the user can turn it off if they (unwisely) wish to.

In Windows XP, for example, Windows Update had a similar option, but that was removed in Windows 10.

AIUI the expectation is that Apple is going to force all 10.13.1 machines to automatically upgrade themselves regardless of settings. This is something they've apparently done once before, with an ntpd remote vulnerability. Given the nature of this bug, forcing all machines to automatically apply this patch seems like the right move.

(BTW the patch doesn't require restarting the machine, so it's not going to interrupt anyone's workflow)

Not regardless of settings, but critical security updates will be installed without user intervention with the default settings in the App Store Control Panel.

Here's an article discussing their first use of this mechanism.

https://www.computerworld.com/article/2862976/apple-deploys-...

No, the poster you replied to is correct. If you turn that setting off you will not automatically get this update.

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

(SMB still works)

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

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)

Not to be confused with the other 2017-001 update they released one month ago: 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), 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).

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

Apple says "Not impacted: macOS Sierra 10.12.6 and earlier" in their security advisory for the patch.

My fear is that Apple doesn't know that it still affects El Capitan, though the poster I linked to could have just been lying.

Or mistaken, or confused, or...

Apple knows when the bug materialized (sounds like it was part of a UX simplification of migration and/or upgrades) and I'm sure before getting embarrassed yet again they would have done due diligence.

Probably.

It doesn't appear to affect (regular) Sierra, so if this issue exists on El Capitan, I'm guessing it's a separate, though relevant, problem, rather than being the exact same one.

I can't reproduce it on El Capitan. Doesn't prove others can't, but I'm pretty sure Apple would patch it on El Capitan too if the bug was that old - they issued other security patches less than a month ago.

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).

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.

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?

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

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

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.

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

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.

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

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.

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.

I just installed the patch on a system where I had logged into root with a blank to confirm the issue. Root login no longer works in the unlock dialog. I didn't try a more sophisticated test.

I've enabled root myself and set password on it. After installation of the patch root account was disabled.

Wow. Automatic security update locks me out of my computer without any explicit notice given. How very nice of them.

So you have only one user on your Mac and that user is named "root"? Really? That would be very strange.

I'm fairly confident most Mac users never enable the root account at all. We don't need to. I'm not sure people who've only used other Unix systems understand that; I didn't when I came to the Mac after using Linux and FreeBSD in the 1990s. You need an administrator account, but that's not really the same thing. I haven't had a root account enabled on a Mac in about 15 years. (Well, except for a 14 hour or so stretch from yesterday evening to this morning, between the time I enabled it with a strong password as a "fix" for this bug and the time the actual fix was pushed by Apple.)

At any rate, I'd be very surprised if there was even a single user literally locked out of their Mac because of this change. I think it'd have been better on general principle if they'd done some kind of check that boiled down to "if the root user is enabled but it doesn't have a password set, disable it, otherwise leave it enabled," but there may be perfectly valid reasons that they couldn't do that.

> So you have only one user on your Mac and that user is named "root"? Really? That would be very strange.

It might be the only local user with a password set, with all other users coming from a remote directory service. Think university labs.

Also, you can always pardon a single incident. But Apple got so aggressive with casualties caused by their system updates that I'm really pissed off by it.

System updates regularly reset configuration to factory settings, breaking things in the progress. Note that I'm not talking about modified system files (those we expect to get reset and thus try hard not to touch) but documented configuration points.

This arrogant mindset is best described as "you surely didn't meant to deviate from our divine default settings, so let me fix that for you!".

For some files they recently started to move your modified files out of the way (creating a backup blah.conf.$(date) or whatever) before forcing the factory config anyway. Not that we need it, but it's probably all we'll ever get.

It did for me.

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

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

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.

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

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...

It's an option that this person enabled. Nothing scary.

I opened App Store, found the package waiting and hit install, waited for a few minutes until it finished. So not automatically for me.

The update didn't auto-install for me. I suppose it only does that when "Install system data files and security updates" is enabled in System Preferences -> App Store.

right, for me neither. I can choose.

There are options in macOS to automatically install various types of updates, labeled as 'app updates', 'macOS updates', 'system data files and security updates'. Maybe m6g6a has the last one checked.

I opened App Store and just had it waiting for me. Where the name would normally be in the Updates tab, it just reads "Install this update as soon as possible." [0]

[0] https://imgur.com/a/bMUKO

Edit: According to Apple's statement, they will automatically start installing the update on systems running 10.3.1 later today.

Not for me, it's waiting for me to click install in the App Store. Its pretty well highlighted though.

It almost shouts at you. Mine says "Install this update as soon as possible"

Whoever installed the OS agreed to it. http://images.apple.com/legal/sla/docs/macOS1013.pdf:

”Q. Automatic Updates. The Apple Software will periodically check with Apple for updates to the Apple Software. If an update is available, the update may automatically download and install onto your computer and, if applicable, your peripheral devices. _By using the Apple Software, you agree that Apple may download and install automatic updates onto your computer and your peripheral devices_. You can turn off automatic updates altogether at any time by changing the automatic updates settings found within System Preferences.”

They do have this capability, and have for years, although they rarely use it. They're force-pushing this update later today. It says so right in their statement:

"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"

Is it possible that "Automatically check for updates" and "Install system data files and security updates" are set in your system preferences?

I have that enabled because this is exactly the kind of thing I want patched ASAP.

Yes, you right. I checked them.

Apple has used the force-upgrade path which you cannot opt out of (at least not easily) and which is permitted by their TOU, exactly twice, both to address serious security vulnerabilities.

Once for this problem, and once for the NTP security bug in 2014. That is it.

https://support.apple.com/en-us/HT204425

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

From what i understood it's not a remote vulnerability until someone actually activates the "root user with empty password" locally using the vulnerability.

You could exploit it with remote desktop. If it's enabled on the client, you can just connect with root/no password.

It's from any login prompt, and it gives root, so it's an elevation vulnerability that could be leveraged by a local or remote process with limited privileges to gain elevated privileges.

Once the exploit is done (clicking the unlock button w/ the user root on the settings pane), the root account is setup with a blank password. At this point any remote access methods that use the accounts on the system should allow access. Depending on SSH config, root may be disallowed.

I've seen rumors otherwise, but until someone with experience verifies those pathways I can only guess.

Not any method. It worked for screen sharing but it did not for SSH, even after the bug was triggered locally.

I'm not near a macOS box at the moment, but I believe that

  PermitRootLogin no

is set in

  /private/etc/ssh/sshd_config

I read that it worked even with Remote Management and Screen Sharing. https://twitter.com/voretaq7/status/935609138725425153

Which means that by default, a Mac would not by vulnerable remotely, but you'd only have to click one checkbox to become exposed remotely.

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.

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

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.

> 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. :(

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

Reply on news.ycombinator.com