Android 14 Nonetheless Permits Modification of System Certificates
Android 14 Nonetheless Permits Modification of System Certificates
Tim Perry lately claimed in an article that “Android 14 blocks all modification of system certificates, even as root”. This sparked significant discussion on Hacker News. Fortunately my checks present that it’s nonetheless potential to regulate the system certificates retailer in Android 14.
Replace Sept. 15 2023, 6:34 AM Pacific: After I’d already written this submit however earlier than I posted it, it appears like Perry already found that he can solve this problem for his functions by bind mounting the /apex/ mount again to the /system/ partition within the namespace of zygote and the youngsters of zygote. The core of the concept got here from a Mastodon thread with @tbodt and @tmw. This submit nonetheless supplies a barely various technique, so it’s nonetheless related, in addition to nonetheless being related to the broader dialogue.
Customers Can Nonetheless Revoke System Certificates Belief By means of the Settings App
The headline of Perry’s article asserts that even root customers can’t “modify” the system certificates in any respect. The truth is, even in Android 14, all customers can nonetheless take away certificates authorities (CAs) from the listing of trusted CAs within the Settings app, similar to they might in earlier variations of Android.
To verify that the Settings app nonetheless works, I used an Android 14 emulator to revoke belief from all of the Amazon and Starfield Applied sciences CAs. I then accessed Amazon Trust Services Repository’s check pages utilizing Chrome. They did not load attributable to an untrusted CA. I additionally confirmed the revocation of belief persists throughout reboots.
Primarily based on this, I feel the headline of Perry’s article is overly robust. Many of the extra impassioned feedback on Hacker Information took the headline’s robust declare at face worth. You will need to be clear: customers nonetheless retain final management over the belief anchors in Android 14.
Builders Can Nonetheless Add Trusted System Certificates by way of ADB
Once I revisited the article after studying Perry’s feedback on HN and Mastodon, it grew to become clear that his major concern was the lack to simply add momentary system CAs by way of ADB. This characteristic is vital for his product, HTTP Toolkit. It is usually vital for a lot of different safety researchers and app builders, myself included.
Whereas Perry accurately notes that the standard technique not capabilities with Android 14, the characteristic hasn’t been discarded.
I initially anticipated a deep dive into APEX and its signing intricacies. Fortunately, an easier, albeit considerably crude, workaround exists for this as a proof-of-concept. This isn’t appropriate for manufacturing use. For a manufacturing setting, it’s essential to rigorously restrict SELinux and tmpfs safety choices to grant solely the minimal privileges. Alternatively, one can assemble a correctly signed repacked APEX.
# These instructions assume a root shell.
#
# Take care of the truth that there will probably be executables on the /apex tmpfs
# !! Not appropriate for manufacturing utilization !!
setenforce 0
mount -o remount,exec /apex
# Make a replica of the present conscrypt APEX contents
cp -r -p /apex/com.android.conscrypt /apex/com.android.conscrypt-bak
# Lazily unmount as a result of conscrypt could be in energetic use
umount -l /apex/com.android.conscrypt
rm -rf /apex/com.android.conscrypt
# Put contents of conscrypt APEX on /apex tmpfs mount
mv /apex/com.android.conscrypt-bak /apex/com.android.conscrypt
# Gentle userspace reboot to get the whole lot again right into a constant state
killall system_server
# Clear system belief anchors, if desired
mv /apex/com.android.conscrypt/cacerts /apex/com.android.conscrypt/cacerts-bak
Executing these steps clears the system CA listing within the “Trusted credentials” part of the Settings app – the outcome desired within the unique submit.
This breaks by way of the mount namespaces by re-writing the listing entry for /apex/com.android.conscrypt on the /apex tempfs. The precise filesystem is shared between all namespaces, so overwriting this mount level has a direct impact seen from all namespaces, although the unmount occasion itself will not be propagated. Hat tip to @tbodt on Mastodon for pushing me to dig into this until I fully understood it.
After this setup, including trusted certificates is sort of similar to prior variations. The one change is utilizing /apex/com.android.conscrypt/cacerts because the vacation spot path. I confirmed this by including my private CA as a system belief anchor.
This course of solely necessitates root entry and doesn’t require altering /system. Should you want persistence past a single boot, you’ll want to switch the /system partition, simply as in older Android variations. Be ready for the slight complexity of both deleting or repacking the com.android.conscrypt APEX. I depart that as an train to the reader.
Verdict: All Is Nicely That Ends Nicely
Sure, Android 14 has altered the conduct of its system certificates retailer. However customers’ freedoms stay intact. The modifications simply add a layer of indirection facilitating over-the-air updates to the certificates retailer. Given Android’s replace delays have previously hurt CAs like LetsEncrypt, it is a constructive transfer. I can see how the brand new layer might appears sophisticated at first, nevertheless it does have to fulfill some fairly robust constraints.
Kudos to Perry for highlighting this modification. Varied instruments will must be up to date to work with Android 14. As soon as that’s achieved, I’m optimistic that safety researchers, builders, and reverse engineers will retain their earlier capabilities to tinker and make.
Disclosures
I’m buddies with Googlers and former Googlers, however I’ve by no means labored for Google. I’ve beforehand labored as a security-focused developer for a small Android OEM, which is why this caught my consideration. I don’t presently work for anybody, so these opinions can solely be my very own.