Description

When an app requests “CMD_BECOME_MANAGER” via prctl, couple of checks done before promoting uid as root manager. Main check relies on requester’s signature. Signature control is done in check_v2_signature function in kernel\apk_sign.c, this function accepts both V2 and V3 signatures (irrespective of the Device’s API level)

if ((id ^ 0xdeadbeefu) == 0xafa439f5u ||
		    (id ^ 0xdeadbeefu) == 0x2efed62f) {

0xdeadbeef ^ 0xafa439f5 = 0x7109871a (v2 signature)

0xdeadbeef ^ 0x2efed62f = 0xf05368c0 (v3 signature)

At any found signature, it checks whether size and a custom hash matches, if so, return value is set to 0 (correct in this case) and loop is broken and the value that indicates signature confirmed is returned.

			if (size4 == expected_size) {
				int hash = 1;
				signed char c;
				for (i = 0; i < size4; ++i) {
					ksu_kernel_read_compat(fp, &c, 0x1, &pos);
					hash = 31 * hash + c;
				}
				offset += size4;
				if ((((unsigned)hash) ^ 0x14131211u) ==
				    expected_hash) {
					sign = 0;
					break;
				}

According to android signature verification process,

if API Level >= 28, signature V3 checked and if it is correct, app is installed. In this case we can place the expected signature as V2 signature in to app signing block before V3 signature, and this authentication mechanism could be bypassed because it will first encounter the V2 signature then verify it and return with confirming response.

If 24 <= API Level < 28, signature V2 checked and if it is correct, app is installed. In this case we can place the expected signature as V3 signature in to the app signing block before V2 signature and this authentication mechanism could be bypassed because it will first encounter the V3 signature then verify it and return with confirming response.

If API Level < 24, devices will only check V1 signature and then install the app, so locating either V2 or V3 fake signature into App Signing block will lead to bypass of this authentication.

More about signing schemes

PS: Worth to mention that a correction on control order of signatures alone won’t be enough to fix the vulnerability. Relying on comparison of 4 byte-length hash is weak against brute-force attacks.

Proof of Concept

1. Dump signing block from the latest release of [KernelSU root manager](https://github.com/tiann/KernelSU/releases/download/v0.6.8/KernelSU_v0.6.8_11238-release.apk)
2. Sign your app with any certificate (according to target device's api level and aforementioned selection process, e.g if target API > 28, only sign with V3 certificate)
3. Place dumped signing block to your own app (e.g, if target API > 28, place V2 signing block of KernelSU app before V3 in your app's app signing block)
4. Verify app signing block(e.g, if target API > 28, Blocks are: V2 Spoofed block that comes from dump of KernelSU app, V3 actual signature of your app)
5. Install your app and request CMD_BECOME_MANAGER via prctl
6. Verify that  `prctl(KERNEL_SU_OPTION, CMD_BECOME_MANAGER...`  returns KERNEL_SU_OPTION (0xDEADBEEF)