Big Christmas bonus for the person who found the photograph to accompany this article :-)
Pro tip: You can log into macOS High Sierra as root with no password
A trivial-to-exploit flaw in macOS High Sierra, aka macOS 10.13, allows users to gain admin rights, or log in as root, without a password. The security bug can be triggered via the authentication dialog box in Apple's operating system, which prompts you for an administrator's username and password when you need to do stuff …
COMMENTS
-
-
-
-
Thursday 30th November 2017 08:58 GMT bombastic bob
"How do you create a really secure password?"
Having forked FBSD's userland, it should be possible to create a random root password with command line tools (like 'pw') assuming those tools exists on a mac...
then you can just do the 'sudo su' trick when you want to do things as 'root' for a while...
-
-
-
Wednesday 29th November 2017 19:16 GMT Hans 1
Big Christmas bonus for the person who found the photograph to accompany this article :-)
Indeed, have an upvote. (I was 100th)
As for the blunder, this is Windows-like security.
Cupertino, stop hiring devs from Redmond, they know jack-shit about coding, have never heard of tests, let alone unit tests .... crikey, this vuln is EPIC.
How Apple get away with this, I dunno !
-
-
-
-
Tuesday 28th November 2017 20:57 GMT Anonymous Coward
How worse than Single User Mode?
I'm no fanboi, but usually physical access is enough to set the root password on *nix. Root passwords get forgotten like other passwords, after all.
Is it exploitable over a remote desktop connection? That would be worse.
It does raise serious questions about basic quality control, nevertheless.
-
-
Tuesday 28th November 2017 23:00 GMT Doctor Syntax
Re: How worse than Single User Mode?
"That's why a lot of distros prefer the "sudo" approach. You never actually log in as root, you just temporarily give the account root permissions...just long enough to run that one command, then you go back to a standard user."
I'm not an Apple user but from the account it seems as if this is how macOS has been supposed to work. It hasn't turned out well here.
I'm old fashioned enough never to have been a fan of sudo. It's always struck me as being an additional attack surface. I suppose it's more convenient than having multiple admin IDs with access to restricted subsets of root functionality such as bin to own system S/W & lpadmin to administer printers & the like but convenience and security don't often mix too well.
-
Thursday 30th November 2017 09:12 GMT bombastic bob
Re: How worse than Single User Mode?
"I'm old fashioned enough never to have been a fan of sudo"
well, if you configure sudo the way a BOFH would, you can lock out anything that's truly "dangerous" and require actually logging in as root for such things.
but most distros that have sudo simply allow any authenticated user to enter his own password to do "whatever he wants" with root credentials. It's convenient, yeah.
-
-
-
Tuesday 28th November 2017 21:07 GMT John H Woods
Re: How worse than Single User Mode?
Physical access to the system is different from "terminal" access. Try getting root access on a well-configured Linux system using just the keyboard and the mouse. If you've got physical access to the box, however, you have everything except the content of encrypted drives.
Although presumably one could splice a wired KB or Mouse to connect a USB storage device and boot from that?
-
Tuesday 28th November 2017 22:53 GMT Wensleydale Cheese
Re: How worse than Single User Mode?
"Is it exploitable over a remote desktop connection? That would be worse."
Yes.
I am running a headless Mac mini here, connected via Screen Sharing using an unprivileged username/password, and logged into a non-privileged account.
I didn't test the main login screen, but the exploit using Preferences > Users and Groups > Unlock worked as described in the article.
-
Tuesday 28th November 2017 23:43 GMT Wensleydale Cheese
Re: How worse than Single User Mode?
"I am running a headless Mac mini here, connected via Screen Sharing using an unprivileged username/password, and logged into a non-privileged account."
Having said the above, when you enable Remore Desktop access, you can restrict the functions available to the remote user. This is done on the target computer via System Preferences > Sharing > Remote Management > Options
-
-
Wednesday 29th November 2017 07:17 GMT bazza
Re: How worse than Single User Mode?
Is it exploitable over a remote desktop connection? That would be worse.
According to the update to the article it can be done on the command line too. So not vulnerable to a remote attack unless the perpetrator can get something run on the computer first (malicious but otherwise innocuous app, etc). Fishing attack might open up the doors for that.
I have to say that between Apple and Intel we're seeing some stinking cock ups in recent times. It's almost funny. All we need now is for Windows or Linux to join in and we may as well throw every single computer in the planet into the bin. Apart from the ones running Solaris.
-
Thursday 30th November 2017 09:07 GMT bombastic bob
Re: How worse than Single User Mode?
"but usually physical access is enough to set the root password on *nix."
not entirely true. On FreeBSD, at least, it is possible to require the root password for single-user mode by specifying that the console is 'insecure'. And, Shirley, you COULD also boot a "live CD" (assuming that hasn't been locked out) or "live USB" image, and then mount the hard drive's root partition and do a password reset THAT way (jumping through necessary hoops to do so via the command line) but you can do this in Windows as well.
Or, if you're really desperate, remove the hard drive and plug it into a different computer that has the correct utilities on it for a password reset.
(I'd much rather make miscreants go through that last step)
-
-
Tuesday 28th November 2017 21:50 GMT Daniel B.
OSX user here, and it's a vulnerability. It's probably somewhat mitigated in the sense that setting a password for root plugs the hole, but it's still an embarassment. Not sure if it's remotely exploitable, which would be bad. If it allows for su - without a password, it's probably bad, but it would still require someone to log in with a valid username/password before exploiting it.
If someone already has physical access to the system, there are larger issues at hand.
-
-
Tuesday 28th November 2017 22:35 GMT handleoclast
Linux root p/w
@kain preacher
Would you have root in linux with no password ?
Every Linux distro I've installed has asked you to set a root p/w. Never checked if you can leave it blank during install. Even if you can't leave it blank at that stage, it's possible to set a null p/w later. Either way, if you end up with a null p/w for root, it's because you deliberately chose to have it that way. You can't have a null root p/w by accident, or simply by doing nothing as you install the system.
And no, I wouldn't set a null root p/w deliberately. That would be crazy. I have a somewhat warped mind but I cannot conceive of any circumstance, no matter how bizarre, in which I would legitimately (no criminal intent) want a null root p/w (feel free to prove your mind is more warped than mine by coming up with one).
I remember the time DEC persuaded me that remote diagnostics were a great idea and that I should have one of those new-fangled modem dooberries. They said I could ensure it would only pick up when I was around to allow them in (which was true). We gave it a try. They told me they couldn't get in with FIELD/SERVICE (those standard superuser accounts had their passwords changed as the very first thing I did on that box) and would I mind changing it back. I gave them a hell of a bollocking over that one. Got a free curry out of it by way of an apology. If they'd suggested I leave the p/w blank on the FIELD account I'd have nuked them from orbit. Null password for superuser accounts? No fucking way.
-
-
-
Wednesday 29th November 2017 14:08 GMT handleoclast
Re: Linux root p/w
Not true, I'm a Linux sysadmin and none of the Ubuntu variants I've installed over the past 10 years have asked. You have to do this manually after install..
From what I've read in other responses, root logins are disabled. So you still have to consciously choose to have a passwordless root login.
-
-
This post has been deleted by its author
-
Wednesday 29th November 2017 12:57 GMT arctic_haze
Re: Linux root p/w
I cannot conceive of any circumstance, no matter how bizarre, in which I would legitimately (no criminal intent) want a null root p/w (feel free to prove your mind is more warped than mine by coming up with one).
The protagonist of the Martian movie could have had a null root password in his abandoned Martian base, at least until he regained some semblance of communication with the Earth.
-
Tuesday 28th November 2017 23:06 GMT Doctor Syntax
"Would you have root in linux with no password ?"
Ubuntu & derivatives. No password but root logins disabled. You're supposed to use sudo and re-enter your own password so if you're in sudoers and someone gets your password they've got root. Wonderful. I don't often use Ubuntu these days.
-
Tuesday 28th November 2017 23:23 GMT chuckufarley
"Ubuntu & derivatives. No password but root logins disabled. You're supposed to use sudo and re-enter your own password so if you're in sudoers and someone gets your password they've got root. Wonderful. I don't often use Ubuntu these days."
Is it that it has no password or that the password hash is set to an invalid value? It could be the former but I thought it was the latter.
-
Wednesday 29th November 2017 11:39 GMT Charles 9
"Ubuntu & derivatives. No password but root logins disabled. You're supposed to use sudo and re-enter your own password so if you're in sudoers and someone gets your password they've got root. Wonderful. I don't often use Ubuntu these days."
Wouldn't they have enough access under similar systems since the group that would include sudo'ers here would likely be the ones with significant group access otherwise? At least with sudo it's like UAC, the high-level access isn't on all the time.
PS. sudo doesn't have to be root. You can sudo as other users, too, with their own access restrictions. Again, this creates a temporary privilege escalation, but one you can control better.
PSS. The sudoers file is also how users can be restricted using sudo, even regarding the root privilege. So instead of it being an all-or-nothing thing like su, it can be turned into a tuned ACL.
-
-
-
Tuesday 28th November 2017 22:48 GMT Anonymous Coward
They are busy setting Root passwords...
BTW a co-worker has just informed me this works on ARD (Apple Remote Desktop) as well, so this is potentially a remote root exploit for anyone with ARD turned on. Might be an issue for other network services, though the SSH default config will probably block that.
-
-
This post has been deleted by its author
-
Wednesday 29th November 2017 18:42 GMT Hans 1
Re: They are busy setting Root passwords...
Ford Pinto> Major PR disaster. Ford is still in business.
The "Ford Pinto" was no less vulnerable to rear impacts causing the fuel tank to explode than other cars in its category ... this was a planted PR attack on Ford ... after the incident and recalls, Ford Pintos were the least vulnerable to rear impacts causing the fuel tank to explode its category, but the damage was already done,
Note, I hate Ford ...
-
-
Wednesday 29th November 2017 14:21 GMT TVU
"Hang on, where are all the fanbois telling us this isn't really a vulnerability?"
It most definitely is a significant vulnerability but at least with the Unices, really critical bugs tend to get sorted out pretty darn quickly and they don't have to be outed by Google to remind them to get their act together.
-
-
Tuesday 28th November 2017 20:27 GMT Dwarf
I'm puzzled
Its amazing how many of these root privilege bypass "bugs" tend to exist in so many OS's - I can't imagine it due to poor coding, its almost as if they were put there deliberately, but who would want to do such a thing ??
I also wonder if they get fixed, or just hidden a bit deeper ?
-
Tuesday 28th November 2017 20:35 GMT Anonymous Coward
This is a deliberate feature and it's because Apple cares.
When you need to login as root, it's normally to fix something fundamental. Chances are you need to do it quickly, and are in a bit of a panic, a bit stressed and so on, so having to also remember a password just seems a step too far. So well done Apple, reducing stress with intelligent design!
-
-
Wednesday 29th November 2017 08:41 GMT Anonymous Coward
Re: This is a deliberate feature and it's because Apple cares.
"When things are bad enough you have to use root, it is time to slow down"
Would you mind talking to our security team please. They've set our boxes so that only root can see anything other than home directories. The result - everyone does sudo su as soon as they log in.
-
-
-
Tuesday 28th November 2017 21:58 GMT FrankAlphaXII
Re: This is a deliberate feature and it's because Apple cares.
That's likely because FreeBSD is designed so that you very rarely need root. I've been running FreeBSD and TrueOS for about three years now and I can count the times I've used root on one hand.
Thing is, last time I had to anything in the terminal for OS X and needed root, it took me awhile to figure out how to enable the root account as Apple has it disabled by default (or at least did a couple of releases ago around Mavericks) which is usually smart, most users have no need for it. It shouldn't be that easy to escalate privileges in any software. This is the kind of trick that I would have tried back in High School just to see if it'd work, trying root with a blank password, then with "password", and then "administrator" just for shits and grins.
Maybe Apple should hire some decent QA people and give external power users a reason to actually test for them. They won't because they're deluded into thinking that they're perfect, and a lot of that is because of Jobs' blamelessness ("You're holding it wrong"), Ive's very clear desire for form over function, and Cook's issue with keeping quality high so that they can justify their outrageous prices. But it'd be a really good idea.
Thing is, even despite this, I still want a Mac mini whenever they update the hardware. It'd be nice to have a UNIX that I don't have to constantly fuck with to use every now and then.
-
Tuesday 28th November 2017 23:41 GMT jake
Re: This is a deliberate feature and it's because Apple cares.
"It'd be nice to have a UNIX that I don't have to constantly fuck with to use every now and then."
Frank, have you tried Slackware-stable as a day-to-day box? I moved my Wife from WinXP about ten years ago. Granted, it took a little hand-holding at first as she learned where the stuff she wanted to do was located ... but it's three or four laptops later now, and I haven't had to do anything other than new installs and routine updates for her in years. Try it, you might like it.
Hint: If you're new to Slackware, do a complete install. It's not like hard drive space is precious anymore. You can strip out the bits you don't need/want later if the inefficiency annoys you.
Caveat: Slack's KDE-centric, but if you hate KDE it ships with alternatives. And obviously, if you are somewhat computer literate you can easily install any of the desktop environments.
Note: My personal day-to-day box uses the same exact box-stock Slack setup that my wife uses. I never have to fuck with it, it just works. That doesn't mean I don't have a couple of dev boxen with other crap grafted onto them, and a couple of Slackware-current boxes just to keep an eye on development. Hardware's cheap.
-
-
-
-
Wednesday 29th November 2017 06:29 GMT HMcG
Re: Dev was a twat
You know, normally I would agree with you, if this was a technical exploit, or in any way difficult to find or exploit. But in this case, it's such a stupid error, that it is highly likely the exploit is already know about in some black-hat circles.
There is also no guarantee that Apple would have come clean immeadiatly with this exploit, as it is going to severely undermine their reputation. This is not a "security is hard" issue, this is corporate negligence, and Apples lawyers would be loath to admit to it until they were forced to. This is 'class-action' bad.
This means there would be a risk of a severe exploit window between the knowledge being widely known in cracking circles, and the public being warned about.
-
-
Tuesday 28th November 2017 22:08 GMT anthonyhegedus
It's harmless
It's just a small glitch in MacOS. It really can't be exploited by anyone much. A true Mac user would never accidentally type 'root' as a user name. And look at all the flaws in windows. One tiny flaw in Apple is nothing by comparison. I'd sooner use my Mac any day than Windows.
Seriously though, I *DO* use a mac, I do prefer using it, but for fucks sake Apple! This is TERRIBLE!!! Very poor show....
-
Tuesday 28th November 2017 22:19 GMT Richard Lloyd
I always set a root password on sudo-based systems
First thing I do on sudo-based systems is "sudo passwd root". Quite a few such systems would prompt for root's password for filing system repair when booting after an unclean shutdown - you're in trouble if you haven't set one!
I often run several root commands in a row, so I'll often just use "su -" for that (only doable if you set a root password), rather than "sudo bash".
-
Wednesday 29th November 2017 03:26 GMT Lomax
Re: I always set a root password on sudo-based systems
All 'buntu flavours lock the root account by default, and setting a password will unlock it - I would advise against this. Personally, I prefer a (memorised) strong password on my user account which can be used to gain su privileges, while leaving the root account locked. Just one less thing to keep track of. For passwords, I find it is easier to memorise a phrase of a few words rather than a (shorter) random string - ideally with a few numbers & special characters thrown in for good measure. Faster to type too!
A list of some of the pros of using sudo:
https://help.ubuntu.com/community/RootSudo#Benefits_of_using_sudo
A comparison of different ways of opening a root shell:
https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
A discussion about character vs. phrase based passwords:
https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/
When it comes to opening a root shell, I prefer to use "sudo -i", since it keeps confusion to a minimum. This will load root's full environment and prevents accidental overwriting of user files with files owned by root, etc. It also decorates your prompt with a # instead of a $, which serves as a visual reminder that you need to think a little more carefully about what you do next...
"su" on the other hand, is not intended specifically for gaining root privileges; it actually stands for "substitute user" and allows you to impersonate *any* user on the system. By including the " - " it will also load that user's environment. This is often handy when you want to test an application which runs under an account for which login is disabled (such as a daemon), and see if/where it runs into permission issues etc (i.e. "su - accountname"). An ommitted account name will default to "root", which is probably why it's often used in the way you suggest, though while the resulting shell is basically the same as what you would get with "sudo -i" I would personally not use "su -" to become root. Just feels wrong.
See also "man sudo" and "man su".
</lecture>
-
-
Tuesday 28th November 2017 22:20 GMT Grease Monkey
For the apologists.
Other OSs do it too. So what? Apple and their fans pride themselves on being secure by default. A blank root password is secure by default?
It requires physical access so it's not a vulnerability. It doesn't matter how often I hear this one it makes me laugh. Somebody with physical access can access all your data and that's not a vulnerability? What exactly do you consider a vulnerability then?
You can fix it by setting a root password. You shouldn't have to fix it, how the hell does a "secure” OS manage to install without setting a root password?
It's still more secure than Windows. And? It's not just Apple and Microsoft you know. Neither of the two OS's I'm using these days would allow you to install without setting a password on the root account.
This simple little fuck up shows that Apple's QC can be truly appalling and their attitude to security is not all its cracked up to be.
Never mind fanbois, you still have your badge.
-
-
Wednesday 29th November 2017 10:50 GMT Anonymous Coward
In fairness, there don't seem ot be too many apologists for once. Presumably, this is so stupid that even Apple fans cannot think up a way to minimize it.
We're also not all "fanbois" or "apologists", but simply people who want desktops to work to an acceptable standard of safety and security, which until now happened to be easiest to achieve by using MacOS based systems. Frankly, I am both appalled and incensed by this and I feel rather let down by Apple that this ever made it past QC.
I expect more than just the usual silence from Apple on this. It is quite simply unacceptable - there ARE no excuses for this.
-
-
Tuesday 28th November 2017 23:19 GMT Doctor Syntax
"It requires physical access so it's not a vulnerability."
To be fair it's not necessarily the worst problem you could have if someone has physical access. But if it's also available remotely as commentards have reported it goes to the top of the class.
Moral - always set a root password - and remember it.
-
This post has been deleted by its author
-
-
Wednesday 29th November 2017 07:32 GMT bazza
It requires physical access so it's not a vulnerability. It doesn't matter how often I hear this one it makes me laugh. Somebody with physical access can access all your data and that's not a vulnerability? What exactly do you consider a vulnerability then?
The article has been updated; the trick works from the command line too. So any application that an attacker can get run on the computer can get itself root privileges. So whilst there is no remote vulnerability, it's only one successful social engineering attack away from that.
Pretty dangerous I think, and that alone justifies the early and global dissemination of the news. Leaving this one to fester in private would have left all users everywhere very vulnerable to malicious software.
-
Wednesday 29th November 2017 08:22 GMT Anonymous Coward
There's "physical access" and "physical access"
Sure, if you are alone in a room for a long time with all the needed tools, you can have full physical access, you can disassemble a machine and re-assemble it later, just, if that is one of the glue-assembled ones you need some specific tools and time to take it apart, and put it together again.
But a bug that needs just a few keystrokes to be exploited, doesn't require much "physical access", you just need a few minutes to type on the keyboard - a very different kind of "physical access".
And Macs are not usually machines buried deep in some remote server room...
-
-
Wednesday 29th November 2017 09:36 GMT NightFox
Macs are consumer devices. The vast majority of users/owners aren't going to even know what root access is, and nor should they need to.
"IT people" who look down on users who don't have a professional level of IT knowledge and roll their eyes at them whenever this type of things happen just reinforce the Moss stereotype. A total failure to understand and therefore accommodate the user's average expected level (or lack) of knowledge is also a reason so many issues occur in the first place.
-
-
-
Wednesday 29th November 2017 07:38 GMT Anonymous Coward
Re: AFK
You're not one of those who'd go into Dixons and type the magic sequence of peeks and pokes into an Amstrad CPC464 (or whichever one it was, someone out there will know) that would render it a smoking ruin in a few minutes time?
(It was possible to get two peripherals driving the data bus at the same time - a logic design error. Get one of them trying to write all 0's, and the other all 1's, and you'd made a short circuit from software. Some chip would then get hot enough to let the magic smoke out...).
-
-
Wednesday 29th November 2017 07:31 GMT Gordon Pryra
Possibly one of the worst oversights to date on any flavor of any OS
Considering the cost of a machine that you need to pay in order to have one that runs High Sierra (MACs are stupidly expensive for the specification) You would think that the manufacturer could engage in some basic testing of security.
With the numbers of people who own these items, there is no way that this wasn't found on the day of release by someone, and WILL have been used in a malicious manner.
There is a (good) argument that this OS is not fit for purpose and refunds should be given.
Luckely most organisations with MACs will also be using active directory or novell for their network infrastructure, and so a user having local admin privileges isn't that big an issue. That said, MAC users tend not to be that technical, claiming artistry over technology, and store all sorts of important stuff locally......
-
Wednesday 29th November 2017 07:46 GMT Oflife
Works for me first time on 10.13.1!
If you do not click in the password field, you cannot get in, at least I could not even after 3 attempts. But clicking in the Password field and leaving it blank let's me in right away. Oh Apple, really! TC is too focused on matters of the bedroom than product.
-
Wednesday 29th November 2017 08:23 GMT Anonymous Coward
Absolutely not acceptable
Honestly, there are no excuses for this. WTF, Apple? WT freaking F?
Microsoft has at least the decency to hide its problems and make it a bit of a challenge. I have never seen a decent company so dramatically drop the ball in quite some time. Even Microsoft Vista wasn't that exposed from a security angle.
Whoever was responsable for this cockup, firing is too good for them. At a minimum, this ought to involve tar & feathers.
-
-
Wednesday 29th November 2017 10:38 GMT Anonymous Coward
Re: Only if....
This is the thing. There is a root account. Active. With, apparently, no password. Why on earth there hasn't been a randomised one set (as you have sudo access anyway) is not clear to me and I am disappointed that someone at Apple made that mistake. This is NOT trivial, and I expect fairly harsh words and probably a pink slip event as a consequence for one or more people.
-
-
This post has been deleted by its author
-
Wednesday 29th November 2017 10:40 GMT windows 92
All aboard the fail bus
I have to agree with some folk here, since Johnnie Ives took over Mac OS it has got steadily worse (I still don't know how he got involved with the Apple with the fail that was the PowerBook G4, maybe Steve liked it's flimsy disposable build quality)....
iOS has become absolute rubbish under his design leadership, used to love my iPhone, now can't wait to dump it for an Android phone (I don't have to jail break Android to get basic UI features that should be on all UI designers lips...)
And this 0day root access flaw is just another example of how Apple are not focused correctly...
-
-
Wednesday 29th November 2017 13:39 GMT the-it-slayer
Re: Simple workaround
Better than that (not everyone wants Wobbly Windows); take a pro's advice (I'm not one, but took it anyway); run the previous or 2nd previous major OS version for stability if it's supported and you don't need the latest and greatest features.
I'm sure El Capitan and Sierra are supported on most Macs that are still in active Apple Support lifecycle.
-
-
Wednesday 29th November 2017 11:30 GMT firebits
Not all installs of High Sierra are affected
I have checked a dozen mac's with High Sierra version 10.13.1 and not all installs appear to be affected, only 1 out of the 12 has a blank root password. I have reset the root password on all devices anyway however, I am struggling to see why only 1 of the 12 has this condition? Any thoughts other than someone else reset the password?
-
Wednesday 29th November 2017 17:51 GMT Peter X
Re: Not all installs of High Sierra are affected
...only 1 out of the 12 has a blank root password. I have reset the root password on all devices anyway however, I am struggling to see why only 1 of the 12 has this condition? Any thoughts other than someone else reset the password?
Total guess, but perhaps if you've upgraded the OS then you'd have a root password set previously, whereas a fresh install fails because of a bug in the new installer?
At risk of #whataboutism, there was an issue with Ubuntu way way way back, where the installer stored the root password in a temporary file and then failed to delete it after install. Leaving it world-readable. That, from a technical standpoint, was similarly embarrassing!
To be fair, it was fixed quickly. And Canonical's entire annual development budget was probably a pittance compared with Apple. But embarrassing bugs are embarrassing. And for some reason I always remember those ones.
-
-
Wednesday 29th November 2017 14:24 GMT John Savard
Bug?
"If you have configured a root password, the above blank password trick will not work."
So if root doesn't have a password, you can log on to root without a password. Isn't that how it's supposed to work?
That doesn't mean there isn't a bug, though - the bug is instead in the procedure for installing the operating system on the computer, which apparently fails to notify the user that having a password on root is recommended.
Oh, wait, Macintosh computers come with the operating system preinstalled, don't they? But isn't there still some sort of personalization program you go through when you use the computer the first time? That's what should be fixed; being allowed to not have a root password may be a feature that is too risky to leave in, but it isn't really a bug in itself.
-
Wednesday 29th November 2017 15:33 GMT MacGuru42
and this is why...
we advise people NOT to update to the latest and greatest version of macOS until all these problems have been fixed.. and yes, that may mean we keep our customers on 10.12.6 for up to 6 months post release, but this and all the other issue with 10.13 are making look a lot like 10.7 (shudder).
Better to have a working, stable, supportable release for a production machine, than jumping on the bleeding edge..
-
Wednesday 29th November 2017 16:08 GMT Jonathan 27
Yet more proof that Apple doesn't care even slightly about security. And they can get away with it. Why? because of low market share and lack of businesses using Mac OS. Seriously, if this was a bug in Windows it would be on the front-page of every news outlet in the country.
Overall though, this is a symptom of Apple's attitude about Mac OS. They clearly don't care anymore and it leaves me wondering if they're going to discontinue Macs 5-10 years down the line. They keep reducing the product line and updates are coming slower and slower. X-Serve, dead. Mac Pro, 4 years old. Mac Mini 3 years old. iMac 3 years (although a new one is coming 3 years a a huge wait). All tower Macs are dead, and even the laptops miss CPU updates.
-
-
-
Thursday 30th November 2017 00:37 GMT coconuthead
Re: Patch now available
Yes, well, it was fast but according to reports it also broke SMB sharing between High Sierra machines.
The workaround is (drum roll) to use sudo at the command line to run some obscure utility in libexec.
It seems to me not so much a lack of testing—probably testers would never have thought of that anyway—but someone monkeying around in the code without having a deep understanding of how it works.
High Sierra was supposed to be a maintenance/performance release, with a new filesystem and window manager. It's hard to see how any of the touted changes could have required messing around with the login logic. Someone needs to put an iron fist down and limit the changes in each release to what's necessary, and in particular to forbid random reimplementations of modules just because they're not in Swift or not yet common to iOS.
-
-
-
Wednesday 29th November 2017 19:15 GMT Anonymous Coward
Can't believe they were dumb enough to leave the root password blank
Many years ago when I was a spotty teenager, I hacked into the local university's PR1ME computers because of a similar stupidity. They had SYSTEM (i.e. root) accounts on some of them without a password. Since they didn't have a project (i.e. resources for CPU time, storage, etc.) assigned if you tried logging in as SYSTEM it would immediately log you out - the equivalent of setting the shell to /bin/false on Unix.
However, when I was exploring I found out about a command called 'arid' - add remote ID - which would enable you to visit the filesystem of another network connected PR1ME from the one you logged into, and you'd have the rights of the remote ID you'd given in 'arid' instead of your own rights. So basically I was SYSTEM on the ones that had a blank password. I was able to use that permission to run the user creation program and create myself a system level account and used the project number of one of their sysadmins who had nearly unlimited resources. That enabled me to login and have ability to do anything I wanted (which really wasn't much, I wasn't causing any damage)
Took them a while to catch me since I was dialing in and they didn't have caller ID on their PBX. I think at some point I was lazy and logged in to my created account on the same phone call I had logged in to my dad's account instead of disconnecting and redialing like I always did. Their main interest when they caught me was finding out how I did it, and I have to admit I enjoyed seeing the hand hitting forehead moment for the head guy when I told him it was because of there was no password set on some of the system accounts, and he said "but you can't login to them" and I told him about 'arid' :)
-
Wednesday 29th November 2017 19:28 GMT richard0x4a
Apple's guidance not quite correct - do not disable the root user!
Apple's guidance isn't quite correct. They say "you should disable the root user after completing your task". However, if you set a root password, then disable the root user, it resets the password back to blank and reintroduces the vulnerability.
You need to set a root password, then make sure you leave the root account enabled. Only then do you defeat the vulnerability.