Sacking them is not a good idea. They are the same people who would be required to fix it.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Releases macOS High Sierra Security Update to Fix Root Password Vulnerability
- Thread starter MacRumors
- Start date
- Sort by reaction score
Sacking them is not a good idea. They are the same people who would be required to fix it.
You have it backwards. Human testers would never have found this. In fact, that is what automated testing is-- once a human thinks to test the product certain way, that sequence is captured and automated.
In this particular case, the user had to go through a specific sequence in terms of cursor placement and keystroke entry. Unless the human is following a specific detailed script (which they wouldn't be-- since anything scripted would immediately be automated), it is completely arbitrary whether they would go through the exact sequence required to trigger this bug.
Discussed this at work. There’s zero chance that testing would find that kind of problem. This is a problem with the development process.
But if you take away complaining how else can MacRumors members express their hyperbolic self-righteousness?
They started fixing it two weeks ago. Two weeks is fast to get a patch out. That's why they were able to get it out almost as soon as it went widely public.
The password was blank because root login is disabled by default in macOS. This bug was improperly enabling it without going through the steps of creating a proper root account.
Still, this mistake by Apple is amateurish. Checking for lack of passwords for pre-installed admin level accounts like this (that are not a part of the first power-on setup sequence) is one of the first things that any test bucket should include, automated or no.
The fact that a company like Apple was not checking for this is completely facepalm-worthy.
It's a System Preference you can easily disable. In fact, I believe it first shows up as an opt-in. I had mine disabled for a long time before I finally decided convenience was more important to me than that bit of security. But, it's certainly a sound decision to disable it or refuse it.
I'm on the beta so am not getting this update - plus I'm not affected anyway as I have an enabled root user and a decent password. But I'm curious ... is this update disabling the root user even if it's enabled? I use mine quite regularly and I'll probably get confused as to what's going on before I remember to re-enable it if that's the case.
Regularly makes ads that tout it's superiority to Apple often making fun of Apple users. The ads have been aimed at iPhone vs. Samsung phones. The original OP's point was in reference to this.
As I understand the bug, it's not a lack of a password. It's a blank password. There's a big difference in terms of the user sequence. You actually have to place the cursor in the password space as if you are going to type a password.
That was a quick turnaround to patch up for the security vulnerability, look like this is real important issue.
Now my question - how do I check the log who is trying to take advantage of this security loophole?
Now my question - how do I check the log who is trying to take advantage of this security loophole?
I didn't turn much up (anything, actually) looking at the Console just now but you can start by narrowing the list of "who" to anyone who had physical access and a login in the last 24 hours.
So here's the thing, I agree that there's a definite WTF moment here. But I don't agree with what the answer should be. OS X has shipped with a disabled root account with no password since 10.0. This is not new, and if that by itself was a problem, we'd be hitting this much sooner, not nearly 2 decades later.
To be able to use root, you have to elevate using an admin account's credentials in this state. That's actually not bad practice (and is common on Linux systems). The real WTF in my mind here is that this piece of code had the permissions required to be able to enable root without also requiring the admin account's credentials to elevate. That tells me that this elevation dialog itself is running elevated code, and would be a great point of attack if you can get it to do arbitrary things, like the flaw demonstrated here. That is a giant WTF to me.
You should not have to mass deploy.
"This morning, as of 8 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 installed beta 5 yesterday evening and the root bypass didn’t seem to work on that. Really quick.
So the fix changes the password (puts one in) and disables root. Okay. how did 13.x ship with that flaw?
Please do tell ...... seriously.... realised you were a photographer , though did not know you moonlighted in developwment . I've been in software development for 17 years, please explain to me how reaction to this is knee-jerk? And while you are there, what priority of bug is this ?
Clearly apple are fools, cause thier reaction was knee-jerk and a patch is out already....
I'm so intrigued ....
That particular response was knee-jerk in nature.
So all of software you have developed/tested over your 17 years, at the scope similar to a major operating system, was delivered 100% bug-free? Tell me more...
With respect to my photography and engineering background, you may not know some people have had multiple careers.
currently running MacOS 10.13.2 beta 4 public
now eagerly awaiting security patch
I tried this and was able after a couple of attempts to gain access to login options for example - though not sure how a third party would access this unless i handed over my laptop whist logged in and screen active.
That said, this is a surprise!
I wonder why it takes a few tries to succeed with ID root and a blank password? It hasn't worked first time in the few attempts I've made just now.
now eagerly awaiting security patch
I tried this and was able after a couple of attempts to gain access to login options for example - though not sure how a third party would access this unless i handed over my laptop whist logged in and screen active.
That said, this is a surprise!
I wonder why it takes a few tries to succeed with ID root and a blank password? It hasn't worked first time in the few attempts I've made just now.
Good. May this be a wake up call for the need to reinstate a Mac OS software team and that exploits like this do not slip through the cracks again. Last Fall, hardware. This Fall, software. 