Got it.
Any idea about why I can't leak anything? is there anything I can check to see if overwriting is taking place?
Any idea about why I can't leak anything? is there anything I can check to see if overwriting is taking place?
truthfully, i'm not sure. haven't worked with this bug at all on 32bit. if i had to guess, maybe wait_queue_head has some padding in it in between fields on 32bit. if you have another 32bit device that's unlocked, you could try compiling the kernel yourself and adding print statements to debug.
wait_queue_head is 12 bytes (checked at compile time), so there's no padding.
I have a couple of 3.18 with unlockable bl (one of those is already temprooted) and the kernel source available. Is there something special I need to debug?
nah, the way i do is it by adding printk statments and looking at them in dmesg. i'm sure there are more sophisticated ways of doing it, but i don't know of any that don't require sodering. if anyone knows of any, please share! anyway, i'd start by adding a printk statement where kfree is called for binder_thread, and where the iovec array gets allocated in the writev syscall and see if they match the same memory address. you'll be able to tell what printk statements related to the exploit process by looking at the pid/tid printed by the message line. good luck!
Well, it sounds very tricky ( I have no idea how to patch a syscall) but I can try.
Stupid question: can I read back iovec_array[some_index].iov_base to see if it was overwritten with a kernel address?
not from userspace, as it will all happen in the kernel. it's not tricky at all, as when you compile the kernel yourself you just add print statements in the places you are interested in. you just have to find the corresponding parts of the code.
for example, here is where the writev syscall is defined on this kernel:
http://androidxref.com/kernel_3.18/xref/fs/read_write.c#905.
here is where the iovec array is allocated for that call:
http://androidxref.com/kernel_3.18/xref/fs/read_write.c#754
if i wanted to know if the uaf is happening i would add:
Code:
printk("iovec array kernel ptr %lx\n", (unsigned long) iov);Thanks!
Patched, here's the output:
Code:
[ 256.510229] <0>binder_thread kernel ptr c8700600
[ 256.510250] <0>iovec array kernel ptr c8700600I found what kills the exploit in my device when it tries to use root privileges. Looks like HKIP (Huawei Kernel Integrity Protection) exists in these kernels, but as it looks so far it doesn't use any hardware based hypervisors. I haven't digged much into this but it seems to evaluate under certain criteria whether a UID to 0 escalation is "legal" and sends a SIGKILL if it isn't. But skimming the code it looks like setting both kernel addresses hkip_uid_root_bits and hkip_gid_root_bits to 1 would turn it off. (Not sure whether this will completely bypass it, it looks counterintuitive that a kernel protection that is meant to protect against a privileged process can be disabled by flipping an address)
Last edited:
Have you tried to use RW capabilities to bypass that check?
I still can't figure out how to bypass KASLR (would it be somehow possible to bypass it without first bypassing KASLR?) If there is no other way I'm going to compile the kernel this weekend and find the offsets to bypass KASLR the way the original exploit did.
BTW @chompie1337 did you figure out a way to bypass KASLR on your 4.4 device?
Thanks!
i did it by searching for code signatures, starting at some base address. if you find somewhere in your kernel binary that references the global you want, i would look for those bytes and calculate the address that way
One way to bypass KASLR would be to look at some of the fields in the task structure that always correspond to a particular kernel symbol, e.g., nsproxy or restart_block.fn. Once one has the correct address for that kernel symbol, one can search forward from the symbol in kernel memory to find the kallsyms table, look up the symbol in the table, and compare the kallsyms table address for the symbol with the actual memory address.
Were you able to get a root shell on your s8 active using your version of the exploit?
Thank you very much for your ideas! (and @arpruss thanks for coming back to share your ideas) I implemented @arpruss's suggestion to the best of my knowledge (if I can't get this working I will search with code signatures. It's harder but looks completely foolproof. Nice idea BTW!) and am getting some strange outputs. Because I don't know how to look up task_struct fields by name I just iterated through all task_struct values that could be kernel pointers because task_struct isn't very large, setting them as the kernel base. Also please forgive me if I'm missing something very obvious or have broken something, I'm still not familiar a lot with how this exploit works and I only know a little of C.
The changes I made (roughly):
1) Make search_base a global variable
2) Defining KERNEL_BASE as search_base
3) kptrLeak function iterates over the task_struct addresses and if an address has a value above 0xffffff0000000000, take that as the search_base and call loadKallsyms()
4) Terminate loadKallsyms() if kallsyms entry counts mismatch (else leads to a segmentation fault, or rarely a device crash or bus error)
5) Some other minor changes which I can't quite remember
The code gives this output:
Anyone have an idea about what is happening here?
(Sorry if this makes no sense but could the kallsyms table be split in two somehow? Or maybe the code doesn't find the kallsyms table at all?)
Thank you very much!
Last edited:
kallsyms tables start with 0x100 alignment. So you should align your search base by ANDing it with ~0xFF. I think what happened was that your search was misaligned and hence missed the start of the alignment.
Yes, you can't lookup fields by name, but you can be a bit clever by looking at the sort of data that neighboring fields have. For instance, the pid and tgid fields seem to both always have the process PID in them. Etc.
Yes, you can't lookup fields by name, but you can be a bit clever by looking at the sort of data that neighboring fields have. For instance, the pid and tgid fields seem to both always have the process PID in them. Etc.
no
i'm close, i can bypass SELinux to attempt to employ the method in the Shen paper. I get past the execute_no_trans denial but I crash. i don't know why. someone messaged me saying they could bypass Knox for the S8 but they didn't message me back, lol
---------- Post added at 07:01 PM ---------- Previous post was at 06:59 PM ----------
i think in my attempts that code was able to "find" the kallsyms table but the dereference was failing. i just used code signatures as it was easier and most of the stuff i was looking for isn't in kallsyms
Yes, I was wondering why the offset in loadKallsyms was ANDed! (So I should AND search_base the same way, right?) BTW where should I AND the search_base? Just after the search_base was selected, somewhere in loadKallsyms or find_kallsyms_addresses, or elsewhere?
I left a few minutes ago and don't have access to a PC now, would try dumping addresses adjacent to the possible addresses and looking for patterns when I get back!
Thank you!
Last edited:
It has to happen before find_kallsyms_addresses() starts going through memory. You can do it in loadKallsyms() if you like or in find_kallsyms_addresses().
By the way, on a device with KASLR, how do you recognize a kernel pointer?
Thanks, would try when I get to my PC.
The code I added doesn't accurately recognize kernel pointers when iterating for search_base, it just takes all addresses that are values found in the task_struct, and above ffffff0000000000.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone