"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."
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)
"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).
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.
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.
> 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?
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?
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.
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.
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???
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?
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 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.
> 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.
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.
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'.)
> 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 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.
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'
"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.
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.
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.
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.
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.
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.
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)
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)...
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."
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.
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.
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.
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.
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)
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?
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).
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.
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.
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?
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.
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.
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.
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.
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]
”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.”
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.
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.
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"
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.
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.
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.
From what i understood it's not a remote vulnerability until someone actually activates the "root user with empty password" locally using the vulnerability.
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.
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.
> 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. :(
"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)