Apple has egg on its face with High Sierra blunder!

[Nusa]

Apple released it's latest MacOS that installs with a blank root password. That's breaking rule number one in UNIX security!

The real surprise is that it took so long (two months) for someone to notice and make public. Now it's a nightmare for Apple, who is racing to get a patch out. Luckily, in most cases, it requires physical access to the machine to exploit, but still...

The quick fix, if you happen to be affected, is simply to set the password on root yourself.

[glarsson]

Apple distributed a patch for this yesterday.

[amyk]

The real surprise is that it took so long (two months) for someone to notice and make public.

A lot more people probably noticed, but just kept it secret.

[cdev]

I'm very surprised that the underlying BSD OS even allows a null length password.

[timb]

Well, by default macOS completely disables the root account for GUI and SSH logins, you can’t even su into the root account without changing a Plist preference. So it’s not really a major attack vector. The only way you could actually log in as root on an unmodified system would be by rebooting into Single User Mode. That said, if you’ve got FileVault enabled (and you really should), you’d still need a valid username and password to decrypt the volume first, so it’s not like you could actually do anything in that case.

[borjam]

Unix systems allow accounts with blank passwords.

In this case the bug was a bit more insidious. There are several explanations around, but it's easier to understand it with an old example.

Back in 1991 I was examining a software package called Atlantix Axcess. It was a Lan Manager server for SCO Unix. Its purpose, to serve disk storage and printers to MSDOS and Windows PCs.

Turns out it had a similar security flaw, caused by poor error handling in the authentication process. (Note: I am simplifying the explanation)

Passwords in Unix are kept encrypted. A one way encryption algorithm is used, and it generally produces a fixed length output. A trick is used to keep an account locked. If the password field contains an invalid password (an asterisk is often used) absolutely no encrypted password will match. That means that nobody will be able to login.

But, wait. I said that the encrypted password field contains an invalid entry, "*". A problem in the exception handling of the login process in Atlantix Axcess actually meant that the authentication routine granted access.

It didn't grant access to root directly, but it granted access to any other locked accounts, such as "bin" (owner of the system files), "tcb" (owner of the authentication and permissions database), etc. So it was trivial to exploit.

Another amusing security flaw was found many years ago in an operating system called TENEX. It's described on Andrew S. Tanenbaum's book "Operating Systems: Design and Implementation", and in this case an optimization was responsible for a reduction on brute force attempts from 26^n to 26*n.

Writing secure software is much harder than it seems.

[Neilm]

Apparently, the patch that fixed this broke file sharing. Not sure if or  is more appropriate

[rsjsouza]

Apparently, the patch that fixed this broke file sharing. Not sure if or  is more appropriate

I agree. Apparently a fix is in place.

[Richard Crowley]

A lot more people probably noticed, but just kept it secret.

They have to maintain the notion that Mac is invulnerable.

[Monkeh]

A lot more people probably noticed, but just kept it secret.

They have to maintain the notion that Mac is invulnerable.

Or, y'know, responsible disclosure.

[Howardlong]

Well, by default macOS completely disables the root account for GUI and SSH logins, you can’t even su into the root account without changing a Plist preference. So it’s not really a major attack vector. The only way you could actually log in as root on an unmodified system would be by rebooting into Single User Mode. That said, if you’ve got FileVault enabled (and you really should), you’d still need a valid username and password to decrypt the volume first, so it’s not like you could actually do anything in that case.

I tried it yesterday. I’ve never used root on this particular machine. First, I updated from Sierra (where I couldn’t log in as root) to High Sierra. Fast forward an hour while it undated. I cold booted it, and at login, I selected “Other...”, keyed in “root” and hit enter twice. It created a nice new desktop, with everything unlocked.

(I promptly then set a root password in case anyone’s got any funny ideas).

[timb]

Well, by default macOS completely disables the root account for GUI and SSH logins, you can’t even su into the root account without changing a Plist preference. So it’s not really a major attack vector. The only way you could actually log in as root on an unmodified system would be by rebooting into Single User Mode. That said, if you’ve got FileVault enabled (and you really should), you’d still need a valid username and password to decrypt the volume first, so it’s not like you could actually do anything in that case.

I tried it yesterday. I’ve never used root on this particular machine. First, I updated from Sierra (where I couldn’t log in as root) to High Sierra. Fast forward an hour while it undated. I cold booted it, and at login, I selected “Other...”, keyed in “root” and hit enter twice. It created a nice new desktop, with everything unlocked.

