Checklist 70: Apple’s No Good Very Bad Security Quarter

For more than a year, we’ve been taking a little time every week here at The Checklist to bring you a podcast focused on and around the security of the Mac, iOS devices, and the Apple platform in general. We all know that was silly, though — after all, there aren’t any major security problems with Apple, right?

There is no such thing as 100% safe & secure, although it has indeed been the case that Apple systems experience fewer major vulnerabilities and problems than their counterparts, generally speaking. Towards the end of 2017, though, it appears Apple itself was hellbent on disproving all these notions that many of us hold. There were bugs, there were vulnerabilities, and then there were the “fixes” that led to even more bugs. Then, to make matters worse, when you tried to fix the fix, you could end up reintroducing the vulnerability that caused the problem in the first place!

With all the problematic news that made waves and sent Apple hurrying to push our security updates, we’ve decided to dub this as Apple’s No Good Very Bad Quarter in security. So here’s what we hit on today’s episode of The Checklist:

• The Worst Game of Password Ever
• The “I Am Root” bug
• The HomeKit zero-day vulnerability
• The Endless iOS Reboot cycle

Let’s kick things off by looking at a surprising slip-up from the Cupertino giant in the realm of password security.

The Worst Game of Password Ever

In September of 2017, Apple released the latest edition of macOS, which they dubbed High Sierra. Alongside a host of changes, one of the most significant differences between Sierra and High Sierra is something fundamental to the way your Mac works: its file system. Previously, Apple used a system called HFS+, which had several drawbacks making it ill-suited for modern use. To solve these problems, Apple introduced the new “Apple File System,” or APFS for short. For the most part, this is a great change!

APFS brings a lot to the table and offers some serious speed boosts over the old HFS system. Users on High Sierra might not notice all the changes directly, but behind the scenes, it does a lot. With the rise of solid state drives and their ability to read and write data rapidly, APFS improves their performance with faster disk operations. That translates to a faster boot time. Copying and moving files is faster as well. APFS helps protect your data in the event of an unexpected crash (such as a power cut) and also brings full-disk encryption to both files and their metadata. The result is a much more secure, locked-down file system. So, everything here is good, right?

Unfortunately, Apple let a crucial bug slip through in the password field for encrypted APFS hard drives, and it started making waves in the news about a month after High Sierra’s release. It all has to do with the way High Sierra handled user passwords for their encrypted drives. Here’s how it breaks down.

Like with almost anything protected by a password, Apple lets you create a hint when you encrypt a drive. This way, if you forget how to unlock the contents of the volume, you can hopefully use the hint to jog your memory and regain access. Sounds simple enough, but somehow, High Sierra shipped  with a bug that did not display a user’s hint upon pressing the “Show Hint” button. Instead, it showed your actual password — right there in plain text! Someone who wanted to get into the drive wouldn’t even need to try guessing a passcode because your Mac would have simply given it to them right away.

It seems that what happened is a simple error: perhaps a line or two of code was wrong, and it caused the system to store the encryption password in the unencrypted location used for the password hint. As a result, the system thinks it’s showing you the hint, when in fact it stored the wrong value there at the start. Not something you want to see when using a system that’s supposed to be more secure, right?

Thankfully, Apple was quick to respond once the bug became public news. With a short turnaround time, the company published an update to High Sierra that corrected the issue within just a week of its disclosure. That’s High Sierra 10.13 — for those of you who may not have updated yet, now is a good time to do so to ensure this bug isn’t present on your system. Apple also published a help page on their website to walk users through the process of fixing volumes displaying this bug. However, this was only the beginning of Apple’s issues during this past quarter.

The “I Am Root” bug

Where the APFS password bug is problematic but not earth-shattering, the next bug on our list for today is pretty close to the definition of a “worst-case scenario.” Called the IAMROOT bug, and also present in High Sierra, widespread attention first came to this issue in late November after a developer noticed something extraordinary and began tweeting out the details. At stake: the ability to gain the highest level of control over any given Mac running High Sierra. Due to IAMROOT, anyone could log in to a Mac as the “root” user without any knowledge of the password at all.

