www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
Reverse engineering the macOS High Sierra supplemental update
By Thom Holwerda on 2017-10-09 19:26:19

Reported by Matheus Mariano, a Brazilian software developer, a programming error was discovered in Appleā€™s most recent operating system, High Sierra, that exposed passwords of encrypted volumes as password hints. A serious bug that quickly made the headlines in technology websites everywhere.

Apple was prompt to provide macOS High Sierra Supplemental Update to customers via the App Store, and ensured that every distribution of High Sierra in their servers included this update.

I decided to apply a binary diffing technique to the update to learn more about the root cause of this bug and hypothesize about how the defect could have been prevented.

 Email a friend - Printer friendly - Related stories
.
.
Comment by sj87
By sj87 on 2017-10-10 08:50:00
As a programmer I fail to find this anything else than another day at the office. Already before reading the article, I assumed that they just stored the password as 'password hint', because that's the only option.

Passwords are usually stored in a form that is not reversible, so it just cannot pop up in another field by accident unless it was deliberately put there.

Programming is still mostly manual work i.e. every little detail has to be written by hand just as we see it happen on the screen. There rarely exists any magical method so that we just type one line of code and see a hundred things happen, no.
Permalink - Score: 4
.
Not an Apple only problem
By markus on 2017-10-10 17:28:52
In the past:
- Developers worked on specific projects
- Testing has been done manually

Now:
- Developers are treated as resources and assigned different projects as needed
- Testing is done automatically for a great part (unit tests)

A developer who works in specific projects know the pitfalls to look for and gets better over time. If you are assigned to many different projects you get better as a developer over time, but you don't get the feel for your task or feel as the owner of this task.

Automatic testing tends to prevent crashes, since for correctness you will need much time to code unit tests for every edge case.

Edited 2017-10-10 17:29 UTC
Permalink - Score: 2
.
RE: Comment by sj87
By Bill Shooter of Bul on 2017-10-10 17:53:11
Really disagree that this was another day at the office. It kind of screams out that security is an after thought at apple. Its a systemic issue, that cries out for redress. The individual developer is only partially at fault here. The system of developing software let apple down, as this really should have been caught somewhere in the SDLC.
Permalink - Score: 5
.
RE: Comment by sj87
By avgalen on 2017-10-11 11:29:18
> Passwords are usually stored in a form that is not reversible, so it just cannot pop up in another field by accident unless it was deliberately put there.
That was the most incredible thing about this whole article. The password to the disk encryption is stored in a reversible way and is read into memory.
The way this showed up was that a programmer made a change that showed the password to the world in the passwordhint-UI, but it was actually never really hidden.
As far as I understood it is still this way after the fix. The fix literally checks if the password hint is the same as the password and won't show the hint in that case. That is literally putting lipstick on a pig

> Apple acknowledged the flaw in its patch release notes: "If a hint was set in Disk Utility when creating an APFS encrypted volume, the password was stored as the hint. This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints."
Permalink - Score: 4
.
RE: Not an Apple only problem
By Sidux on 2017-10-13 08:47:54
Testing can be done separately as long as it's part of the same development team.
Same with provisioning the environment and data-sets.
The amount of technology that most software is build upon today makes it very hard to implement any other way.
Permalink - Score: 2
.
RE[2]: Comment by sj87
By sj87 on 2017-10-14 13:31:14
> That was the most incredible thing about this whole article. The password to the disk encryption is stored in a reversible way and is read into memory.
Encryption password has to be stored in memory as without it encryption/decryption is impossible. I don't know why they're storing this password on the disk in the first place, though. Maybe it is needed for some automation, and they're storing the container in an encrypted form.

> The way this showed up was that a programmer made a change that showed the password to the world in the passwordhint-UI, but it was actually never really hidden.
As far as I understood it is still this way after the fix. The fix literally checks if the password hint is the same as the password and won't show the hint in that case. That is literally putting lipstick on a pig.

I guess their point is to also 'fix' this issue for those users who were affected by the now-fixed bug and already have their password stored also as the password hint. There are different ways to tackle this problem but they decided this is the least likely way to fail at that.

Although a new issue might be that upon changing the encryption password, the app will then leak the old password that was used (and stored as pw hint), which might open an attack surface in case that the same password is in use somewhere else too.

Edited 2017-10-14 13:34 UTC
Permalink - Score: 2

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?