CryptoSmite
What is CryptoSmite?
It is a code name for a Cryptohome exploit that we have made.
How does this exploit relate to exploits in the past?
In the past, we have seen cryptohome exploits that used symlinks to persist themselves in the system. We used that idea, to create our exploit, which allows modification of user data.
What were the limitations?
Cryptohome can be barely modified by a RMA shim (or sh1mmer). The initialization system of Chrome OS reads a key that is wrapped with a TPM Key. Unfortunately this key is inaccessible due to a clear between verified devmode transitions. Also the system powerwashes even if you don't boot into it (from what I have seen).
How did we get past them?
We figured out how to get past this system. While there is no way (foreshadowing) to prevent the tpm key from getting cleared, we can use the fact that there was still one entrypoint that accepted custom stateful keys.
"Note that the design goal is that a TPM clear should always destroy the cryptohome, otherwise this opens up a way for a persistent attacker go perform a TPM clear and re-write install attributes for example. See also https://bugs.chromium.org/p/chromium/issues/detail?id=776771." - Mattias Nissler (gerrit link)
What can we see from this quote, we can see that we can overwrite install attributes. We aren't entirely sure what the contents of 776771 is but is still serious none the less.
What we did with this ability, was we first tested with an unenrolled stateful, and hopefully a policy reload will get rid of FWMP. It didn't. After looking at the chromium source code a little more, we notice that there is another way to get rid of FWMP.
The Ash Ownership System (and FWMP removal)
The Ash Ownership System, checks for the ownership of the system. While we didn't know much about this system, we knew that it was used in one of the Auto Enrollment helpers. AutoEnrollment checks for ash ownership, and then uses that information to remove FWMP. Without much information of the ownership system, we decided to use an unenrolled stateful and restart the oobe, by lying about its completion status in Local State. That modification led to the removal of FWMP. We were able to later develop a minimal stateful, by just placing an owner key at var/lib/devicesettings/owner.key and that would sucessfully remove fwmp after it existing, and containing a valid key (which wasn't wrapped with tpm stuff)
What did we learn from this experience?
Responsible disclosure, with letting google fix the bug, was the best route. We believed that it is a core value to hold, of responsibly disclosing vulnerabilities. Another thing we learned from this moment, was that we shouldn't leave any holes, even if people say that the bug won't get accepted by Google. It is always still a good idea to get stuff reported, and recognized as a good security researcher. We also learned. about security practices of not getting exploits leaked quickly. Another thing I've learned from seeing these patches, is that we should always generate data, not rely on data that exists, because there is a chance that it is compromised, but generated data isn't.
Always remember, learning how to research, is more important than the research itself.
Timeline:
Initial vuln discovery: 9/9
Exploit was completed at 11/1
Exploit was succesfully ran and tested 11/2 by Fallenmoon8080
Minor bugs were fixed on 11/3
FWMP Removal is finished by the end of 11/4
Exploit reported on same day
Exploit has been made public and responsibly disclosed by Febuary, I'm hoping it will release earlier if the chrome team allows for this. (my prediction is right lets goo!)