(I promptly then set a root password in case anyone’s got any funny ideas).

Okay, then the bug is not that “Apple set a blank root password” like a lot of people are stating. The bug is Apple forgot to disable the root account! Because the account is supposed to be disabled, there is never a password set until the user enabled it. (Normal behavior is that when you enable the account via Keychain or the terminal, you’re prompted to set a password.)

Obviously someone goofed. Still, I imagine the risk was minimal. Root login would have been unavailable over SSH.

Do you have FileVault enabled on your system? You shouldn’t have been able to login with the blank password root account if it was. (FileVault would require a valid user account associated with the key.)

[borjam]

Okay, then the bug is not that “Apple set a blank root password” like a lot of people are stating. The bug is Apple forgot to disable the root account!

No. Apple didn't forget to disable the root account. A bug in the authentication code led it to authorize access to a locked out account. Look at the example from 1991 I mentioned. It's pretty similar.

[Howardlong]

Well, by default macOS completely disables the root account for GUI and SSH logins, you can’t even su into the root account without changing a Plist preference. So it’s not really a major attack vector. The only way you could actually log in as root on an unmodified system would be by rebooting into Single User Mode. That said, if you’ve got FileVault enabled (and you really should), you’d still need a valid username and password to decrypt the volume first, so it’s not like you could actually do anything in that case.

I tried it yesterday. I’ve never used root on this particular machine. First, I updated from Sierra (where I couldn’t log in as root) to High Sierra. Fast forward an hour while it undated. I cold booted it, and at login, I selected “Other...”, keyed in “root” and hit enter twice. It created a nice new desktop, with everything unlocked.

(I promptly then set a root password in case anyone’s got any funny ideas).

Okay, then the bug is not that “Apple set a blank root password” like a lot of people are stating. The bug is Apple forgot to disable the root account! Because the account is supposed to be disabled, there is never a password set until the user enabled it. (Normal behavior is that when you enable the account via Keychain or the terminal, you’re prompted to set a password.)

Obviously someone goofed. Still, I imagine the risk was minimal. Root login would have been unavailable over SSH.

Do you have FileVault enabled on your system? You shouldn’t have been able to login with the blank password root account if it was. (FileVault would require a valid user account associated with the key.)

Disabling the root account in this case doesn't resolve the problem, as the "exploit" re-enables it.

I don't use FileVault, in fact I rarely use OSX at all for work, all but one of the Macs I have run in Windows natively, I leave the OSX partition on there in case of BIOS updates etc, and very occasionally I boot to OSX for IOS and OSX development purposes when specific needs dictate. The one Mac that I have that only runs OSX is for music arrangement as part of my DAW setup, i.e., not for the day job!

[bd139]

This is a dumb cock up but relatively inert either way:

1. It's not active or open by default.
2. You have to authenticate with the machine to enable it.
3. You have to have physical control of the machine to enable it.
4. SSH to root account is forbidden by default anyway so remote auth isn't possible even with a password and you have to turn SSH on.

The only attack vector appears to be running unsigned software on the machine which you have to click through a whole bunch of warnings and hoops to do, or have an Apple Remote Desktop session up with the attacker who actually does it in front of you. Or you're dumb enough to just do it via forum instructions. Game over anyway if someone has physical access to any system.

And it has been patched now.

An let us not forget pre-Windows XP SP1, where you could log in as Administrator with a blank password because there was a bug in MSGINA and LSASS.

[borjam]

This is a dumb cock up but relatively inert either way:

1. It's not active or open by default.

In this case, the problem is more serious. In Unix systems you lock an account by assigning it an invalid encrypted password. In this case, that invalid encrypted password made some poor exception handling to authorize access.

3. You have to have physical control of the machine to enable it.

Which still leaves you vulnerable in all those situations in which, for whatever reason, you leave a machine unattended. I don't carry my laptop to the loo when I am at the office.

4. SSH to root account is forbidden by default anyway so remote auth isn't possible even with a password and you have to turn SSH on.

It did not affect *only* root, but potentially any account locked by the traditional method of the invalid password. Read my simple description above
of a similar cock-up in a network server in 1991. I could authenticate successfully as "bin", "tcb", "daemon", etc.

An let us not forget pre-Windows XP SP1, where you could log in as Administrator with a blank password because there was a bug in MSGINA and LSASS.

Probably a problem belonging to the same class. This kind of problems can be caused by error or exception handling problems, or even race conditions .

There has been a comparable problem in the systemd service in Linux. https://github.com/systemd/systemd/issues/6237

