Apple Releases macOS High Sierra Security Update to Fix Root Password Vulnerability

[leman]

Are automatic tests always 100% reliable, checking all corners of all possibilities for all potential disaster situations; ie not this particular situation? For all other companies maybe, and not Apple?

Automatic tests are quite reliable in finding stuff like “can one elevate to root without inputting a password” come on, we are not talking about an elaborate hack here. Of course you can’t prevent every single bug with tests but you can prevent obvious and very serious blunders like this one.

 

[chrfr]

could someone contact apple to tell them that the Build Number does not appear on About Mac - Overview?

The only way to see the build number is by the terminal command

 system_profiler SPSoftwareDataType

I would do it but I don't know how. please PM me if you do it thanks

Just click on the version number text in the "about this Mac" window. It's detailed here:
https://support.apple.com/HT201260
You can also enter

sw_vers

in Terminal.

 

[RyanXM]

Wasn't this bug out for weeks? It wasn't discovered yesterday.

The "root" user bug was discovered and communicated to Apple on November 13th via the Apple Developer forums.

 

[citysnaps]

Automatic tests are quite reliable in finding stuff like “can one elevate to riot without inputting a password” come on, we are not talking about an elaborate hack here. Of course you can’t prevent every single bug with tests but you can prevent obvious and very serious blunders like this one.

And if there's a flaw in the automatic test procedures? Procedures a human has to develop to hopefully robustly test all potential user stimuli when engaging the OS in relevant potential states that could result in an adverse consequence, in which proper detection (by automatic tests) is key.

You're correct, were not talking about a hack. We're talking about a certain set of user stimuli that resulted in the equivalent of a password confirmation, and in this case a password that was not previously set and/or a state not properly initialized for that situation. I imagine there could be other multiple stimuli sets that could result in the same (or similar) adverse result, or a different adverse result, that might not be tested for or properly detected by automatic tests.

And the above is just a single instance of a flaw with adverse consequences. How many more potential flaws are there? Who knows - I'll let others estimate. A large number wouldn't surprise me.

 

[Fukrhed]

I actually am surprised that this turned out to be a bug. I noticed this issue a few weeks ago I just thought that it was just something with my computer for some reason. I didn’t know who to tell, didn’t think of tweeting it. For those that are on beta I think there’s an easy fix. All you need to do is:

1. Open Directory Utility
2. Click the lock to make changes
3. Select Edit on the apple menu
4. select disable root user
5. or change root password

 

[Tech198]

And the above is just a single instance of a flaw with adverse consequences. How many more potential flaws are there? Who knows - I'll let others estimate. A large number wouldn't surprise me.

True, but you only do this once... as far as i'm convinced.

It shouldn't have happened, and i still dunno why Apple doesn't just give root a default password with the password in txt file or something in the placed in home folder.

It doesn't even have to be that complicated..

If this was in a password website type issue, the reserve would be trur ("no blank password")

Why would that be different in an OS, just because its in users & groups doesn't make it anymore hidden and less of a worry, to keep the password blank

 

[stanwalters]

We (anyone who codes) make all kinds of errors, all the time. That's why even the smallest development concerns do QA and regression testing. With the level of test automation that exists these days there is no excuse for something of this magnitude to make it outside of the building.

This is another example of the slow decline in quality we've seen over the past 6-7 years. For a good summary of the phenomenon check out the 'Apple Core Rot' blog, which lists quite a few other examples (https://macperformanceguide.com/AppleCoreRot-intro.html). It's not your imagination - major issues (like WiFi on OSX) remain unresolved across multiple versions of OSX, while we get fresh phone features nobody asked for and useless bloat with each new release.

We might not be in this situation if we had a few more people on QA testing and a few *less* people working on crap like emoji and redesigning iTunes and Safari icons.

People make mistakes. I guess we can rest that all of you negative posters are perfect and your coding skills are simply unparalleled and you never have made an error. All you need to apply for jobs at Apple so in the next 30-60 days apple doesn't file for bankruptcy.

 

[Burger Thing]

We need longer update cycles among the various OS. Apple clearly is unable to cope with its present yearly updates. Is there really a need - or pressure from the competition to have, for example, iOS updated yearly? While Google is throwing out new Android Versions on a yearly basis, too, hardly no one is able to use it anyway, so who really cares? Take your time and polish your software, Apple. Same applies to MacOS. vs. Windows, of course.

 

[leman]

You're correct, were not talking about a hack. We're talking about a certain set of user stimuli that resulted in the equivalent of a password confirmation, and in this case a password that was not previously set and/or a state not properly initialized for that situation. I imagine there could be other multiple stimuli sets that could result in the same (or similar) adverse result, or a different adverse result, that might not be tested for or properly detected by automatic tests.

No, we are not talking about a set of user stimuli. We are talking about a botched credential check procedure. Again, checking whether credential check on root with empty password passes is not exactly rocket science and it would have prevented this situation.
[doublepost=1512026562][/doublepost]

We might not be in this situation if we had a few more people on QA testing and a few *less* people working on crap like emoji and redesigning iTunes and Safari icons.

