How can we "hardened" an Android eco-system without Google?

.cn utilizes shitty firewall blocked every Google services away including Google Play and Nexus+OTA. Android phone vendors are providing their own OTA inside the .cn. For the security aspect, there are a few issues hard to solve.

1) Qualcomm/Samsung/Huawei build their own BSP based on AOSP source code. If the BSP shipped without basic security mitigation, the cellphone vendors are unlikely to backport it. It will definitely be a problem to those who concerns security and privacy.

2) Local small vendors upgrade so slow and some even may not have OTA. Security patches are hard to deliver in time.

3) .cn doesn't have Google Play, which means tons of Android apps never been well tested by malicious check before its online for the end-user.

Anyway, end-user has been suffering from the philosophy of "A-bug-is-bug". I'm going to share two stories about hardening solution. The 1st one is how I got here with help of PaX/Grsecurity's previous work. The 2nd is from Baidu( I don't talk about reputation here, not today-_-) Millions of Android phones are endangered by wilding malwares contains kernel exploits, such as HummingBad, Godless and Hellfire( Chinese version).

I'm pretty sure this is only a corner of iceberg. Organizations like underground criminals and intelligences might be use these easy-to-implement exploit to compromise those Android phone without basic mitigations. How can we still don't have ret2usr protection in 2016. Okidoki, welcome to the desert of the real;-)

I was keeping my eyes on what vulnerability and exploit exist within malware or rooting tools in past 18 months. Then I figure out that some of vulnerabilities are very popular to the offensive side: CVE-2014-3153( Futex vuln), CVE-2015-3636( Pingpong root), CVE-2015-0569( Prima wifi driver) and CVE-2015-1805( iovyroot).

I was thinking what if there's a solution to prevent those exploit without patch anything. Then I tried to make a prototype old Nexus device with hardened kernel. I did a few things on Nexus 7 2013's kernel( repo based on Jan 2014) last year by doing a couple of things:

1, Ported a PaX to flo's kernel, which is based on 3.4. Note: What I use is a relative weak version of PaX, without KERNEXEC/UDEREF/RAP and those strong Grsecurity features for x86.

2, Ported PXN( armv7). Minimal memory mapping restriction might be the 1st step for ret2usr protection and PXN should be the 2nd one.

3, Backport a security fix for CVE-2014-3153, which is the only one vulnerablity need to be fixed in my kernel. Because this version doesn't have UDEREF/PAN. Fortunately, Kees Cook done a backport of software-based PAN for 4.1.

4, Prevent infoleak to make exploit writer's life harder a bit.

I've been using rooting tools like TOWELROOT/KINGROOT/360ROOT to test this hardened version. None of their exploits can work until last month( maybe). I've also modified some need-to-hardcoded public exploit to test and I got the same result. Well, guess it seems not bad( yet).

Baidu( Google's competitor in .cn) proposed a solution a couple of months ago at HITB AMS and then release more info in Chinese at here and English version at Black Hat USA.

Unfortunately, they don't share how do they getting the root( so obviously;-)) in the 1st place. A complete steps should be like( let me know if I were wrong):

1) End-user install their apps

2) Rooting it via those easy-to-implement exploit( or getting it by reversing-_-)

3) Insert rootkit( based on inline hook framework) & Luapatch( Policy engine) into the kernel. I'm very curious if Baidu guys co-operate with Huawei. Cu'z Luapatch is looking similar to Huawei's ktap.

4) Then fixing bug ...let me guess, if you have a rootkit in someone else's kernel...well, shit will happen, as always. Otherwise, the policy engine & rootkit themselves may also have vulnerabilities. It's possible that adversary( criminals/Intelligence) will act if this solution goes popular.


IMOHO, I prefer the 1st way to solve the problem. But it's hard to convince vendors to merge the hardening patches. The 2nd solution may have potential risk to privacy, no one wants to have someone else's "god mode" in their cellphone, aren't they?

I've been analyzing different situational hardening solution and exploit method. For the defensive aspect, I hope that making more mitigation lands into AOSP kernel. Otherwise, KSPP is another way to improve Android security. Mitigation is the way to solve those issues once for all.

Update( Oct 31 2016):  Hardened PoC for Android needed a backport fix for CVE-2016-5195( a.k.a "DirtyCOW"). Cu'z it's a dangerous threat to all Android devices. There are a dozen of public PoCs, so it'd be much easier to attackers to forge their weaponized exploit to target Android devices.