In this case, a user name beginning with a number in a configuration file was interpreted as number. The file accepts both user names and numerical uids. This particular problem deals with how interpret a field that can be in any of two different formats.

How do you deal with that? You can try a number conversion first, with a fallback to a name look up. But some number conversions may happily return the "0" in the user "0day" assuming that the rest was garbage you can discard.

You can do it in the opposite order in order to be safe from lax number conversions. However, in case the "0day" user is deleted for whatever reason, its processes will be executed with uid=0, ie, root.

The discussion itself is interesting, because some claim that it shouldn't happen anyway, so they don't consider it a bug in the first place.

[bd139]

In this case, the problem is more serious. In Unix systems you lock an account by assigning it an invalid encrypted password. In this case, that invalid encrypted password made some poor exception handling to authorize access.

Actually that's not quite correct. It varies quite a bit between implementations. If you give it an invalid password, this just disables password authentication. You can still auth other PAM/directory providers (ssh/kerberos etc) if your platform supports PAM/directory services. An account is only properly disabled if it is expired.

The root account is still a valid, active account. It is not actually locked or disabled, just password auth is disabled. You can still sudo as it for example.

Which still leaves you vulnerable in all those situations in which, for whatever reason, you leave a machine unattended. I don't carry my laptop to the loo when I am at the office.

Lock it, filevault/bitlocker it. Security 101. Plan to lose it, not plan to avoid losing it.

There has been a comparable problem in the systemd service in Linux. https://github.com/systemd/systemd/issues/6237

Don't even talk to me about that turd . Many a jousting match I've had with systemd (and Poettering on a couple of occasions)

[Howardlong]

May I respectfully suggest Krebs? There seem to be a lot of assumptions being made on this thread.

https://krebsonsecurity.com/2017/11/macos-high-sierra-users-change-root-password-now/

[borjam]

Actually that's not quite correct. It varies quite a bit between implementations. If you give it an invalid password, this just disables password authentication. You can still auth other PAM/directory providers (ssh/kerberos etc) if your platform supports PAM/directory services. An account is only properly disabled if it is expired.

The root account is still a valid, active account. It is not actually locked or disabled, just password auth is disabled. You can still sudo as it for example.

Right. I entered the mindset of the 1980's when explaining this. There was no fancy account locking and different authentication methods were rarely used. So, disabled password authentication was equivalent to account locking ¡Sorry for the confusion!

Anyway I tried to point out how an apparently silly programming error or assumption can lead to a serious security problem such as this one.

Which still leaves you vulnerable in all those situations in which, for whatever reason, you leave a machine unattended. I don't carry my laptop to the loo when I am at the office.

Lock it, filevault/bitlocker it. Security 101. Plan to lose it, not plan to avoid losing it. Of course I lock the screen (when it works, Apple has a rather embarrassing history in this regard lately) and I indeed use FileVault.

But note that a laptop with the screen locked is not safe from other physical access attacks (such as USB/FireWire/Thunderbolt). The only
secure state in this case is powered off.

I remember the kerfufle when some people suddenly realized that Firewire offered a DMA facility.

There has been a comparable problem in the systemd service in Linux. https://github.com/systemd/systemd/issues/6237

Don't even talk to me about that turd . Many a jousting match I've had with systemd (and Poettering on a couple of occasions)

Anyway, the discussion is a really interesting peek into the predominant mindset in the Linux world. Which is not beautiful, by the way.

(I rather prefer to use FreeBSD for serious purposes)

[bd139]

Right. I entered the mindset of the 1980's when explaining this. There was no fancy account locking and different authentication methods were rarely used. So, disabled password authentication was equivalent to account locking ¡Sorry for the confusion!

Believe me I wish it was still like that. There was some determinism. I was a wrangler of SunOS 4 for a number of years. Went downhill after that.

Of course I lock the screen (when it works, Apple has a rather embarrassing history in this regard lately) and I indeed use FileVault.

But note that a laptop with the screen locked is not safe from other physical access attacks (such as USB/FireWire/Thunderbolt). The only
secure state in this case is powered off.

I remember the kerfufle when some people suddenly realized that Firewire offered a DMA facility.

Indeed again. It's quite disgusting how stupid some of the holes are.

If you expose the bus to any devices directly or otherwise you are always at risk. The ThinkPad series of machines have interesting security controls. You can turn off all the ports before the machine even comes up (including the ME service). Also GPO on windows has the ability to kill off USB ports at least. I haven't bothered securing mine if I'm honest.

