640K!enough wrote on 2020-11-28, 22:16:
Do you have any idea what caused it to lose the ability to decrypt the volume? Could it have been user error or tampering durin […]
ragefury32 wrote on 2020-11-26, 23:02:
The T2 is known to do some really strange things - Ever since I witness a T2 on a Mac crap the bed and lose the ability to decrypt the APFS volume right before a major trade conference I had been less than complementary towards it. When you are asked to put all eggs in a single basket, you better make sure that the basket in question is sturdy, and Apple...does not extol that trait.
Do you have any idea what caused it to lose the ability to decrypt the volume? Could it have been user error or tampering during pre-flight inspection (assuming a flight to the trade-show)?
ragefury32 wrote on 2020-11-26, 23:02:
Let’s not kid ourselves - security by obscurity coupled with “trust us, we know what we are doing” does not scream confidence.
To me, that is an admission by Apple that they aren't sure they know what they're doing, or that they knew something was wrong with it, and they hoped nobody would notice or take the time to do the research. This reminds me of a leaked presentation from CSE (formerly CSEC) a few years ago that said something to the effect that "if it's an Android device, we can probably access its data. If it's an iPhone, we know we can access its data". So much for "what happens on iPhone stays on iPhone"; convincing marketing for those who don't know any better, and not much more than that. With Apple, it's barely security through obscurity, and more like security by marketing. First the "gotofail" embarrassment, now the T2 disaster, and who knows how many in between and yet to come. For a company that arrogant, you would at least expect them to try harder.
Lastly, before the Apple-faithful try to rush to their defence, I am not being unfairly critical of Apple. Firstly, they deserve the criticism, and secondly, it's only because this is the issue that was recently in the news. If/When Pluton suffers the same fate, I won't hesitate to start or participate in a discussion of that.
If I have to point fingers - the end user was supposedly doing a MacOS upgrade (which can include firmware updates) when the T2 freaked out - either:
a) The end user did the update unsupervised and didn't plug the machine in, the battery ran down, and this somehow that messed up the T2.
b) The machine was bound to onprem ActiveDirectory with a mobile profile, but the user was traveling and not synching back to the domain controller regularly via VPN, so the FileVault password is likely desynchronized between the cached one, the AD copy and the previous AD copy. AD/LDAP binded machines have been problematic with MacOS ever since High Sierra due to subsystem changes Apple made. The password might’ve simply have been forgotten, although the fact that I also couldn’t get into the admin account on the machine was also a bit...troubling. I didn't really care enough to investigate too far. I dispatched a spare, the end user sent the busted machine back to me, I sent it to my AppleCare guy to see if there's a hardware fault (they can't find any), and once it's cleared up I recovered as much as I can and handed it back out.
I do not trust the T2 chip entirely, but that's more based on its nature as a single point of failure for multiple systems, and how it sits in a chain of trust. Basing your current security scheme off old silicon and making it difficult/impossible to patch it was just hubris. Just imagine what happens if the MS Surface Pro uses the SoC from a Zune music player to implement its security enclave...
Let’s not forget that while the Apple haters had a field day with gotofail (which dates back to Mountain Lion/Mavericks 6 years ago) there was a very similar GnuTLS slip-up involving dead code (CVE-2014-0092) - both of them involving a duplicated goto state that caused the goto conditions to be executed by default rendering checks redundant.
https://www.synopsys.com/blogs/software-secur … ulnerability-2/
GnuTLS GotoFail (read the patch file for an idea of what happened):
https://www.openembedded.org/pipermail/openem … rch/208670.html
Note that Apple had one condition bypassed with a duplicate goto statement - GnuTLS had 3.
The GnuTLS issue impacted nearly every Linux distribution out there in early 2014 (RHEL/CentOS 5/6, Debian 6/7 and other similar distress) and I had to scramble to get production servers patched. In my mind, that's even more of a screwup. In both cases the code is open source and the issue was quickly found and fixed.