MotoMAGX weakness of kernel modules hashes

Security of kernel modules

Motorola uses SHA1 hash of kernel module matching to prevent "untrusted" modules to be loaded. Using the GPL'ed source code of linux kernel (actually kernel/module.c) we can study how this hash is generated. Generally, all sections of ELF file which has ALLOC flag will be used to produce a hash of module. But there are some exceptions - symbol tables are treated as ALLOCed (for kallsyms feature), .modinfo treated as non-ALLOCed, and .gnu.linkonce.this_module section is not used in hash computation. After studying this, we can speak of a weakness of this system.

Weakness

If we'll see, which sections of ELF file doesn't affect module hash - we can find that very important section - a section with relocations - doesn't have ALLOC flag, so we can easily edit it, not affecting the hash. This actually leads us to editing the module text or data in some very limited way. But that is enough - since we have .gnu.linkonce.this_module section which is ALLOCed, we can relocate some branches in kernel text to this section, where we can place our code. That's it - we can finally modify module's logic for our own needs. Actually, it is not guaranteed that we'll find suitable branch instruction in kernel text, but it seems that is not a problem in existing MAGX phones (tested on Z6, U9, E8).

Example of usage

I had chosen motsecurity_sysfs.ko module, which contains suitable branch instruction (funny thing - module with motsecurity in his name helps to break security of the phone), and I didn't find better code, than a code that disables module's hash checking in runtime.

 % arm-linux-gnueabi-objdump -rd motsecurity_sysfs.ko
 ...
 140:   e2855001        add     r5, r5, #1      ; 0x1
 144:   ea000008        b       16c <init_module-0xf0>
 148:   e5113030        ldr     r3, [r1, #-48]
 ...

As we can see, on 0x144 there is a unconditional branch to +0x28. If we'll analyze logic module's text, we can find out that this branch happens when module finds '\n' in text written to /sys/security/allowed_mounts. Let's adjust the code with relocation

 % arm-linux-gnueabi-objdump -rd motsecurity_sysfs_new.ko
 ...
 140:   e2855001        add     r5, r5, #1      ; 0x1
 144:   ea000008        b       28 <init_module-0x234>
                        144: R_ARM_JUMP24       __this_module
 148:   e5113030        ldr     r3, [r1, #-48]
 ...

__this_module is a symbol that can mean "start of .gnu.linkonce.this_module section". So, now this instruction can be interpreted as "unconditionally branch to code, which is placed in .gnu.linkonce.this_module+0x28". 0x28 is a great choice, because it points to space which is reserved to null-terminated kernel name string. We have enough space to execute following code

 ptr:    .word 0xc005f914
 old:    .word 0xebfffdb1
 new:    .word 0xe3a00000
         sub     r7, pc, #0x14
         ldmia   r7, {r4, r5, r6}
         ldr     r7, [r4]
         cmp     r5, r7
         streq   r6, [r4]
         mvn     r0, #0x1
         sub     sp, fp, #0x20
         ldmia   sp, {r4, r5, r6, r7, r8, fp, sp, pc}

which safely changes a word at 0xc005f914 from 0xebfffdb1 (call hash cheking subroutine) to 0xe3a00000 (put 0 to r0, successful "checking") and returns from orignal sysfs write handler. Let's put it in ELF section

 % arm-linux-gnueabi-objdump -rD motsecurity_sysfs_new.ko
 ...
 1c:   c005def4        strgtd  sp, [r5], -r4
 20:   ebfffdb1        bl      fffff6ec <cleanup_module+0xfffff3ec>
 24:   e3a00000        mov     r0, #0  ; 0x0
 28:   e24f7014        sub     r7, pc, #20     ; 0x14
 2c:   e8970070        ldmia   r7, {r4, r5, r6}
 30:   e5947000        ldr     r7, [r4]
 34:   e1550007        cmp     r5, r7
 38:   05846000        streq   r6, [r4]
 3c:   e3e00001        mvn     r0, #1  ; 0x1
 40:   e24bd020        sub     sp, fp, #32     ; 0x20
 44:   e89da9f0        ldmia   sp, {r4, r5, r6, r7, r8, fp, sp, pc}
 ...

First three instruction is actually our data, our entry point of this code is 0x28. In current example the string with a name should be shortened - to "motsecurity_sys" for example.

You can get working example for 44R Z6 firmware here. Please ensure that you have 6ccb945a8bd6726df807cdba7992c5c63eb4d246 listed in trusted hashes (/etc/modules.hash), and that your kernel's md5 is 34517c12b2f6c9cb7a8898345ddc1b1f (you can calculate it on /dev/mtdblock/kern).

Better way to patch a kernel

As we can obtain an addresses of kernel symbols using kallsyms, we can can make this exploit to be more convinient. It would be hard (or even impossible) to use kallsyms lookup subroutines from our kernelspace code, so it is possible to write userspace helper, that looks address of module_hash_verify in /proc/kallsyms, modifies module's code to use that address and inserts module. It should be fairly simple. The kernelmode code itself should replace first to words of module_hash_verify with

 e3a00000  mov     r0, #0
 e12fff1e  bx      lr

If we'd assume that module_hash_verify's code consists of at least two instructions, it would be fairly safe to do such substitution. Thanks for WyrM for idea. Simple and dirty implementation is here.