Apple has egg on its face with High Sierra blunder! - Page 1
Forum section: electronics / general

author: Nusa
author_rank: Super Contributor
timestamp: November 30, 2017, 03:59:39 am
content: 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.

author: glarsson
author_rank: Frequent Contributor
timestamp: November 30, 2017, 09:19:42 am
content: Apple distributed a patch for this yesterday.

author: amyk
author_rank: Super Contributor
timestamp: November 30, 2017, 12:22:59 pm
content: Quote from: Nusa on November 30, 2017, 03:59:39 amA lot more people probably noticed, but just kept it secret.

author: cdev
author_rank: Super Contributor
timestamp: November 30, 2017, 03:10:24 pm
content: I'm very surprised that the underlying BSD OS even allows a null length password.

author: timb
author_rank: Super Contributor
timestamp: November 30, 2017, 03:28:09 pm
content: 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.

author: borjam
author_rank: Unknown
timestamp: November 30, 2017, 04:27:38 pm
content: 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 routinegrantedaccess.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.

author: Neilm
author_rank: Super Contributor
timestamp: November 30, 2017, 08:02:09 pm
content: Apparently, the patch that fixed this broke file sharing. Not sure iforis more appropriate

author: rsjsouza
author_rank: Super Contributor
timestamp: November 30, 2017, 08:36:51 pm
content: Quote from: Neilm on November 30, 2017, 08:02:09 pmI agree. Apparentlya fixis in place.

author: Richard Crowley
author_rank: Super Contributor
timestamp: November 30, 2017, 08:47:53 pm
content: Quote from: amyk on November 30, 2017, 12:22:59 pmThey have to maintain the notion that Mac is invulnerable.

author: Monkeh
author_rank: Super Contributor
timestamp: November 30, 2017, 08:55:32 pm
content: Quote from: Richard Crowley on November 30, 2017, 08:47:53 pmOr, y'know, responsible disclosure.

author: Howardlong
author_rank: Super Contributor
timestamp: November 30, 2017, 09:12:48 pm
content: Quote from: timb on November 30, 2017, 03:28:09 pmI 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).

author: timb
author_rank: Super Contributor
timestamp: December 01, 2017, 08:14:05 am
content: Quote from: Howardlong on November 30, 2017, 09:12:48 pmOkay, 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.)

author: borjam
author_rank: Unknown
timestamp: December 01, 2017, 08:42:59 am
content: Quote from: timb on December 01, 2017, 08:14:05 am

author: Howardlong
author_rank: Super Contributor
timestamp: December 01, 2017, 08:51:11 am
content: Quote from: timb on December 01, 2017, 08:14:05 amDisabling 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!

author: bd139
author_rank: Super Contributor
timestamp: December 01, 2017, 10:14:33 am
content: 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.

author: borjam
author_rank: Unknown
timestamp: December 01, 2017, 11:15:23 am
content: Quote from: bd139 on December 01, 2017, 10:14:33 amIn 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.QuoteWhich 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.QuoteIt did not affect *only* root, but potentially any account locked by the traditional method of the invalid password. Read my simple description aboveof a similar cock-up in a network server in 1991. I could authenticate successfully as "bin", "tcb", "daemon", etc.QuoteProbably 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/6237In 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.

author: bd139
author_rank: Super Contributor
timestamp: December 01, 2017, 11:47:46 am
content: Quote from: borjam on December 01, 2017, 11:15:23 amActually 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.Quote from: borjam on December 01, 2017, 11:15:23 amLock it, filevault/bitlocker it. Security 101. Plan to lose it, not plan to avoid losing it.Quote from: borjam on December 01, 2017, 11:15:23 amDon't even talk to me about that turd. Many a jousting match I've had with systemd (and Poettering on a couple of occasions)

author: Howardlong
author_rank: Super Contributor
timestamp: December 01, 2017, 11:55:03 am
content: 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/

author: borjam
author_rank: Unknown
timestamp: December 01, 2017, 12:01:45 pm
content: Quote from: bd139 on December 01, 2017, 11:47:46 amRight. 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.QuoteBut note that a laptop with the screen locked is not safe from other physical access attacks (such as USB/FireWire/Thunderbolt). The onlysecure state in this case is powered off.I remember the kerfufle when some people suddenly realized that Firewire offered a DMA facility.QuoteAnyway, 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)

author: bd139
author_rank: Super Contributor
timestamp: December 01, 2017, 12:09:29 pm
content: Quote from: borjam on December 01, 2017, 12:01:45 pmBelieve 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.Quote from: borjam on December 01, 2017, 12:01:45 pmIndeed 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.Quote from: borjam on December 01, 2017, 12:01:45 pmYes 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.

author: timb
author_rank: Super Contributor
timestamp: December 02, 2017, 08:29:04 pm
content: Quote from: borjam on December 01, 2017, 12:01:45 pmWhen 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?

author: cdev
author_rank: Super Contributor
timestamp: December 02, 2017, 08:59:13 pm
content: 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?

author: timb
author_rank: Super Contributor
timestamp: December 02, 2017, 09:08:12 pm
content: Quote from: cdev on December 02, 2017, 08:59:13 pmAnd the Intel Management Engine decrypts the drive how exactly?

author: cdev
author_rank: Super Contributor
timestamp: December 02, 2017, 09:11:38 pm
content: Quote from: timb on December 02, 2017, 09:08:12 pmThere is a whole world of functionality on those boxes that the owner/user and his or her OS never even sees.

author: Electro Detective
author_rank: Super Contributor
timestamp: December 02, 2017, 09:15:48 pm
content: 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

author: timb
author_rank: Super Contributor
timestamp: December 02, 2017, 09:19:21 pm
content: Quote from: cdev on December 02, 2017, 09:11:38 pmCare 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.)

author: cdev
author_rank: Super Contributor
timestamp: December 02, 2017, 11:52:51 pm
content: Quote from: timb on December 02, 2017, 09:19:21 pm

author: timb
author_rank: Super Contributor
timestamp: December 03, 2017, 01:41:57 am
content: Quote from: cdev on December 02, 2017, 11:52:51 pmRight, 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.

author: raptor1956
author_rank: Frequent Contributor
timestamp: December 03, 2017, 03:15:47 am
content: Quote from: amyk on November 30, 2017, 12:22:59 pmYes, what are the odds that the NSA and other signals intelligence outfits around the world were aware and said nothing?Brina

author: bd139
author_rank: Super Contributor
timestamp: December 03, 2017, 09:27:39 am
content: 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.