Root takeover via signature spoofing in tiann/kernelsu

Valid

Reported on

Oct 8th 2023


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)

Impact

If a KernelSU installed device is infected with a malware whose app signing block specially crafted as mentioned above, it can take over root privileges on the device.

Occurrences

We are processing your report and will contact the tiann/kernelsu team within 24 hours. 4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
Yusuf modified the report
4 months ago
We created a GitHub Issue asking the maintainers to create a SECURITY.md 4 months ago
We have contacted a member of the tiann/kernelsu team and are waiting to hear back 4 months ago
tiann/kernelsu maintainer has acknowledged this report 4 months ago
weishu gave praise 4 months ago
The researcher's credibility has slightly increased as a result of the maintainer's thanks: +1
weishu
4 months ago

Maintainer


Magisk has the same vulnerability?

weishu validated this vulnerability 4 months ago
0x33c0unt has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
weishu
4 months ago

Maintainer


We have successfully constructed such an apk according to the PoC, and the vulnerability is confirmed to exist.

weishu
4 months ago

Maintainer


We've made a fix: https://github.com/tiann/KernelSU/pull/1027

Yusuf
4 months ago

Researcher


Thanks for the urgent response. I would like to emphasize this note from above:

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
Yusuf
4 months ago

Researcher


For the magisk topic, I don't know if I am allowed to comment on another possible or not vulnerability.

weishu
4 months ago

Maintainer


Sorry, i will make a new fix.

weishu
4 months ago

Maintainer


We've reproduce it in Magisk, i think you should report to it too.

Yusuf
4 months ago

Researcher


Seems like a sane fix @weishu, thank you a lot for the great collaboration. Can you update status to fixed please? And shall we request a CVE for this issue?

weishu
4 months ago

Maintainer


I will mark it as fixed when 0.6.9 released. I don't know the procedure of CVE, what is your advice?

Yusuf
4 months ago

Researcher


I think, if you have nothing against it, huntr.dev will take care about it

weishu marked this as fixed in v0.6.9 with commit a22959 4 months ago
weishu has been awarded the fix bounty
This vulnerability has now been published 4 months ago
apk_sign.c#L74 has been validated
weishu
4 months ago

Maintainer


It seems to work, thank you again!

Yusuf
4 months ago

Researcher


glad to hear, thank you, too!

to join this conversation