On UNIX-based computer systems like macOS, “root” is the most powerful status a user can assume. It enables access to many more levels of the system. In other words, it’s not the type of access you want in the hands of anyone who isn’t you. Thus, the ability to get in without knowing the password is a pretty serious issue. To exploit IAMROOT didn’t even take a lot of effort or even technical knowledge.

In fact, all one had to do to gain root permissions was to leave the password field blank. Make a few unsuccessful login attempts with a blank password, and eventually, the system lets you right in! Now you’re logged in as root with the ability to exercise extensive powers. Going on behind the scenes, the bug was actually more complex than the system merely deciding your blank password was legitimate. In fact, the system was completely overwriting the root password value and resetting it with whatever you had continued to supply in the password field. Whether you tried to log in with no password or a made-up password several times, the system would let you in regardless.

What happened here? This is a high-severity problem, and not one that you would expect Apple to make. The culprit: a logic bug affecting the password verification code Apple wrote into the system. By default, Apple disables the root account for all Macs; users must manually enable it for access. When High Sierra attempted to verify the password for a disabled account (such as root), it failed to check the entered password against the stored value. Instead, the logic bug caused the system to take the supplied password and apply it to the root account as a “new” password.

For nearly two weeks before Twitter users began to call attention to this serious issue, posts about the flaw had been circulating on Apple’s developer forums. Somehow, none of Apple’s security team noticed these reports, and nothing was done to correct it until the news gathered steam on Twitter. At that point, Apple scurried to issue a patch for this bug — perhaps too rapidly. In their haste, the fix for the bug began a problem in its own right.

Perhaps in an effort to show good faith and a commitment to users, Apple required only about a day to create and publish a patch for IAMROOT. Called Security Update 2017-001, the patch did indeed fix IAMROOT and restored the password functionality to the proper procedure. While great that they got a fix out the door so fast, it appears the Quality Assurance team should have taken a closer look before sending it out the door.

Due to the severe nature of IAMROOT, Apple decided to place the patch into their critical update pipeline that functions through the macOS automatic update feature. In other words, even if you did not choose to install the update right away manually, macOS would take the initiative and apply the update automatically. Generally, this isn’t a bad thing — it’s a fast and easy way for Apple to ensure users receive fixes of the highest priority. However, Security Update 2017-001 introduced a new bug, completely breaking the File Sharing utility. Without delay, users began to complain about this new problem.

This, of course, led to another patch to restore File Sharing back to working order. For whatever reason, Apple chose not to increment the update version number when they pushed this fix to users. The result is that this update was also called “Security Update 2017-001” — and that was the start of another round of problems for users.

This version fixed IAMROOT and ensured File Sharing worked correctly too. However, if users were running the original version of High Sierra (v. 10.13.0), applied the update, and then updated to macOS 10.13.1, they essentially undid the entire patch. Thus, they would have to do the entire upgrade process all over again — a problem that probably could have been avoided with proper version numbering.

Of course, at this point, you would also have to perform a reboot of the system to ensure everything worked correctly. As that wasn’t required with the initial update, it led to further confusion about whether the issues were fixed. Suffice to say there were some serious breakdowns in both communications and testing procedures during this fiasco.

The HomeKit zero-day vulnerability

As if dealing with the IAMROOT bug wasn’t enough for Apple’s security team, it wasn’t long until the next issue was breaking into the news. This time, it was a problem concerning Apple’s HomeKit suite, and it was a big one: a zero-day vulnerability. (A zero-day exploit occurs when someone finds a way to manipulate a weakness that was previously unknown or undiscovered).

