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.
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.
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.
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
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
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.