Anyway, the discussion is a really interesting peek into the predominant mindset in the Linux world. Which is not beautiful, by the way.

Yes it's horrible and keeps me awake at night sometimes. Unfortunately it pays the bills pretty well.

I am also a FreeBSD user and have been for about 20 years now - my VPS and file server are running it. MacOS gets the desktop though because of convenience.

[timb]

But note that a laptop with the screen locked is not safe from other physical access attacks (such as USB/FireWire/Thunderbolt). The only
secure state in this case is powered off.

When you log out, FileVault re-encrypts the volume. Also, even if that weren’t the case, I can’t see how USB/FW/TB would be an attack vector. macOS doesn’t have auto-run functionality like Windows.

Even if you rebooted the Mac into Target Drive Mode (where it acts like an external hard drive to the system connected over FW/TB) and cloned the drive, it’s still encrypted.

So, what’s the attack vector?

[cdev]

This story (link below) has not gotten the media attention one would think it would get.

http://www.cs.vu.nl/~ast/intel/

But that doesn't mean its not important. 

WTF?

[timb]

All Apple PCs use Intel hardware. This story (link below) has not gotten the media attention one would think it would get. But that doesn't mean its not important.

http://www.cs.vu.nl/~ast/intel/

And the Intel Management Engine decrypts the drive how exactly?

[cdev]

All Apple PCs use Intel hardware. This story (link below) has not gotten the media attention one would think it would get. But that doesn't mean its not important.

http://www.cs.vu.nl/~ast/intel/

And the Intel Management Engine decrypts the drive how exactly?

There is a whole world of functionality on those boxes that the owner/user and his or her OS never even sees.

[Electro Detective]

Which versions/updates of High Sierra are vulnerable?  all of them from beta and GM initial release?

and which one has the apparent fix?  that will soon need a patch for the fix   

[timb]

All Apple PCs use Intel hardware. This story (link below) has not gotten the media attention one would think it would get. But that doesn't mean its not important.

http://www.cs.vu.nl/~ast/intel/

And the Intel Management Engine decrypts the drive how exactly?

The same way any user does but with three levels higher permissions.

Care to explain that further? FileVault isn’t like a BIOS password on a PC. Aside from the UEFI partition and a small amount of code to boot the system, the rest of the drive is stored in an encrypted disk image. A master key or valid username and password are required to un-encrypt and mount the volume. The IME would have neither. (And it wouldn’t know how to do it to begin with, since the encryption is all software based and designed by Apple, not Intel.)

[cdev]

All Apple PCs use Intel hardware. This story (link below) has not gotten the media attention one would think it would get. But that doesn't mean its not important.

http://www.cs.vu.nl/~ast/intel/

And the Intel Management Engine decrypts the drive how exactly?

The same way any user does but with three levels higher permissions.

Care to explain that further? FileVault isn’t like a BIOS password on a PC. Aside from the UEFI partition and a small amount of code to boot the system, the rest of the drive is stored in an encrypted disk image. A master key or valid username and password are required to un-encrypt and mount the volume. The IME would have neither. (And it wouldn’t know how to do it to begin with, since the encryption is all software based and designed by Apple, not Intel.)

(Also, I’m pretty sure access to the IME is disabled on Apple systems. I know ethernet/WiFi access isn’t turned on, which means no remote KVM access.)

[timb]

Right, UEFI and SMM can be exploited, but that’s nothing new and applies equally well to all PCs, not just Apple systems. (This problem has been around a lot longer than UEFI. Viruses that re-flash a PC’s BIOS have been around since at least 1999.)

My point was that FileVault closes an attack vector otherwise open on non-encrypted systems when locked.

[raptor1956]

The real surprise is that it took so long (two months) for someone to notice and make public.

A lot more people probably noticed, but just kept it secret.

Yes, what are the odds that the NSA and other signals intelligence outfits around the world were aware and said nothing?


Brina

[bd139]

High.

FireWire and lightning have DMA capabilities. I’m not sure how exploitable it is but you could read disk buffers which are not encrypted directly from RAM. When you suspend a Mac I.e. shut the lid it goes into light sleep not hibernate so if you open the lid then all disk buffers that have been read are vulnerable.

Also I don’t think macs use a HSM so the state of the machine is likely in that RAM somewhere, possibly enough info to get that FileVault key.

And then there’s the ME processor which can be activated and has better than ring 0 access.

You can’t win either way unless you control the entire hardware end to end which Apple do with iOS.

The whole situation sucks.