A quick refresher: HomeKit is an “Internet of Things” framework that allows users to exercise control over HomeKit-supported devices from their iOS device. That means you could change the thermostat temperature from your phone, flick the lights on or off, or even unlock the front door, provided you had those products installed. We’ve covered HomeKit and some of its pros and cons in a few of our previous episodes on the Internet of Things; you can find those in our archive for a more in-depth dive on that subject.

Actual details on what the vulnerability involved are hard to come by; media reports described it as difficult to replicate, and it’s clear Apple doesn’t want further information about the methodology out in the wild. HomeKit has a general reputation for being one of the stronger, more secure home IoT platforms out there, but that doesn’t mean it’s invulnerable — and this threat could have been serious.

Apparently, the only thing necessary to execute the exploit was an iOS device on version 11.2 (then the latest release) connected to the target user’s iCloud account. With that setup, an attacker could take total control over the victim’s connected devices. As you can imagine, for someone who might use a web-connected door lock, that’s a frightening situation!

It appears Apple wasn’t moving as quickly as perhaps they could have been on this particular issue. It seems that the company knew about this potential vulnerability since at least the end of October, but hadn’t yet deployed a patch. When the website 9to5Mac scooped the story about the exploit, they warned Apple they were going to press with the story.

This kicked the development team into high gear, as Apple issued a patch within just 48 hours of learning about 9to5Mac’s story. While that turnaround time is commendable, it’s another example from this past quarter of Apple not being quite on the ball. Should it really take a publication getting a hold of the story to finish off an update for a product that prides itself on security?

The Endless iOS Reboot cycle

Not all the problems that cropped up for Apple over the past few months were related to security, though. One of the big issues we encountered was actually just a big bug in iOS itself. It affected many users and generated some serious consternation on web forums online. At the root of the problem was a bug surrounding local, app-generated notifications. When the bug hit, iOS devices worldwide ended up locked into an endless cycle of reboots.

It all started at exactly 12:15 AM on December 2nd. At this point, some iPhones and iPads began to use 100% of their CPU and would subsequently automatically soft reset, creating unresponsiveness in the devices until the user’s lock screen popped back up as normal. Within a minute or two, though, the problem would repeat, rendering the device practically unusable. No matter what a user did, including a full restart of the phone, the phone would continue to reboot every couple of minutes.

The cause was a bug related to apps that triggered notifications in a set schedule, such as daily or hourly reminders. When the app tried to trigger a notification, the bug kicked in instead and set off the endless reboot cycle. Once made aware of it, Apple began to advise users — but it wasn’t exactly the right thing to do. At first, they suggested users set their time and date backward by one day as a stopgap solution while they prepared a software update. While this did stop the bug, it also stopped a lot of other iOS functionality — such as apps that rely on encryption for communication. With the incorrect time and date set, these apps could no longer function, leaving users locked out of several typical services.

Users instead should have been directed to simply disable notifications altogether, as this would have cut the bug off at the source. Ultimately, though, Apple released iOS 11.2 to rectify the issue altogether. It did fix the problem—but then introduced yet another! Apple forgot to update Xcode, the primary programming application for developers on macOS and iOS. Xcode believed 11.2 to be an invalid version number and thus ceased functioning, prohibiting developers from releasing apps for devices that were up to date. Finally, after all this, Apple patched Xcode as well and restored things to order. It seems like a fitting capstone to a quarter filled with security snafus and poorly planned update rollouts.

With that, we’ll wrap up this edition with the hope that as we plow onward into 2018, Apple can regain a firmer grasp on its development efforts to reduce the number of problematic bug issues such as these. Want to go back and find out more about what’s gone on with Apple over the past year? You can easily look back through the show notes for all our previous episodes right here on our site — and that’s right where you’ll find notes for future episodes, too.

Got questions? Have an idea for a topic you’d love to hear us discuss sometime? Send an email with your comments and concerns to Checklist@SecureMac.com — we’d love to hear from you! As always, we’ll return next week with another discussion.