I wonder why some people keep repeating this clearly fallacious "argument". Firing artists won't improve software quality. Moving artists to QA probably won't either. The issue is not "crap like emoji" but lack of sense of responsibility in the developer team, combined with code management issues. And that is much more difficult to fix. What we are talking about here is a culture change.

 

[MH01]

Of course I understand how bad that is. Who is saying it's an acceptable bug? No one here - that's a straw-man you're creating simply to create drama where none is necessary. Most everyone here gets it without need for your assistance. There is no perfection and stuff happens, no matter how robust you believe your test plan is.

And, I'm not minimising the bug at all. What I'm saying is it's virtually impossible to test all corners of a piece of complex software such as an OS. Some bugs that creep in will be innocuous. Some will be incredibly important. You don't get to choose what kind and where they'll show up, no matter how comprehensive and robust you believe your test plan is.

The important thing is Apple jumped on it immediately the first day it was revealed, with a temporary user-fix. And then, in less than a day's time, had a solution that solved the problem. That's what counts.

" You also ignored my question in relation to software development. I assume you were not a software engineer ?"

Well, you've assumed wrong - which is not surprising based on your earlier characterizations - the latest suggesting I speak for "us," meaning all software engineers. As I mentioned in the past, I'm a hardware and systems engineer, mostly architecting and setting requirements for hardware-based high-speed signal processing systems that include software, but from time to time in the past have written my share of software supporting various projects and teams to help out as a software engineer, using various languages, at both the hardware and operator interface level. As I do with hardware design as well. I have also written specs and proposals for projects where software was a major part of the project. And have also managed software engineers as a program manager for deliverable projects. And I even write manuals, when necessary.

But that's neither here nor there.

The issue here is not the debate about "bugs" , bugs is what everyone .... that is very pro apple uses as an excuse for poor QA and shipping unfinished software , cause the real issue is devs are not given enough development time, being forced into annual updates , many gimmicks lead by marketing .

The the issue here, a backdoor, sounds like a devs, or devs were allowed to created one for dev purposes and it got to productions..... that is not "bugs" and you cannot use a blanket owwwww bugs happen it's okay.

I say This cause the people on these forums are the huggest hypocrites when any company other than Apple messes up like this , say google ..... and when apple does it.... owww you can't test everything.... hence , sorry , but I say rubbish, this is massive and not acceptable . Your test coverage for accounts / security should be as close to 100% percent, and regression testes maintain that. Your test coverage on Bs gimmicks 20-30% percent ... who.... yeah cannot test all, but you test the critical functionality .... and not allow backdoors, but hey .....stupid deadlines ... means short cuts.... so I say, markerting and Tim agreeing is the issue here. Bring back quality....and that means removing this annual BS launches that are buggy - that is the real issue

 

[Baby12]

There's no new emoij? Oh wait. Great Apple the best company in the world let hackers hack your computer without root password. Amazing.


BTW: this bug was discovered fortnights ago

 

[DeepIn2U]

That was quick

THIS is what I call a fix. Not that manual work around posted on a support page.

Awesome Apple ... hoping this doesn't occur again.
[doublepost=1512031894][/doublepost]

Does Craig loose some stock options for this and other software bugs that seem to become more prevalent with Apple software?

I doubt it, however he SHOULD! I'm curious what will happen with Siri now that it's under his management, although a specific team member is the lead on Siri.

Bertrand has 1 working eye and I NEVER seen such a grave issue with any OS X release such as enabling and setting a blank root user account/password when he was in charge! That man was a genius ... wish he was still in charge of OSX, ahem macOS.

Wow, some folks at Apple surely pulled an all nighter to get this one out.

Yes they most likely did ... testing it internally across Apple's internal computers, then down to store computers, and most likely notified Craig F early morning before the push was officialized; whilst he was practicing "nehs" on his unicorn animoji.

The update also appears to disable the root user even in cases where you had changed its password.

a PROPPAH fix at that then indeed!

Faith in Apple restored.

 

[iBungie]

I actually am surprised that this turned out to be a bug. I noticed this issue a few weeks ago I just thought that it was just something with my computer for some reason. I didn’t know who to tell, didn’t think of tweeting it. For those that are on beta I think there’s an easy fix. All you need to do is:

1. Open Directory Utility
2. Click the lock to make changes
3. Select Edit on the apple menu
4. select disable root user
5. or change root password

Thanks for this suggestion however having tried disabling root user via both my proper admin login and logging in as 'root' with blank password this does not work for me. I can still login in after the boot screen using 'root' and blank password.

10.13.2 beta 5 public 17C83a

UPDATE

As a second step instead of disabling I chose to change the root password. AT first this ddid not in itself solve the problem. Then I tried a third step - having set a root password I now disabled root user.

This seems to work. I can no longer login as root with a blank password. Also the additional 'other' login icon after the boot screen has now been disabled and Im back to only my login icon showing.

Cautiously awaiting an update/patch

 

[adrianlondon]

Thanks for this suggestion however having tried disabling root user via both my proper admin login and logging in as 'root' with blank password this does not work for me. I can still login in after the boot screen using 'root' and blank password.

10.13.2 beta 5 public 17C83a

The bug is that you can log on as root with no password if the root user IS DISABLED. You need the root user to be enabled and a password set. (Or, install the patch which stops a disabled root from being used, for those on 10.13.1 or 10.13)

 

[iBungie]

The bug is that you can log on as root with no password if the root user IS DISABLED. You need the root user to be enabled and a password set. (Or, install the patch which stops a disabled root from being used, for those on 10.13.1 or 10.13)

Was offline experimenting when you replied - and having tested options I can confirm setting a password then subsequently disabling root user seems to work in 10.13.2.b5

 

[ArmCortexA8]

I did a screen recording with Quicktime and put it on Vimeo -

 

[citysnaps]

The the issue here, a backdoor, sounds like a devs, or devs were allowed to created one for dev purposes and it got to productions..... that is not "bugs" and you cannot use a blanket owwwww bugs happen it's okay.

And that is pure speculation. Plain and simple.

And no one here is saying it's OK. More inaccurate characterization on your part.

Once more, what's most important, is how Apple handled the situation.

 

[Habakuk]

SECOND Security Update!

Apple published another update some minutes ago.

My advice: Restart your machine after the update! Check the build number in "About this Mac" (click on 10.13.1). Is it 17B1003 (after the second update)? If not: Start your machine new. You'll encounter a "Setting up your Mac" routine when it starts (pretty unusual for a "normal" restart).

Here—MacBook Pro (15-inch, Late 2016)—it was 17B48! Only after the restart it was 17B1003!! I hope Apple didn't forget that after the update a restart is obligatory! After both updates a restart was not required by default. (Or it's just the build number which is flawed. Confused.)

Btw when you installed the first security update only the build number should be 17B1002.

Attachment (screenshot): Both updates in the "recent updates" list in Mac App Store (German-language).

Edit: A buddy told me that it isn't necessary to restart the machine for being able to see the most recent build number. BUT you have to close and open again the "About this Mac" window. I can't verify this right now. Please restart your machine anyway.

 

[0837990]

It was quick. Period.

Considering the severity of this issue, it was not. Double Period..

 

[MH01]

And that is pure speculation. Plain and simple.

And no one here is saying it's OK. More inaccurate characterization on your part.

Once more, what's most important, is how Apple handled the situation.

Stop. Look at you knee-jerk reaction to post #51 , a poster asks for "better testing"........ inaccurate characterisations... look at the mirror . The poster is correct, there should be better testing, so such major bugs do not make it through.... You are really tying to find excuses for it, saying that bugs are part of development, and that's just the way it is. Wrong, bugs like this are not part of development that we accept, this is a major screw up. So when you refer this to as part of the bug process......way to down play it in my opinion.

As for my speculation, sure, I don't have access to the Code base, my speculation is as silly as your speculation that users should no be be allowed to ask for better testing..... they have every right. Telling someone bugs are FINE is missing the point of software development.... trend should be push back for better QA and not acceptance that crap can be shipped...

Ignore all you want, though if you want to understand software development and where the problem is, I've explained it to you, deadlines....that is what causes bugs like this. This is the real issue here! This is apple's fault, they set unrealistic deadlines on devs, software gets pushed out, without the necessary test coverage. I guarantee you that a call was made to ship the OS with lots of critical and high severity bugs they knew about, this is one they did not..... time time time.... is the enemy of development when the deadline is set..... good old Annual MacOs and iOS marketing gimmick is bitting apple in the butt..... and that is reality...each year iOS and MacOs is buggier and buggier.....

 

[PinkyMacGodess]

Maybe reread the announcements. You seem confused on the basic details.
Effects 10.13.1 specifically.
The fix does not put in a password.

Then why the requirement to change the password to re-enable root access? Or is a password now required for root?
[doublepost=1512047892][/doublepost]

Considering the severity of this issue, it was not. Double Period..

It should never have happened. Triple exclamation points

 

[citysnaps]

Telling someone bugs are FINE is missing the point of software development

Bugs are FINE? Nowhere did I tell someone that. That alone speaks volumes about the veracity of your posts. There are many more in your last post, as well.

 

[tipoo]

This was known two weeks ago, and only got a 24 hour drop everything and fix **** patch when it got picked up by the media. Oof.

https://forums.developer.apple.com/thread/79235

This is another thing I'm finding about Cooks Apple. **** doesn't get fixed until there's a critical mass of negative press.

 

[iShater]

Almost sounds like a brute reset of the account to fix the issue.

 

[citysnaps]

This was known two weeks ago, and only got a 24 hour drop everything and fix **** patch when it got picked up by the media. Oof.

https://forums.developer.apple.com/thread/79235

This is another thing I'm finding about Cooks Apple. **** doesn't get fixed until there's a critical mass of negative press.

I'm looking through the post you referenced. At what point did someone there take the time to notify Apple of the issue?

It seems it took until late November (the 28th, two days ago) to conclude this was indeed a security issue. The OP apparently didn't come to that conclusion. Someone asked on Nov 28 why the issue wasn't reported to Apple's bounty program.